Vendor Onboarding vs. Vendor Identity: The Problem With Treating Them As The Same Thing

Ask most AP teams how they authenticate their vendors, and they'll describe their onboarding process.

They'll walk you through how new vendors submit a W-9, how banking details get collected, how someone in AP enters the data into the ERP, maybe how they run an OFAC check or make a callback call. It's a reasonable description of a reasonable process.

But here's the problem: vendor onboarding and vendor identity are not the same thing. Treating them as interchangeable is one of the most consequential mistakes in AP risk management,  and it's nearly universal.

This article explains the difference, why it matters, and what organizations that have confused the two usually discover, often the hard way.

Vendor onboarding is a workflow problem. The question it answers is: how do we get a new vendor set up in our system?

Vendor identity is an authentication problem. The question it answers is: how do we know the vendor we're paying is who they say they are and that the payment information we have for them is accurate and legitimate?

These are related but distinct. You can have a highly efficient onboarding process that still produces poor vendor identity. And you can have strong vendor identity authentication that doesn't require a particularly elaborate onboarding workflow.

The confusion between the two has real consequences. When organizations optimize for onboarding speed — fewer steps, faster approvals, simpler forms — they often do so at the expense of identity authentication. That tradeoff feels invisible until a fraud incident makes it obvious.

---

Vendor onboarding, at its core, is the process of collecting information from a new vendor and getting them into the payment system. In most organizations, this involves:

• Sending a new vendor a form (paper, PDF, or web-based)
• Collecting legal name, address, tax identification, and banking information
• Manual data entry into the ERP
• Some level of review — W-9 verification, OFAC check, maybe a callback to confirm banking details
• Approval and activation in the system

This process is designed to gather data. It's not inherently designed to authenticate it.

The form collects what the vendor submits. Manual review checks for obvious errors. But the fundamental question — is this data accurate, and is the person submitting it authorized to do so? — often goes unanswered in any rigorous way.

That gap is the problem.

---

Vendor identity is the authenticated truth about a vendor's legal and financial standing. It goes beyond what was collected during onboarding to establish what can be confirmed through independent authentication.

True vendor identity management includes:

Legal entity authentication. Is the legal name and taxpayer identification number consistent with IRS records? Is there a match or a potential mismatch that signals a data entry error, a fraudulent submission, or an entity that doesn't exist in the way claimed?

Banking authentication. Is the routing number and account number combination valid? Does it belong to a financial institution that makes sense for this vendor? Has it been authenticated through a process that goes beyond trusting the form submission?

Sanctions and watchlist screening. Is this vendor, or any associated entity, on OFAC's Specially Designated Nationals list or other relevant watchlists? And criticall, is that screening ongoing, or only at the point of onboarding?

Submission legitimacy. Is the person submitting this data authorized to do so on the vendor's behalf? Business email compromise attacks often succeed not because the data itself is suspicious, but because no one authenticated that the request came from a legitimate source.

Ongoing monitoring. When vendor data changes — banking information, ownership, address — is that change re-authenticated before it affects payments? Or does it go directly into the ERP because someone submitted a request?

Most onboarding processes address one or two of these requirements, partially. Very few address all of them consistently and at scale.

---

If the distinction is this important, why do so many organizations conflate the two?

A few reasons.

First, when onboarding goes well — when a new vendor is set up quickly, the data looks right, and payments process without incident — there's no feedback signal that authentication was inadequate. The absence of fraud doesn't mean authentication was rigorous. It might just mean you were lucky, or that the bad actor hasn't found your vendor data yet.

Second, most of the tools organizations use for onboarding are workflow tools. They're designed to move data from vendor to ERP as efficiently as possible. Authentication steps, if they exist, are add-ons to the workflow rather than foundational to it. That architecture puts onboarding speed and authentication rigor in tension with each other.

Third, authentication is hard to see. An efficient onboarding process has obvious metrics: time to onboard, forms completed, vendors activated. Vendor identity authentication is less visible — until it fails.

---

When organizations treat vendor onboarding as vendor identity, a few specific risk patterns emerge.

Business email compromise via bank account changes. This is the most common and most costly pattern. A fraudster impersonates a legitimate vendor — often via a spoofed or compromised email address — and requests a bank account update. If the payer's process for handling that update is essentially: "receive the request, authenticate by replying to the same email, update the ERP," then the fraud succeeds. The "verification" step confirmed nothing.

This attack works because onboarding processes create a model for how vendor updates are handled. And that model is usually: collect the data, make a reasonable effort to confirm, enter into the system. When bank account changes flow through the same model, they carry the same vulnerability.

Stale or inaccurate vendor data accumulating in the ERP. When identity authentication is only point-in-time — at initial onboarding — vendor data in the ERP gradually drifts from reality. Vendors change ownership, move, update banking relationships. Some of those changes are submitted through legitimate channels. Some aren't. Without ongoing monitoring tied to re-authentication, the ERP becomes a collection of data of varying accuracy and vintage.

Compliance exposure on TIN matching and sanctions. 1099 reporting errors and OFAC violations trace back to poor vendor identity data. If TINs were never properly matched, or if sanctions screening was only done at onboarding and never repeated, the compliance record is thin, and the liability is real.

