Vendor Verification and Banking Validation: Stopping Fraud Before Payment
- What is vendor verification, and why does it belong before payment?
- Why do vendor records and bank portals let bad payments through?
- What does a strong vendor verification process look like?
- How does automation make verification a system step, not a favor?
- Verify every vendor and bank account with Corpay
Vendor verification is the process of confirming that a supplier is a real, legitimate business entity and that the bank account on file genuinely belongs to them. Done before payment, it prevents both fraudulent redirection and the ordinary mistake of paying the wrong party.
Most finance teams have some version of this already. A W-9 gets collected, someone eyeballs the company name, and the banking details land in the ERP or the bank portal. What's usually missing is the step that ties the account back to the entity, and the discipline that repeats the check every time those details change.
The gap shows up in two very different failure modes that share one root cause. In the first, an attacker sends a banking-change request and money goes to them. In the second, nobody is attacking anyone, and an AP specialist simply selects the wrong template from a list of similarly named vendors. Both trace back to a vendor master that can't distinguish one supplier from another with confidence.
Key Takeaways
Attempted or actual payments fraud reached the large majority of organizations in 2025, per AFP survey data, and vendor records are where much of it enters.
A verified vendor means the entity is confirmed to exist and the bank account is confirmed to belong to that entity, which are two separate checks that people often treat as one.
Duplicate and near-duplicate vendor records cause misdirected payments without any fraud involved, and they defeat duplicate-payment controls at the same time.
Manual banking-change verification is unreliable because it depends on someone deciding to make the call, and it degrades quietly under volume.
Independent bank account validation confirms ownership rather than format, which is the difference that stops a mule account.
Vendor master data management is the upstream control that makes every downstream check work, and it's usually the least-resourced piece.
What is vendor verification, and why does it belong before payment?
Vendor verification is a pre-payment control that confirms a supplier's identity and banking details before funds are released, rather than confirming them after a problem surfaces. It belongs before payment because every remedy available afterward is slower, more expensive, and less likely to work.
The exposure data supports treating it as a primary control rather than an onboarding formality. More than three-quarters of organizations (76%) experienced attempted or actual payments fraud in 2025, according to AFP's 2026 Payments Fraud and Control Survey Report. The same survey found 30% of organizations were targeted by ACH-debit fraud and 25% by wire fraud, which are precisely the rails a bad vendor record routes money to.
Verification also carries an efficiency argument that gets underrated. A clean, verified vendor master reduces exception handling across the whole AP cycle, because the mismatches that create exceptions in matching, reconciliation, and 1099 reporting frequently originate in the vendor record. Getting the sequencing right within the accounts payable process means vendor setup and validation happen before the first invoice arrives, not in parallel with paying it.
What does "verified vendor" actually mean?
A verified vendor is a supplier whose legal existence has been independently confirmed and whose payment account has been confirmed to belong to that same legal entity. Both halves have to hold. A real company with an unverified account is as dangerous as a fake company, because the fraud you're guarding against uses a real company's name.
The term gets used loosely by software vendors, which muddies things. Some platforms mean "we checked the tax ID format." Others mean "we confirmed the account holder name matches the registered entity through a banking data source." Those are very different assurances at the same price point, and the question worth asking any provider is which specific external source they check against and what they do when the check comes back ambiguous.
How do you check if a vendor is legitimate?
Legitimacy checks confirm that the business exists as claimed, is authorized to operate, and isn't on a list that prohibits you from paying it. The core set is short and mostly automatable:
Business registration confirmed with the state or national registry where the entity claims to be incorporated.
Tax identification number validated against IRS records through TIN matching, which also protects your 1099 reporting.
Sanctions and watchlist screening against OFAC and any lists relevant to your industry or jurisdictions.
Address and contact verification against an independent source, not just the details supplied on the vendor's own form.
Duplicate screening against your existing vendor master before the record is created.
Beneficial ownership review where the entity structure is opaque or the spend is material.
Run these at onboarding and the marginal cost per vendor is small. Run them reactively after a problem and they become a forensic exercise. The duplicate-screening step in particular tends to get skipped because it feels like an internal hygiene item rather than a fraud control, which is a misreading of what it does.
Why do vendor records and bank portals let bad payments through?
Because both were designed to store instructions accurately, not to question whether the instructions are correct. A bank portal will faithfully send money to whatever template you select, and an ERP will faithfully pay whatever vendor record you point an invoice at. Neither system has an opinion about whether that's the party you owe.
The scale of a mature vendor master turns that neutrality into real risk. One AP practitioner described wiring $475,000 to the wrong vendor because AP selected the wrong template from more than 1,500 maintained in the bank portal, and the accounting manager who approved the payment missed it because the vendor names were similar. No attacker was involved. The system did exactly what it was told, and what it was told was wrong.
ACFE's Occupational Fraud 2024: A Report to the Nations puts the deliberate version in context. Billing schemes are the second most common occupational-fraud type, asset misappropriation accounts for 86% of cases, and the median occupational-fraud loss is $145,000. Billing schemes work by creating or altering a vendor record, which is to say they exploit exactly the gap that unverified vendor data leaves open.
If you can't say how many near-duplicate supplier records exist in your vendor master right now, that number is the first thing worth measuring.
How do duplicate and similar vendor records cause misdirected payments?
Duplicate records cause misdirected payments by removing the human's ability to tell two options apart at the moment of selection. When a dropdown shows three entries that read almost identically, selection accuracy stops being a matter of care and becomes a matter of luck.
The practitioner whose team lost that money identified the fix precisely, calling for either a unique vendor ID match or a second verification step in the process. Both work, and they work differently. Unique-ID matching removes the ambiguity at selection time by forcing the payment to reference an identifier that can't be confused visually. A second verification step catches the error after selection but before release. Teams with a serious volume of similar supplier names generally need both.
Here's a diagnostic worth running this week. Ask whoever owns the vendor master to sort it by normalized name, stripping punctuation, suffixes like Inc and LLC, and case, then show you the clusters where two or more records collapse to the same string. In most mid-market companies that list is considerably longer than leadership expects, and every cluster on it is a misdirected payment waiting for the right invoice to arrive. The same clusters also defeat duplicate-payment detection, since a check scoped to one vendor ID will never compare invoices filed under a second ID for the same supplier.
Why is manual banking-change verification unreliable?
Manual verification is unreliable because it's a discretionary step in a non-discretionary process. Policy says to call the vendor; the payment run says today. When those conflict under volume, the call is what gives.
A widely shared account of a $188,000 loss came down to exactly that omission, with the original vendor email hacked and the asset management team never voice-verifying the updated wire information. Nobody in that story was careless in a way they'd recognize at the time. The verification step existed on paper and simply didn't execute, which is the normal failure pattern rather than an unusual one.
Verizon's 2024 Data Breach Investigations Report found that 68% of breaches involved a non-malicious human element, a person tricked or making an error rather than an insider acting badly. Any control whose execution depends on a person remembering, under time pressure, to do something optional will inherit that rate. The manipulation techniques covered in how social-engineering fraud works against finance teams are specifically designed to arrive at the moment when the verification step is most likely to be skipped.
Segregation of duties fails the same way, and for the same reason. One controller described an environment where treasury, procurement, and the GL team could all enter invoices, with no meaningful separation in AP. That isn't a policy failure so much as an access-configuration failure that nobody revisited after the org chart changed. Enforcing it through system permissions, in the way card controls and spend policies enforce limits on the card side, is what makes it survive staff turnover.
Protect cash flow with modern AP
Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.
Download the whitepaper
What does a strong vendor verification process look like?
A strong process runs verification as a sequence of gated steps where each one must complete before the vendor becomes payable, and where any banking change re-opens the gate. Six steps cover the ground:
Collect supplier data through an authenticated portal rather than by email or spreadsheet, so the submission itself is attributable.
Confirm legal existence through registration, TIN matching, and sanctions screening before a record is created.
Screen against the existing vendor master for duplicates and near-duplicates, resolving matches before proceeding.
Validate the bank account independently, confirming ownership against the verified legal entity.
Enforce segregation of duties so that vendor setup, approval, and payment release sit with different people or roles.
Re-verify on every banking change, with a system-enforced hold on payments to the account until verification completes.
Step six is the one most programs treat as optional, and it's the one attackers depend on. FBI Internet Crime Complaint Center data recorded $55,499,915,582 in global exposed BEC losses across 305,033 incidents between October 2013 and December 2023, most commonly arriving as a fraudulent request to change vendor banking details. U.S. domestic victims alone reported $20,089,561,364 in exposed losses across 158,436 cases. A banking change amounts to a payment redirection request, which is why it deserves the same scrutiny as a new vendor, and how business email compromise targets AP teams covers how convincingly those requests arrive.
A supplier portal is the practical delivery mechanism for most of this, since it moves data collection out of email entirely and gives you an authenticated, logged channel for changes. What a supplier portal does for onboarding and self-service covers how that shifts the work onto the supplier while improving the audit trail on your side.
How do you validate a vendor's bank account before paying?
Bank account validation confirms that the account number and routing details correspond to an open account held by the vendor's verified legal entity. The critical word is ownership. A format check tells you the number could exist; an ownership check tells you whose it is.
There are a few practical methods, and they trade off speed against certainty:
Method | What it confirms | Speed | Limitation |
Format and routing check | Structure is valid, bank exists | Instant | Confirms nothing about ownership |
Micro-deposit verification | Vendor controls the account | 1-3 days | Slow; confirms control, not legal ownership |
Bank data source lookup | Account status and holder name | Near real-time | Coverage varies by institution |
Out-of-band callback | Vendor asserts the details | Minutes to days | Depends on reaching a known contact |
Coverage and turnaround vary by provider and by receiving institution, so confirm both before relying on a single method.
Most teams end up combining a data-source lookup with an out-of-band callback for higher-value or newly changed accounts. What you want to avoid is the arrangement where the only check is a format validation, because that's the configuration a mule account passes without difficulty. The ACH-specific version of this problem, including the controls that catch fraudulent debits and credits, is covered in tips for preventing ACH credit fraud.
How does vendor master data management reduce fraud and duplicates?
Vendor master data management reduces both by making every supplier record unambiguous, current, and attributable. When one supplier maps to exactly one record with verified attributes, the ambiguity that fraud and error both exploit disappears.
The discipline covers four things:
A single record per legal entity, with an enforced unique identifier.
Mandatory fields that can't be bypassed at record creation.
Periodic re-validation of dormant and long-lived records.
Deactivation rather than deletion, so payment history stays intact.
None of it is technically hard. It's unglamorous and it competes for resources against work with a visible deliverable, which is why it loses.
The payoff shows up in places that look unrelated. Clean master data improves three-way match rates, since matching an invoice against a purchase order and a receipt depends on the vendor reference resolving correctly. It reduces duplicate payments, since duplicate detection is scoped by vendor. And it shortens audits, because auditors testing vendor authorization can sample cleanly instead of reconstructing which record was live when. The broader governance model in vendor master file lifecycle controls covers how to keep it current once it's clean.
How does automation make verification a system step, not a favor?
Automation makes verification structural by requiring it to complete before a vendor becomes payable, which removes the option to skip it. The check stops being something a person does when there's time and becomes a state the record has to reach.
The difference is enforcement, not effort. A manual process and an automated one can run identical checks; only one of them refuses to release a payment when a check hasn't passed. That refusal is the entire control. Everything else is procedure.
Detection timing shows what happens without it. ACFE's Occupational Fraud 2024: A Report to the Nations found that 43% of occupational frauds are first detected by a tip rather than by controls, and that the median scheme runs 12 months before discovery. A year of undetected activity is a long time for a fraudulent vendor record to keep drawing payments, and it's a reasonable proxy for how long a well-hidden problem survives when nothing in the system is actively looking. The scheme mechanics in how AP fraud operates explain why they last that long.
Payment rail choice contributes to the same outcome. FinCEN data reported through the Thomson Reuters Institute shows 682,276 check-fraud Suspicious Activity Reports filed in 2024, up from 665,505 in 2023, and every check you issue exposes your account and routing details to everyone who handles it. Moving suppliers onto validated electronic rails is partly a fraud control and partly a data-exposure reduction, and the operational gains covered in the benefits of automating supplier payments come along with it.
How does a managed service verify suppliers at scale?
A managed service verifies at scale by taking the outreach, chasing, and evidence collection off your team and running it as an ongoing function rather than a project. Software enforces the gate; people do the work of getting suppliers through it.
That division matters because supplier verification is mostly a communications problem, not a technical one. Confirming a bank account is fast. Reaching the right person at a supplier who hasn't responded to three emails, walking them through a portal registration, and resolving the case where their AR contact left the company is what actually consumes the time. Teams that automate the check but keep the outreach in-house tend to find the backlog reappears within two quarters.
The scale threshold where this flips is lower than people expect. A few hundred active suppliers with normal turnover generates a steady stream of banking changes, new enrollments, and dormant-record cleanups. That's a part-time job nobody owns, which means it becomes nobody's job, and automated invoice processing that reduces payment fraud only helps to the extent the underlying supplier data stays trustworthy.
Verify every vendor and bank account with Corpay
The two failure stories above, the wire sent against the wrong template and the loss where nobody voice-verified a banking change, have the same shape. A person was the last check, the check was optional, and the process gave no signal when it didn't run. You can't fix that with more training, and you can't staff around it once supplier counts pass a few hundred.
Corpay's payments automation makes verification a condition of payability. We enroll and verify suppliers, validate banking details at onboarding and again on every change, and hold payments to changed accounts until that validation completes. MFA-protected portals move supplier data collection out of email into an authenticated, logged channel, and system-enforced permissions keep vendor setup separated from payment release regardless of who's covering for whom that week. Our managed service runs the supplier outreach behind all of it, which is the part that quietly fails when it stays in-house.
Corpay is connected to a network of more than four million accepting vendors, and that reach is why enrollment and verification work as an ongoing service rather than a one-time cleanup that decays.
See how Corpay's payments automation validates supplier banking before funds move, or look at the wider AP automation platform to see how verification connects to matching, approval, and reconciliation.
Frequently Asked Questions
What is a vendor verification certificate?
It's a document some buyers or platforms issue confirming a supplier has completed a defined verification process. There's no universal standard behind the term, so the assurance it carries depends entirely on which checks the issuer actually ran. Treat it as supporting evidence rather than proof.
What is the difference between vendor verification and vendor onboarding?
Onboarding is the full process of bringing a supplier into your systems, including contracting, tax forms, and payment setup. Verification is the subset that independently confirms the supplier is who they claim to be and that the payment account belongs to them.
How often should you re-verify an existing vendor?
Always on a banking change, and on a periodic cycle otherwise. Annual re-validation is common for active suppliers, with dormant records reviewed or deactivated after a defined period of no activity. High-value relationships often warrant a shorter interval.
Who should own vendor verification, AP or procurement?
Procurement usually owns supplier selection and onboarding, while AP owns payment execution, so verification works best as a shared control with clear boundaries. What matters more than the reporting line is that whoever sets up the vendor cannot also release payment to it.
Can bank account validation confirm the account holder's name?
Some validation methods can, depending on the data source and the receiving institution's participation. Coverage isn't universal, so ask any provider specifically whether they return account holder name and what percentage of accounts they can resolve it for.
What happens if a vendor refuses to complete verification?
Treat it as a risk signal rather than an inconvenience. Legitimate suppliers occasionally resist because the request reached the wrong contact or the process is unclear, which is usually resolvable. Persistent refusal on a banking change, in particular, is a common indicator of a compromised or fraudulent request.
- What is vendor verification, and why does it belong before payment?
- Why do vendor records and bank portals let bad payments through?
- What does a strong vendor verification process look like?
- How does automation make verification a system step, not a favor?
- Verify every vendor and bank account with Corpay
Switch to Corpay
Discover how making the move to Corpay streamlines payments and strengthens your business.
Talk to an ExpertSmarter payments. Stronger growth. Keep business moving.
Corpay powers payments for 800,000+ businesses worldwide. Let’s build what’s next for yours.