What Your Vendor Payment Software Can’t Protect You From (And What Fills the Gap)

You've invested in vendor payment software. Maybe it automates your payment runs, integrates with your ERP, handles ACH and wire payments, reduces check volume, and gives you a cleaner approval workflow.

It's doing its job, but that's not the problem.

The problem is what it was never designed to do and what that limitation exposes you to.

To be clear, vendor payment software isn’t a problem, but miscalculating the scope can be. Understanding where your payment software ends and where your risk begins is the first step to actually managing that risk.

---

Let's start with an honest description of what most vendor payment software is actually designed to accomplish. Payment automation platforms are built to get approved invoices paid. They manage payment runs, handle multiple payment methods, integrate with ERPs, reduce manual data entry, and give finance teams better visibility into cash outflows. The best ones also handle payment reconciliation, early payment programs, and supplier financing.

These are genuinely useful capabilities. They solve real operational problems. If your team is still cutting checks manually or managing payment approvals through email chains, good vendor payment software can meaningfully improve your operations.

But here's what that description doesn't include by design: authenticating that the vendor you're paying is who they say they are, that the banking information you have for them is accurate, and that the data in your ERP hasn't been compromised between the last time you authenticated it and today.

That's not the job vendor payment software was built to do. It assumes the data it's working with is accurate. It's designed to process payments reliably, not to question the legitimacy of the vendor data it's processing.

That assumption is where the risk lives.

---

1. Business Email Compromise Targeting Bank Account Changes

Business email compromise (BEC) is consistently among the highest-dollar fraud categories reported by the FBI. In the vendor payment context, it typically works like this:

A fraudster gains access to or spoofs a legitimate vendor's email address. They contact your AP team with a message along the lines of: "We've changed our banking information. Please update your records." Sometimes they provide a completed form. Sometimes they send a letter. Sometimes it's just an email.

