Vendor Onboarding
What Should Your Vendor System Actually Do? The Capabilities Most Organizations Discover Too Late
What Should Your Vendor System Actually Do? The Capabilities Most Organizations Discover Too Late
Most organizations don't go looking for a better vendor system until something breaks.
A payment lands in the wrong account. A 1099 comes back with a TIN mismatch. An auditor asks for documentation that doesn't exist. A vendor calls to say they haven't been paid, and someone in AP realizes the bank account on file isn't theirs anymore.
By then, the gap between what the vendor system does and what it should do is obvious. The problem is that it wasn't obvious before, and that delay is expensive.
This article is for organizations that want to close that gap before it costs them. Here's what a vendor system should actually do, the capabilities that tend to surface too late, and why the difference between a data management tool and a vendor identity platform matters more than most finance leaders realize.
What Most People Mean When They Say "Vendor System"
The term vendor system gets used loosely. Depending on who's asking, it might refer to a vendor master file in the ERP, a vendor portal for onboarding new suppliers, a payment management platform, or some combination of all three.
For the purposes of this article, a vendor system is any platform or infrastructure that manages the relationship between a buying organization and its vendors — from initial setup through ongoing payment and maintenance.
That definition matters because it clarifies the scope of what a vendor system should do. It's not just about collecting data or processing payments. It's about managing the full lifecycle of the vendor relationship in a way that keeps the organization protected, compliant, and in control.
Most vendor systems fall well short of that standard. Here's why.
The Baseline: What Most Vendor Systems Do
The average vendor system — whether it's a module in an ERP, a standalone portal, or a combination of tools — handles a few core functions reasonably well:
It collects vendor information during onboarding. It stores that information in a database. It makes that information available to the payment process. It produces records for 1099 reporting. And it allows AP staff to search for and update vendor records when needed.
These are table stakes. They're necessary but not sufficient.
The gap isn't in these basic functions. The gap is in everything that surrounds them: the authentication layer that should exist before data enters the system, the monitoring that should continue after a vendor is set up, and the controls that should govern how data changes over time.
Most vendor systems were built to manage data. The best ones are built to authenticate it.
Capability 1: Vendor Identity Authentication Before ERP Entry
The single most important thing a vendor system should do — and the thing most organizations discover they're missing after a fraud event — is authenticate vendor identity before data enters the ERP.
This means more than collecting a W-9 and running a manual OFAC check. Authentication means confirming legal entity information against IRS records, validating banking information through independent channels, screening against sanctions lists, and confirming that the person submitting data on the vendor's behalf is authorized to do so.
When this happens before data reaches the ERP, the ERP contains authenticated information. When it doesn't — when the ERP receives raw submissions and treats them as authoritative — the payment system is operating on data that may or may not be accurate.
The distinction feels abstract until a fraudulent vendor setup or a business email compromise attack makes it concrete. At that point, organizations almost universally wish authentication had been built into the front end of their vendor system, not bolted on afterward.
Capability 2: Secure Banking Data Management
Banking information is the most sensitive data in any vendor system. It's also the most targeted.
A vendor system that handles banking data well does a few specific things. It authenticates banking details at the point of entry, confirming that the routing number and account number combination is valid and belongs to a legitimate financial institution. It requires re-authentication when banking details change, rather than accepting updates at face value. And it maintains an audit trail of every banking data change: who requested it, when, what was changed, and what authentication steps were completed.
Most vendor systems don't do this. They collect banking information through a form, store it in the database, and allow it to be updated through a change request process that often involves nothing more than an email and a data entry step.
That process is the primary attack vector for vendor payment fraud. Business email compromise targeting bank account changes succeeds precisely because most vendor systems treat banking updates as routine administrative tasks rather than high-risk events requiring strong authentication.
Capability 3: Ongoing Sanctions and Watchlist Screening
Running an OFAC check at onboarding is not ongoing sanctions screening. It's a point-in-time check that tells you the vendor was clean on the day they were added to your system.
Vendors get added to sanctions lists. Ownership structures change. Entities that were clean at onboarding become restricted later. If your vendor system only checks at the point of setup, you have no visibility into these changes and no documented process for catching them.
A vendor system that does this well runs continuous screening against OFAC's Specially Designated Nationals list and other relevant watchlists, flags changes that require review, and creates a documented record of that ongoing monitoring. That documentation matters not just for catching actual violations, but for demonstrating to regulators that your compliance process is active rather than static.
Capability 4: TIN Matching and 1099 Readiness
1099 season surfaces vendor data problems that were accumulating all year. TIN mismatches, missing tax classifications, incorrect legal names — these are symptoms of a vendor system that collected data without authenticating it.
A vendor system built for 1099 readiness doesn't scramble in Q4. It maintains accurate TIN matching throughout the year, flags discrepancies when they arise, and ensures that the tax data associated with each vendor reflects what's actually in IRS records.
This is a data quality function. Organizations that treat TIN matching as an annual cleanup project instead of an ongoing process pay for it in time, penalties, and strained vendor relationships when corrections have to go out.
Capability 5: Vendor-Owned Profiles With Accountability
One of the most underappreciated capabilities in a modern vendor system is giving vendors ownership of their own data.
In most vendor systems, vendors submit information to the buying organization, which then manages that data on the vendor's behalf. The vendor has no visibility into what's stored, no way to flag errors, and no mechanism to detect if their information has been changed by someone else.
This creates a one-sided accountability structure. The buying organization is responsible for data accuracy, but has limited ability to confirm it. The vendor is most directly affected by errors, but has no access to catch them.
A vendor system that assigns profile ownership to vendors changes this dynamic. Vendors maintain their own authenticated profiles. They can see what buyers have on file. They receive notifications when their data changes. If a fraudster attempts to alter a vendor's banking information, the legitimate vendor has a mechanism to surface it.
This is a fundamentally more defensible model for both parties.
Capability 6: ERP Integration That Carries Authentication Status
A vendor system that authenticates data but doesn't communicate that status to the ERP has a gap in its architecture.
The ERP needs to know more than just what the vendor data says. It needs to know whether that data has been authenticated, when it was last confirmed, and whether any elements of it are flagged for review. Without that context, the payment system is making decisions based on data quality it can't assess.
Strong ERP integration means authenticated vendor data flows into the system with its authentication status intact. Unauthenticated or flagged data gets routed for review rather than processed automatically. And changes to vendor data — particularly banking changes — require re-authentication before they propagate to the payment system.
This is the architecture that gives AP teams actual control, rather than the illusion of it.
Capability 7: Audit Trails That Exist Outside the ERP
When vendor payment fraud occurs, investigators need to reconstruct what happened. That reconstruction depends on documentation.
If the only record of vendor data is what's currently in the ERP, that documentation is incomplete and potentially compromised. ERP data can be changed. Records can be altered. The audit trail for what happened — and when, and who authorized it — may not exist or may not be trustworthy.
A vendor system that maintains its own audit trail, independent of the ERP, creates a reference point that survives ERP manipulation. It records what authenticated data looked like at every point in time. It logs who requested changes, what authentication steps were taken, and what the system contained before and after each update.
This documentation serves multiple purposes: fraud recovery, regulatory compliance, and internal accountability. Organizations that have it are in a materially better position when things go wrong. Those that don't are often starting from scratch.
The Capabilities Most Organizations Discover Too Late
Here's the honest pattern. Most organizations discover these capability gaps not during an evaluation process, but after a specific incident forces the issue:
A fraud loss makes the banking authentication gap visible. A compliance finding surfaces the absence of ongoing sanctions screening. A 1099 penalty highlights the TIN matching problem. An audit reveals that the audit trail doesn't exist.
Each of these is a solvable problem. None of them are inevitable. But they tend to go unaddressed until the cost of inaction becomes concrete, because vendor system capabilities are easy to underestimate until the absence of them creates a measurable problem.
The organizations that close these gaps proactively share a common trait: they evaluated their vendor system against what it should do, not just what it currently does. That evaluation is uncomfortable. It surfaces gaps that were invisible before. But it's significantly less expensive than the alternative.
What a Modern Vendor System Looks Like
When a vendor system is built around authentication rather than just data collection, the operational picture changes.
New vendors complete Guided Onboarding through a process that includes identity authentication, banking confirmation, and TIN matching before their profile is activated. Buyers connect to authenticated profiles rather than raw submissions. Banking changes go through re-authentication before reaching the ERP. Continuous sanctions screening runs in the background. The audit trail captures every change, every authentication step, and every data state.
AP teams stop being the last line of defense against fraud and start managing exceptions. Compliance is documented automatically rather than assembled manually each quarter. The ERP receives data that's already been authenticated, rather than data that requires post-entry review.
That's what a vendor system should do. The gap between that description and what most organizations currently have is the risk they're carrying.
Don’t Let an Infrastructure Problem Take You Out
A vendor system that collects data without authenticating it is infrastructure for a problem that hasn't happened yet.
The capabilities that matter most — vendor identity authentication, secure banking data management, continuous sanctions screening, vendor-owned profiles, and independent audit trails — aren't advanced features. They're the baseline for a vendor system that actually protects the organization.
Most organizations discover this too late. The ones that don't are the ones who asked the right questions before the incident, not after.
Get Ready For Vendor Management Appreciation Day
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.
Want Help Aligning Teams?
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
Interested in More Tips?
Want Personalized Guidance?
A vendor system should do more than collect and store vendor data. At minimum, it should authenticate vendor identity before data enters the ERP, manage banking information securely with re-authentication on changes, run continuous sanctions and watchlist screening, support accurate TIN matching throughout the year, and maintain an independent audit trail of all vendor data changes. Most vendor systems handle data collection well. The gap — and the risk — is in authentication, ongoing monitoring, and the controls that govern how data changes over time.
Let us show you how we can help
We’d love to walk through your process with you and talk about security, compliance, efficiency and sleeping better at night.
See How it Works