Blog · Guide
Why your AP controls will fail without pre-payment verification
Published June 10, 2026 · 7 min read
The AFP 2026 Payments Fraud and Control Survey found that 76% of organizations experienced attempted or actual payment fraud in 2025. Most of those organizations had AP controls in place. Some had multi-level approvals, dual authorization, and regular staff training. They still got hit — because controls and verification are not the same thing.
What AP controls actually do (and what they do not)
AP controls — user permissions, approval workflows, segregation of duties, audit logs — are essential and worth having. They prevent a junior staff member from approving their own expense, catch duplicate invoice numbers, and create an evidence trail that matters for compliance and insurance.
What they do not do: verify that the bank account on today's invoice is the same bank account your firm has successfully paid before. They do not check whether a vendor's email domain changed slightly since the last payment cycle. They do not flag that this is the first ACH to a new vendor who was onboarded last week.
Controls govern process. Pre-payment verification governs payee.
The verification gap in one sentence
Controls tell you that the right people approved the payment. They do not tell you that the payment is going to the right place.
3 scenarios where controls let fraud through
Each scenario below represents a fraud pattern seen in 2025–2026. All three bypassed standard AP controls at organizations with documented procedures. In each case, the gap was the same: no one verified the payee details against an independent record at the moment of payment.
Vendor Email Compromise (VEC) — the attack that passes all approvals
A legitimate vendor's email gets compromised. The attacker waits, learns invoice timing and amounts, then sends a PDF that looks exactly right — same logo, correct invoice number format, accurate dollar range. Your approval workflow runs. Three people sign off. The bank account on the PDF is different from every prior payment. No control in your workflow checked that. The wire goes out.
The gap controls miss
Controls verify that the approval process ran. They do not verify that the bank account on this specific invoice matches the vendor's known account.
Bank account change request — the social engineering window
A vendor emails your firm: "We've switched banks — please update our payment details for future invoices." Comes from what looks like the right address. Staff member updates QBO. Next payment goes to the new account. The real vendor emails three weeks later asking about a late payment. The update came from a look-alike domain (vendorcorp.co, not vendorcorp.com) — you just can't see it at a glance.
The gap controls miss
Controls restrict who can update vendor records. They do not independently verify that the update request came from the real vendor before the change is applied.
New vendor — first payment, no baseline
A new vendor is onboarded for a client. New vendor record created in QBO. Invoice arrives. All approvals run. Payment goes out. Three months later, during a client audit, it turns out the vendor entity was created by a former employee who still had a contact inside the firm. First payment to any new vendor has no historical baseline — no prior bank account to compare against, no payment history to validate amount.
The gap controls miss
Controls enforce a process for new vendor onboarding. They do not flag first-time payments for additional scrutiny at the moment of payment.
What pre-payment verification adds
Pre-payment verification runs a different check: at the point of payment, compare the current payee details against an independently maintained record of what this vendor actually looks like. Not what was entered in QBO last week — what was confirmed through prior successful payments and out-of-band verification.
In practice, three checks close most of the gap:
Bank account match
Compare the routing and account number on the current payment against all prior successful payments to this vendor. Any deviation — even one digit — surfaces for human review before the payment releases.
New vendor flag
Every first payment to a vendor that has never been paid before triggers heightened scrutiny. No historical baseline to compare against means the risk is definitionally higher. Require out-of-band confirmation before ACH release.
Amount anomaly
Flag any invoice that is significantly above this vendor's historical average. A vendor who normally bills $1,800–2,200/month submitting a $14,000 invoice is a signal, not a confirmation of fraud — but it requires a look before money moves.
How this applies to accounting firms managing multiple clients
For a firm managing QBO for 15–40 SMB clients, the scale problem is acute. Each client has its own vendor list, its own payment schedule, its own risk surface. Running three verification checks manually — bank match, new vendor flag, anomaly review — for every client's payment cycle is 3–5 hours per week in staff time that doesn't exist.
This is why pre-payment verification for accounting firms needs to run automatically — surfacing only the items that require human judgment, not requiring manual review of every payment. The goal is not to slow down payment cycles. It is to catch the three or four payments per month that have a real flag, before they release.
Nacha Phase 2, which went live June 22, 2026, also requires that firms originating ACH payments maintain a documented, risk-based fraud monitoring program. Pre-payment verification is that program. See the Nacha 2026 ACH fraud monitoring checklist for what the requirement covers.
The case for adding verification to existing controls
Adding pre-payment verification does not require replacing your current AP workflow. It layers on top. Controls stay as-is — approvals still run, permissions still gate access. Verification adds the payee check that controls architecturally cannot do, because controls operate on the process, not the payment destination.
The argument for adding verification is not that current controls are wrong. It is that fraud has adapted to them. Attackers no longer try to circumvent approval workflows — they ride them. They get an invoice approved by the right people because it looks right, because it came from a compromised real vendor, because the amount is plausible. The approval runs. The payment goes to the wrong place.
Verification catches what that. For a deeper look at how fake invoices succeed even with controls in place, see how to detect fake invoices before you pay them.
FAQ
Can strong AP controls prevent vendor fraud?
AP controls — user permissions, approval workflows, dual authorization — significantly reduce casual misuse and internal fraud. They do not, however, verify that a vendor requesting a bank change or submitting an invoice is actually the legitimate vendor. Controls tell you who touched what in your system. Pre-payment verification tells you whether the payee on that specific payment is real.
What is pre-payment verification and how is it different from AP controls?
Pre-payment verification is a check performed at the moment of payment — not at setup — that compares the current payment details (bank account, routing number, vendor identity) against independently confirmed historical data. AP controls govern process. Pre-payment verification governs the actual payee on each transaction.
What percentage of businesses experienced payment fraud despite having controls in place?
According to the AFP 2026 Payments Fraud and Control Survey, 76% of organizations experienced attempted or actual payment fraud in 2025. This figure includes organizations with documented AP controls, multi-level approvals, and staff training — confirming that controls alone do not close the verification gap.
How do you close the gap between AP controls and verified payments?
The gap closes when vendor payment details are verified against an independent, historical record at the point of payment — not just approved through a workflow. Practically, this means flagging any payment where the bank account has changed since the last successful payment, any first payment to a new vendor, and any invoice amount that deviates significantly from that vendor's historical baseline.
Add the verification layer your AP controls are missing
Vantirs runs bank account match, new vendor flagging, and amount anomaly detection automatically across every QBO and Xero client — before each payment cycle releases.