If your vendor payment software processes the payment using the banking information in your ERP (which it will, because that's its job) and that banking information was updated based on a fraudulent change request, the payment goes to the fraudster.

Your payment software didn't fail. It processed exactly what it was told to process. The failure was upstream, in the process that accepted a banking change without adequate authentication.

Vendor payment software has no mechanism to detect this. It can't distinguish between a legitimate bank account update and a fraudulent one. It processes what's in the system.

2. Fraudulent Vendor Setup

Not all vendor fraud arrives via email interception. Some of it is built in from the beginning.

A fraudulent vendor setup occurs when a vendor record is created in your ERP using fabricated entity information, stolen identities, or shell company structures designed to pass basic review. Payments get approved for this vendor, often by going through your standard approval workflow, and the money goes to a fraudster.

Your vendor payment software processes these payments identically to legitimate ones. There's nothing in the payment itself that flags the problem. The fraud was in the vendor record, established during onboarding, before the payment software was ever involved.

This isn't a rare edge case. It's a documented pattern in organizations with weak vendor identity authentication at onboarding, which, to be direct, describes most organizations.

3. Stale and Drifting Vendor Data

This one is slower-moving, but no less consequential.

Vendor data has a shelf life. Businesses change banking relationships, move offices, update ownership structures, get acquired, go out of business. The information that was accurate when a vendor was onboarded two years ago may not reflect current reality.

In a low-risk environment, stale vendor data is mostly a nuisance: misdirected payments, returned ACH transactions, 1099 issues. In a higher-risk environment, stale vendor data creates specific vulnerabilities: banking accounts that are no longer monitored by the legitimate vendor, contact information that reaches the wrong people, ownership structures that no longer reflect who's actually controlling the account.

Vendor payment software doesn't know any of this. It pays what the ERP says to pay. It doesn't know or care whether the vendor data is current.

---

It would be convenient if vendor payment fraud were a static problem, something that exists at a constant, manageable level that you've already priced into your risk posture.

It isn't.

Fraud attacks targeting vendor payment processes are increasing in both frequency and sophistication. Business email compromise losses have grown substantially year over year. The techniques fraudsters use to impersonate vendors are improving and include spear phishing, domain spoofing, and social engineering of AP staff. Attacks are more targeted and more patient than they used to be.

At the same time, the attack surface has expanded. Remote work normalized email-based communication for things that previously happened in person or over the phone. Vendor counts at many organizations have grown. AP teams are managing more with the same or fewer resources, which means less time for manual authentication steps.

The gap between what your vendor payment software can do and what the fraud landscape demands has widened. We’re not trying to be alarmist. It's the honest read on where things stand.

---

If vendor payment software can't necessarily protect you from these risks, what does?

The answer is vendor identity infrastructure: a set of systems and processes designed specifically to authenticate who your vendors are, confirm the accuracy of their payment data, and maintain that authentication over time.

This is distinct from vendor payment software. It operates upstream, before data enters the ERP and before the payment software ever touches it. Its is to ensure the data payments are processed against is accurate and legitimate.

Here's what that infrastructure looks like in practice.

Authenticated vendor profiles. Rather than collecting vendor data and trusting the submission, vendors establish profiles through a process that includes identity authentication. Legal entity information is matched against authoritative sources. TIN matching runs automatically. Banking information is authenticated, not just recorded. The result is a vendor profile that carries an authenticated credential, not just a data record.

Secure handling of banking changes. When a vendor submits a bank account change, that change goes through re-authentication before it reaches the ERP. The authentication isn't a callback to the same phone number in the file but an independent confirmation process that establishes the legitimacy of the change. Banking updates don't flow around the authentication process; they go through it.

Ongoing monitoring. Sanctions status changes. Ownership structures shift. Banking relationships are updated. Continuous monitoring tied to re-authentication means the payment system is always working from current authenticated data, not a point-in-time snapshot from months or years ago.

An audit trail that exists outside the ERP. When vendor payment fraud occurs, the investigation always asks: what was the vendor data at the time of the payment, and how was it authenticated? Vendor identity infrastructure creates that record independently of the ERP, so even if ERP data is manipulated, there's an authoritative reference for what authenticated vendor data should have looked like.

Vendor-side accountability. Legitimate vendors have access to their own profile and can see what information buyers have for them. They can flag discrepancies. They receive notification of changes. This creates a check on fraud that doesn't rely entirely on the buyer's team to detect; the vendor themselves can surface problems that the buyer might not catch.

---

Here's something that doesn't get discussed enough in vendor payment solution conversations: who bears the loss when fraud occurs?

In most vendor payment fraud scenarios (particularly ACH and wire fraud), recovery rates are low. The money moves fast, often internationally, and tracing it back is difficult. Financial institutions have limited liability for authorized payment transactions, even when that authorization was obtained through fraud.

That means the loss lands on the organization.

The question of risk transfer — whether any party in the payment chain bears liability for fraud that occurs due to inadequate authentication — is largely determined by the strength of your authentication process. Organizations that can demonstrate a documented, consistent, defensible vendor identity authentication process are in a materially better position than those that can't.

Vendor payment software, by itself, doesn't create that position. Vendor identity infrastructure does.

---

Finance leaders sometimes ask what "good" looks like when it comes to vendor payment security. Here's a practical description.

You can name, step by step, how a new vendor is set up. What’s more, each step includes an authentication action, not just a data collection step. The authentication is documented and auditable.

When a vendor submits a change to their banking information, there is a defined process that authenticates the change independently before it reaches the ERP. That process doesn't rely on trusting the communication channel through which the request arrived.

Ongoing sanctions screening runs continuously, not just at onboarding. You know your vendor base is clean today, not just that it was clean when the vendors were first added.

When something goes wrong, whether a misdirected payment, a fraud attempt, a vendor data discrepancy, your team can reconstruct exactly what happened, when, and what was authenticated at each step.

If you can describe your current process in those terms, you're in a strong position. If you can't (i.e., if any of those answers involve "I'd have to check" or "we usually do" rather than "here's the documented process"), you have gaps worth closing.

---

Finance leaders who understand these gaps sometimes make a calculation: the probability of a significant fraud event is low enough that the cost of addressing the gap doesn't justify the investment.

This calculation is getting harder to defend.

Fraud attempts targeting vendor payment processes have increased substantially. The sophistication of those attempts has increased. The dollar value of individual fraud events has increased. And the regulatory and reputational consequences of payment fraud are more significant than they used to be.

The expected cost of a fraud event has risen. The cost of vendor identity infrastructure has not risen proportionally. The math is shifting.

More practically: every organization that has experienced significant vendor payment fraud thought the probability was low before it happened. The absence of prior incidents is not evidence that your current process is adequate. It may just mean the attempt hasn't come yet.

---

Your vendor payment software is doing its job. The problem is that its job doesn't include authenticating vendor identity, securing banking change processes, or maintaining authenticated data over time.

Those are the things that protect you from vendor payment fraud. And they require different infrastructure that sits upstream of the payment, before data enters the ERP, at the point where vendor identity is established and maintained.

The gap between what your payment software does and what complete vendor payment protection requires is real, and it's where most successful fraud attacks land.

Vendor identity infrastructure fills that gap. Not by replacing your payment software, but by ensuring the data it processes has already been through an authentication process you can defend.

---

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