The invoice was real, the vendor was real, and the bank account belonged to someone else

The most effective form of accounts payable fraud does not involve a fake invoice.

It involves a real invoice from a real vendor for real work, submitted with updated banking details. Everything about the transaction is legitimate except where the money goes, which is why every control aimed at document authenticity misses it entirely.

Why this attack works on competent teams

Three things line up in its favor.

The request is routine. Vendors change banks. They get acquired, switch to a factoring company, or move from a check to ACH. An AP clerk sees legitimate versions of this request several times a year, so it does not register as unusual.

The email may genuinely be from the vendor. If the vendor's own email account has been compromised, the message comes from the correct address, in the middle of a real thread, sometimes replying to your own earlier email. Header inspection finds nothing because there is nothing wrong with the headers.

Timing pressure is manufactured. The request arrives alongside an invoice that is due, or near your payment run, and often with a note about avoiding a late fee. The pressure is the mechanism, because the control that stops this is a phone call and time pressure is what makes a phone call feel like an overreaction.

Notice that none of this is defeated by better document analysis. The invoice is real.

One control stops nearly all of it

A change to vendor banking or remit-to details is never accepted from an email, an invoice, or a portal submission. It requires an outbound call to a phone number already in your vendor master, placed to a person you can identify, and it requires a second employee to record that the verification happened.

Four specifics that matter and are commonly skipped.

Outbound, to a number you already had. Not a number in the email requesting the change. Not a number on the new invoice. The number on file from onboarding.

A person, not a voicemail. A voicemail confirmation is not a confirmation.

A second person records it. The employee who received the request should not be the only one who verified it, because the attack sometimes includes social engineering of that specific person.

No exceptions for urgency. The entire attack depends on somebody waiving the control once. A policy with an urgency exception has no policy.

Four other patterns worth naming

Fictitious vendor. A vendor created in the master by someone with access, invoiced for plausible services at a plausible amount. Caught by segregation of duties between vendor creation and payment approval, and by periodic review of vendors added in the last quarter with no purchase orders.

Invoice inflation with a real vendor. A genuine vendor billing above the agreed rate, sometimes with an internal accomplice approving it. Caught by price validation against a PO line price rather than by reviewing the invoice.

Approval impersonation. An email appearing to come from a controller or an owner instructing a payment to be made outside normal process. Caught by having no out-of-process payment path at all, which is a policy decision rather than a detection problem.

Duplicate submission with intent. A vendor resubmitting a paid invoice with a changed number, relying on your process not catching it. Caught by fuzzy duplicate detection rather than exact matching.

Each of these has a different control, and a program that has only document verification has covered none of them.

Segregation of duties is the structural control

The single most important design principle, and the hardest to maintain at a small AP team.

Four capabilities that should not all sit with one person: creating or editing a vendor record, approving an invoice, releasing a payment, and reconciling the bank account.

At a two-person AP function you cannot fully separate four things. What you can do is separate the two that matter most, which are vendor master editing and payment release. Anyone who can both create a payee and pay them has the whole capability in one seat.

Where the team is genuinely too small, compensating controls: a monthly review of all vendor master changes by someone outside AP, and a review of new vendors with payments in their first ninety days.

What the system contributes and what it cannot

Where BillRoute helps: validation against the supplier master, so a supplier code that does not match surfaces as a named Supplier Code Mismatch error rather than passing through. Price validation against PO line prices. Duplicate detection before approval. A full audit trail across capture, coding, approval, and posting, timestamped with user attribution, which is what an investigation needs afterward.

On the payment side, payment approvals are separate from invoice approval workflows, which is a segregation control rather than a convenience. Money movement runs through Stripe with funds held in FDIC-insured accounts at Fifth Third Bank N.A., and the vendor manages their own banking details and payment preferences in a vendor portal rather than emailing them to your AP team.

That last point is worth dwelling on, because it changes the attack surface rather than just detecting the attack. A vendor who maintains their own banking details in an authenticated portal is not sending them to you by email, which removes the channel the fraud uses. It does not remove the risk entirely, since a compromised vendor portal account is its own problem, and it is a better structure than an inbox.

What we do not do, stated plainly:

We do not verify a banking change. The callback control above is a human process, it is the most important control on this page, and no software step replaces it.

We do not detect a compromised vendor email account.

We do not recover funds that have left. Once a payment settles to a fraudulent account, recovery depends on the banks and on speed, and it is frequently unsuccessful.

One sentence of policy, approved this week

One sentence, and get it approved: banking and remit-to changes require an outbound call to the number on file, confirmed by a second employee, with no exception for urgency.

Then ask your AP team how many banking changes they processed in the last year, and how many were verified that way.

What was the answer?