Business Email Compromise: How AP Automation Stops Vendor Fraud

Business email compromise is a fraud in which an attacker uses a compromised or spoofed business email account to redirect a legitimate payment to an account they control. In accounts payable, it almost always arrives as a routine request to update a vendor's banking details.

The reason BEC works so well against finance teams is that nothing about it looks wrong. There's no malicious attachment, no misspelled domain, no urgent stranger asking for gift cards. The attacker has usually been reading the vendor's mailbox for weeks, waiting for a real invoice in an active thread, and the message they eventually send is grammatically fine, contextually accurate, and sent from an address your AP team has corresponded with for years.

That's what separates this from the fraud most training programs prepare people for. You aren't asking an AP specialist to spot a scam. You're asking them to notice that one field in an otherwise ordinary email is different from what's on file, in a message they have every reason to trust.

Key Takeaways

• BEC has caused tens of billions of dollars in exposed losses worldwide since 2013, and the reported figure is still climbing year over year, according to FBI IC3 data.

• The AP-specific version is a banking-change request inside a real vendor email thread, which is why domain checks and attachment scanning miss it entirely.

• Manual verification depends on one person choosing to make a phone call, which is a habit rather than a control.

• Validating supplier banking independently at enrollment and on every change removes the attacker's payoff, because an emailed account number never becomes a payment instruction on its own.

• Moving spend off checks and manual wires onto controlled rails shrinks the surface a successful BEC attempt can reach.

• Red-flag training still matters, but it should be the second layer, not the only one.

Why does business email compromise target accounts payable?

Business email compromise is a social-engineering fraud that uses trusted email access to redirect legitimate funds. Attackers target accounts payable because AP is the one department whose ordinary job is moving money to external parties on written instruction, at volume, on a schedule.

The scale is hard to overstate. The FBI's Internet Crime Complaint Center reported $55,499,915,582 in global exposed losses across 305,033 BEC incidents between October 2013 and December 2023, with U.S. domestic victims accounting for $20,089,561,364 across 158,436 cases. IC3 also found that global identified exposed losses rose 9% between December 2022 and December 2023, so this isn't a threat that's aging out as email security improves.

Finance-side survey data tracks the same direction. About three in four organizations (74%) were affected by business email compromise in 2025, according to AFP's 2026 Payments Fraud and Control Survey Report. When a fraud type touches that share of organizations, treating it as an edge case in your control design is a choice with a cost attached.

What is the difference between BEC and phishing?

Phishing casts a wide net to harvest credentials or deliver malware; BEC is a targeted deception aimed at a specific payment, usually with no malicious payload at all. Phishing wants access. BEC already has it, and wants a transfer.

The practical difference is what your defenses can see:

The distinction matters because email security tooling is scored on the left column and BEC lives in the right one.

Because BEC carries no payload, it slips past the tools most companies count on. That's the mechanism behind eight ways fraud emails compromise the back office, and it's why the countermeasure has to sit in the payment process rather than the inbox.

What does a BEC attack on AP actually look like?

It looks like a reply to an email you already sent. The attacker gains access to a vendor's mailbox, watches until a genuine invoice is in flight, then responds within that same thread with updated remittance details and a light reason for the change.

An AP practitioner described exactly this sequence on r/Accounting after a near-miss on a six-figure wire. An attacker sat inside their vendor's email for weeks before making a move, waited for a real invoice in an active thread, replied with updated banking details, and asked the team to process before month end. Same thread, same sender, real invoice number. Another poster summarized the same experience more bluntly: same Gmail thread, same sender name, same invoice format they'd seen plenty of times before, and the only thing that changed was the bank account number.

The tell in most of these cases is the timing rather than anything in the message itself. The banking change lands two or three days before a scheduled payment run, in a thread that's been quiet for a week, with a soft deadline attached. Attackers understand AP calendars better than most AP teams expect, and the sub-type where the vendor's own mailbox is the launch point has become common enough to earn its own name, covered in how to identify vendor email compromise.

Why do manual defenses against BEC keep failing?

Because the standard defense is "call the vendor to verify," and that depends on an individual noticing something worth verifying. Verification that runs only when someone feels uneasy isn't a control, it's a reflex, and reflexes fail under deadline pressure.

The evidence on detection methods makes this concrete. ACFE's Occupational Fraud 2024: A Report to the Nations found that 43% of occupational frauds are first detected by a tip, with employees supplying 52% of those tips, rather than by any designed control. Tips are valuable, and I'd rather have a culture where people speak up than not. But when your leading detection method is somebody deciding to say something, the system underneath isn't doing the work.

There's a second reason manual defenses underperform, and it's structural rather than behavioral. Verizon's 2024 Data Breach Investigations Report found that 68% of breaches involved a non-malicious human element, meaning a person who was tricked or made an error rather than an insider acting deliberately. Any control whose final step is human judgment inherits that failure rate.