Fraud that looks like vendor data. In some cases, fraudulent vendor entries don't look like fraud at all. They look like real vendors because they were added through the legitimate onboarding process by someone who had access to it. The vendor exists in the ERP. Payments have processed. And at some point, someone notices that the "vendor" is a shell entity that's been draining funds for months.

---

Organizations that treat vendor identity as a distinct discipline — separate from and more rigorous than vendor onboarding — operate differently in several ways.

They authenticate before data enters the ERP. Rather than collecting vendor data and hoping it's accurate, they run authentication steps that must pass before the vendor is activated in the payment system. The ERP receives authenticated data, not raw submissions.

They maintain authentication over time. Banking information changes. Ownership changes. Sanctions status changes. Strong vendor identity programs don't just authenticate at onboarding, they monitor ongoing data for changes that require re-authentication.

They separate the submission from the authentication. When a vendor submits a bank account change, the process doesn't trust the submission; it authenticates it. That usually means out-of-band confirmation, not just a reply to the same email thread.

They create accountability at the vendor level. Rather than treating the vendor as a passive data provider, they give vendors ownership of their identity profile and responsibility for maintaining its accuracy. That's good security practice and it's a different organizational model for vendor relationships.

---

Separating vendor identity from vendor onboarding doesn't mean onboarding doesn't matter. It does.

Onboarding efficiency affects how quickly new vendors can be activated and paid. A cumbersome onboarding process creates friction that has real cost: delayed projects, strained vendor relationships, AP teams spending time chasing forms instead of processing payments.

But onboarding efficiency and identity authentication rigor are not in conflict when the architecture is right. The goal is a process where authentication happens as part of onboarding instead of a manual add-on that slows everything down, but as a built-in function that's faster and more reliable than manual checks.

That's the design problem that most organizations haven't solved yet. They've optimized their onboarding workflow without building authentication into it. Or they've built authentication steps that are so manual they've become inconsistent in practice.

---

When vendor onboarding and vendor identity are properly integrated, the process looks something like this:

A new vendor receives an Invitation to Connect from the buying organization. They complete a profile through a guided process that includes identity authentication steps — not just data collection. Banking information is authenticated through the platform, not accepted on the vendor's word alone. TIN matching runs automatically. Sanctions screening runs at onboarding and continues on an ongoing basis.

When the vendor's profile is complete and authenticated, a Payee Profile is made available to the buyer containing data that has already been through an authentication process the buyer doesn't have to manage manually. That data flows into the ERP, where it's treated as authenticated rather than as a raw submission requiring review.

When the vendor's banking information changes, the change flows through the same authentication infrastructure, not around it. The update doesn't reach the payment system until it's been re-authenticated.

That's not a perfect system. No system is. But it's a fundamentally more defensible posture than treating onboarding and identity as the same thing.

---

Here's a useful diagnostic. Ask your AP team: if a vendor you've been paying for two years sends an email today saying their bank account has changed, what happens?

Walk through every step. Who gets the email? What do they do? How do they confirm the request is legitimate? What does "confirmation" actually mean — a reply to the same thread, a callback to a number you already have on file, something else? How does the new banking information get into the ERP? Who approves it?

If any step in that chain relies primarily on trusting the submission rather than authenticating it independently, you have a gap.

That gap is where vendor fraud lives. And it persists in most organizations not because they haven't thought about it, but because vendor onboarding processes weren't designed to close it.

---

Vendor onboarding is a workflow. Vendor identity is a standard.

When you conflate the two, you end up with a process that looks like authentication but isn't. Data gets collected. Forms get completed. Vendors get activated. And somewhere in there, the question of whether any of it was actually authenticated — against authoritative sources, by a process that can be defended — doesn't get a clean answer.

That's the gap that fraud exploits. Closing it requires treating vendor identity as its own discipline: one with its own standards, its own infrastructure, and its own place in the payment process.

The good news is this isn't a solved problem that only large enterprises can afford. The right platform does the authentication work that manual processes can't do consistently. The question is whether you're willing to see your current process clearly — and whether you can distinguish between collecting data and authenticating it.

---

Vendor Management Appreciation Day (VMAD) returns this year—and we’d love to have you join the celebration. There’s never a wrong time to recognize one of the most essential yet often overlooked functions in every organization: vendor management.

We’re already preparing for this year's festivities, and we want the entire community to be part of it. VMAD was created to bring vendor management professionals together, spotlight the innovation happening in the field, and give this important work the recognition it deserves.

As a reminder, throughout the year, we’re rolling out monthly gifts and resources to help elevate your vendor management practice. We’re also planning a series of events designed to spark connection, learning, and celebration across the profession.

So, while you wait for the big day, explore what’s new—and grab some free vendor management goodies.

---

Explore our blogs below. They’re filled with action items you can implement right away.

Why Supplier Verification Is the First Line of Defense Against Risk

What Is Business Identity? Why It Matters, and How to Get It Right

The Supplier Risk Assessment Process: A Step-by-Step Framework

Why Supplier Lifecycle Management Is the New Frontline of Cybersecurity

---

Subscribe to our blog

---

Contact Us–we’d love to help you