If your banking-change process today is "AP calls the number on the invoice," that's the single highest-value thing to change this quarter.

Why is the AP clerk the wrong last line of defense?

Because almost no one in that seat was trained for it. Accounting curricula and firm training cover controls in the abstract, but very few finance professionals have ever been shown what a fraudulent invoice or a compromised vendor thread actually looks like in practice.

One r/Accounting post captured the gap in a single line: five years of accounting education, two firms, one industry role, and not a single conversation about what a fraudulent invoice looks like in practice. The thread drew hundreds of upvotes, which tells you how widely that experience is shared.

Put the incentives next to the training gap and the picture gets worse. The AP specialist is measured on throughput, works a queue with a deadline, and is the most junior person in the approval chain. Asking them to be the organization's fraud filter puts the least-trained, most time-pressured person at the point of highest financial consequence. The controls that actually work are the ones described in how AP fraud schemes operate, and none of them rest on individual vigilance.

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 are the red flags, and why aren't they enough on their own?

Red flags are useful for catching the mediocre attempts, which is a real fraction of the total. They stop being sufficient once the attacker has genuine mailbox access, because most of the classic signals are absent by construction.

The signals still worth training on:

• A banking-detail change that arrives by email, in any form, from any sender.

• Urgency tied to a payment deadline, especially near month end or a scheduled run.

• A reply-to address that differs from the display name's usual address.

• A request to keep the change between the sender and the recipient, or to skip a normal approver.

• Small inconsistencies in remittance formatting or invoice layout against prior documents from the same vendor.

• New banking details at a bank in a different region than the vendor's operations.

Here's the honest caveat. In a well-executed vendor email compromise, the sender is real, the domain is real, the thread is real, and the invoice is real. Four of the six signals above are simply not present. Red-flag training raises the floor and it should be part of onboarding, but building your defense on it means accepting that the best-executed attacks are the ones that get through. The related patterns in how social-engineering fraud works against finance teams show how quickly attackers adapt once a signal becomes widely taught.

How does AP automation stop BEC before payment goes out?

AP automation stops BEC by moving verification out of the inbox and into the payment system, so a banking change can't become a payment instruction without passing an independent check. The email becomes a request, not an authorization.

Four mechanisms do the work, and they're most effective stacked:

1. Supplier banking validated at enrollment and re-validated on every change, through a channel the requester doesn't control.

2. Approval workflow that holds any payment to a recently changed account until verification completes and is recorded.

3. MFA-protected supplier portals, so banking updates happen in an authenticated system rather than as free text in a message.

4. Payment rails that limit what a successful redirect can reach.

Only 17% of organizations currently use AI to help combat payments fraud, per AFP's 2026 survey, which is a striking number given that more than three-quarters of organizations (76%) experienced attempted or actual payments fraud in 2025. Most of the detection work here comes down to making the verification step a system requirement rather than a personal habit, and automated invoice processing that reduces payment fraud is where that requirement gets enforced. The same pre-payment layer runs duplicate payment detection against payment history, since both controls fire at the one point where stopping a payment still costs nothing.

How does validating supplier banking neutralize the bank-change trick?

Independent validation neutralizes it by confirming that the account belongs to the vendor of record, using a source outside the email thread that requested the change. If the account can't be tied back to the legitimate business, the change never takes effect and no payment is exposed.

The mechanism matters more than the label. Validation means checking account ownership against the vendor's registered identity, not simply confirming that the account number is well-formed or that the routing number exists. An attacker's mule account will pass a format check every time. It won't pass an ownership check against the vendor's legal entity. Working through how vendor verification and banking validation work in practice is what turns that check into a repeatable step rather than a judgment call.

Doing this by hand at scale is where most programs break down. A finance team with several thousand active suppliers can't independently validate every banking change without adding headcount, so the process quietly degrades into "call the number on file, and if nobody answers, proceed." That degradation is invisible until it isn't, and it's the strongest practical argument for a managed approach where verification runs as a service rather than as an individual's task list. Sequencing that work properly inside vendor master file governance is what keeps it from becoming optional under load.

How do controlled payment rails shrink the attack surface?

Controlled rails shrink the surface because a redirected payment can only be as damaging as the instrument it travels on. A wire is irreversible and untraceable within hours; a virtual card number is issued per transaction with a fixed limit and a defined merchant.

Checks are the clearest example of the problem. 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 a check carries your account and routing numbers to every party who handles it. Every check you mail is a small disclosure of the credentials an attacker needs. The dynamics behind the rise of check fraud and how AP automation blunts it apply directly to BEC, because both attacks monetize the same weak instrument.

Virtual cards and validated ACH change the arithmetic. Card payments settle to an enrolled merchant account with a set amount, so a fraudulent banking change has nothing to redirect. Validated ACH still moves to an account, but one that passed an ownership check before it was payable. Neither eliminates BEC attempts. Both cap what a successful one collects.

What should a BEC-resistant payment process include?

A BEC-resistant process makes verification structural, so that no single person's judgment stands between a fraudulent request and a released payment. Six elements cover most of the exposure:

1. Out-of-band verification of every banking change, using contact details from your vendor master rather than from the request.

2. A mandatory hold period on payments to any account changed within a defined window, with the hold enforced by the system rather than by policy memo.

3. Segregation of duties so that no one who can edit a vendor record can also release a payment to it.

4. Approval thresholds that escalate by amount, with dual approval above a documented limit.

5. Vendor master governance covering onboarding, periodic re-validation, and deactivation of dormant records.

6. A rail strategy that moves recurring and high-risk spend off checks and manual wires.

Verizon's data offers one more useful calibration. BEC, measured as pretexting, accounted for roughly a quarter of financially motivated attacks with a median loss of about $50,000 per incident. That median is instructive, because it sits below the threshold where most companies require dual approval. Attackers have read the same policies you have, and they size requests to clear your controls rather than trip them. Setting escalation thresholds against that median rather than against your largest payments is a small change with an outsized effect, and the controls that gate a payment at approval are where it gets implemented.

How do you verify a banking-detail change the right way?

Out of band, against contact details you already hold, with the result recorded in the system. That's the whole rule, and each clause is doing work.

Out of band means a different channel than the request arrived on. If the change came by email, verify by phone. Against details you already hold means using the phone number in your vendor master or on a prior contract. Never use the number in the signature block of the message requesting the change, since the attacker controls it. Recorded in the system means the verification gets logged against the vendor record with a name, a timestamp, and a method. An auditor can then confirm it happened, and a colleague can see it without asking.

One refinement worth adopting: verify with a person you've spoken to before, not whoever answers. Attackers with mailbox access can often see who at the vendor your team normally deals with, and a call routed to a general line is easier to intercept than a call to a known contact. The broader set of practices in security measures that protect the business and in how to defend your company from payment fraud covers the surrounding hygiene, but this one step prevents the majority of AP-targeted BEC losses on its own.

Build BEC out of your payment process with Corpay

The scenario worth designing against is the one that AP lead described: weeks of quiet access, a real thread, a real invoice number, a soft month-end deadline, and one changed field. Their save came from a phone call somebody decided to make. That's a good outcome produced by an unreliable process, and repeating it across thousands of vendor interactions a year isn't something you can staff for.

Corpay's payments automation makes that verification a system step. We validate supplier banking details at enrollment and again on every change, so an emailed account number never becomes a payment instruction on trust alone. Approval controls hold payments to recently changed accounts, MFA-protected portals keep banking updates inside an authenticated system, and moving spend onto virtual card and validated ACH limits what any successful attempt can reach. The managed service runs supplier outreach and verification on your behalf, which is the part that usually degrades when a team tries to hold the line manually.

Corpay works with more than 800,000 businesses, and that volume is what makes supplier verification practical as an ongoing service rather than a project you resource once and let lapse.

See how Corpay's payments automation validates supplier banking before funds move, or review the full AP automation platform to see how the controls fit alongside your ERP.

Frequently Asked Questions

What is business email compromise?

Business email compromise is a fraud in which an attacker uses a compromised or spoofed business email account to redirect a legitimate payment to an account they control. It carries no malware and relies entirely on the trust already established in the email relationship.

What is an example of a business email compromise?

A common example is an attacker gaining access to a supplier's mailbox, waiting for a genuine invoice to be sent, then replying in that same thread with updated banking details and a request to pay before month end. The invoice, sender, and thread are all real.

How is vendor email compromise different from BEC?

Vendor email compromise is a sub-type of BEC where the compromised mailbox belongs to your supplier rather than to your own company. It's harder to detect because every technical signal, including the sending domain and authentication records, is legitimate.

Who inside a company does BEC usually target?

Accounts payable staff and anyone with payment-release authority, along with executives whose names lend authority to a request. Attackers research org charts and finance calendars, so the target is typically a specific named person with a known role in the payment chain.

Can a payment sent because of BEC be recovered?

Sometimes, and speed determines everything. The FBI's Internet Crime Complaint Center advises contacting your bank immediately to request a recall and filing a report as soon as the fraud is identified, since funds are often moved onward within hours of landing in the receiving account.

Does moving vendors off checks and manual wires reduce BEC risk?

Yes, by capping the damage rather than preventing the attempt. Virtual card payments settle to an enrolled merchant for a fixed amount, and validated ACH moves only to accounts that passed an ownership check, so a fraudulent banking change has far less to redirect.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

AP Automation

Risk management