What the FBI's 2025 BEC Numbers Mean for How You Verify a Vendor Payment

Business email compromise cost US businesses $3.05 billion in reported losses in 2025, up from $2.77 billion in 2024, according to the FBI's 2025 Internet Crime Report. Most of that money did not leave through a hacked bank account or a cracked password. It left because someone in accounts payable updated a vendor's bank details, or approved an invoice, based on an email that looked right.

That is the part the dollar-figure headlines skip. The FBI's Internet Crime Complaint Center (IC3) logged 24,768 business email compromise (BEC) complaints in 2025, up from 21,442 the year before, and the loss total climbed with it. The number that should land hardest on an AP desk is not the $3.05 billion. It is that the FBI's Recovery Asset Team froze more than $507 million in fraudulent domestic wires in 2025, which means the money is usually still sitting somewhere, reachable, for the first 24 to 72 hours after a bank flags it as suspicious, according to the same IC3 report. Speed of detection decides whether a company gets that money back.

How much did business email compromise cost US businesses in 2025?

$3,046,598,558, across 24,768 complaints, per the FBI's 2025 Internet Crime Report. That is up from $2.77 billion across 21,442 complaints in 2024. BEC is now the second-costliest category the IC3 tracks, behind investment fraud, and it is the one category that routes almost entirely through accounts payable and payroll workflows rather than through a stolen credential or a ransomware payload.

For a services firm paying subcontractors on MSAs and SOWs, the exposure is specific: BEC scams most often impersonate a vendor the company already pays, not a stranger asking for money. The attacker does not need to break into anything. They need to know who you pay, how much, and when - information that sits in plain sight in a rate card, a signed SOW, or a public invoice sent to the wrong recipient once.

How a vendor-impersonation invoice scam actually plays out

The pattern repeats enough that it is worth walking through once, plainly:

1. A vendor's email account is compromised, or a look-alike domain is registered (the real domain with one letter swapped, or a different top-level domain).
2. The attacker watches the vendor's outgoing invoices and email threads for a few days or weeks, learning the cadence: when invoices go out, who approves them, what the amounts usually look like.
3. Near a normal invoice date, the attacker sends a message - sometimes from the compromised real account, sometimes from the look-alike - saying the vendor has changed banks and asking AP to update the file before the next payment.
4. The next invoice comes in at a normal amount, for normal work, and gets paid to the new account.

Nothing about the invoice itself looks wrong. The PO matches, the amount matches the rate card, the line items are real. The only thing that changed is where the money goes, and that change arrived by email, which is exactly the channel BEC is built to exploit. Quittance's writeup on invoice fraud versus payment fraud covers why a correctly matched invoice can still be the one that gets paid wrong - this is the mechanism.

Why a vendor bank-account change is the single biggest blind spot

Most AP controls are built to catch errors in the invoice: wrong amount, wrong PO, duplicate submission, rate-card mismatch. A bank-account change request usually is not an invoice at all - it is an email, sometimes a phone call, and it often bypasses the approval workflow entirely because "updating a file" does not feel like the same risk as "approving a payment." It is the same risk. Updating the bank record is the fraud; the invoice that follows is just the payout.

This blind spot is well documented outside of BEC statistics, too. A separate Quittance review of vendor bank-detail practices found that most firms do not have a standing process for revalidating a vendor's bank details once they are on file, which means the first verification a vendor ever gets is also, often, the last.

What to verify before you update a vendor's bank details

Treat a bank-change request as a security event, not a data-entry task. Before anyone edits the vendor record:

• Call the vendor back on a number you already have on file - not a number provided in the email or letter requesting the change. If the only number you have is in the same message, you have not verified anything.
• Confirm with a known contact, by name, not a generic inbox. "Accounts receivable" replying to its own change request is not independent confirmation.
• Check the sending domain character by character. Look-alike domains swap a letter, add a hyphen, or use a different extension (.co instead of .com).
• Ask why the account changed, and expect a plausible, checkable answer (a bank merger, a new business entity) rather than urgency with no explanation.
• Hold the next payment until the callback confirms the change, even if that means paying a day or two late. A short delay costs nothing next to a wire that cannot be clawed back.
• Log the change and who approved it. If something goes wrong, you want to know in minutes who touched the record, not after a week of searching an inbox.

Verification channel	What it actually proves	Should you rely on it alone?
Reply to the email requesting the change	Nothing - you are replying to the attacker if the account is compromised	No
Phone call to a number in the same email or letter	Nothing - the attacker can staff that number	No
Phone call to a number already on file before the request	The person on the line has access to the vendor's known line	Yes, as the primary check
Vendor portal login with existing credentials	The requester controls the vendor's existing account	Yes, if the portal itself has not been compromised
A second employee independently confirming through a different channel	Two people, two channels, have to be wrong at once	Yes, best when paired with a callback

How to spot a BEC-style invoice before it reaches approval

A few signals show up often enough to be worth a standing check, even when the invoice amount and line items look clean:

• The invoice references a PO or contract number that does not exist in your system, or references one that exists but under a different vendor.
• The remittance details do not match the vendor's last confirmed bank record, even by one digit.
• The request arrives with unusual urgency - end of day, end of quarter, "the client is waiting."
• The sender's reply-to address does not match the sender's display name on close inspection.
• The invoice amount sits just under a dollar threshold that would normally trigger a second approval.

None of these alone proves fraud. Together, or even two at once, they are reason enough to hold the invoice and verify before it posts. Quittance's breakdown of a recent AI-generated fake invoice covers how these signals look on paper when the invoice itself is machine-generated and visually convincing.

What to do if a payment has already gone out

Minutes matter more than anything else here. The sequence that gives a company the best shot at recovery:

1. Call your bank immediately and request a wire recall or SWIFT recall. Banks can sometimes halt or reverse a transfer before it settles on the receiving end, but the window is short - often hours, not days.
2. File a complaint with IC3 at ic3.gov as soon as possible. The FBI's Recovery Asset Team only works fraudulent-wire cases reported quickly, and froze more than $507 million in 2025 precisely because victims reported fast, per the 2025 Internet Crime Report.
3. Notify the real vendor through a verified channel, since their email or systems may still be compromised and other customers may be at risk.
4. Preserve everything - the original email, headers, the altered invoice, any portal logs - before anyone "cleans up" the record.
5. Review every other vendor bank-detail change in the same period. If one vendor record was compromised, check whether the attacker touched others.

Absorb the work before the next hire, not instead of a person

None of this is solved by hiring faster or by trusting software to approve payments on its own. The honest frame is to absorb the verification work that is already falling through the cracks - the callback that does not happen, the bank-detail change nobody logs - before adding headcount to do it by hand, not to replace the person who reviews and approves. Agreement-aware AP tools like Quittance flag a changed bank account, a payee mismatch, or an invoice citing a PO that does not exist before anything posts to the books, but a human still approves every payment. That is a design choice, not a limitation: the fraud gate is there to stop a bad payment from reaching a person's approval screen looking clean, not to remove the person from the decision.

FAQ: business email compromise and invoice payments

How much did BEC cost US businesses in 2025? The FBI's IC3 received 24,768 BEC complaints in 2025, totaling $3,046,598,558 in reported losses, up from $2.77 billion in 2024, according to the FBI's 2025 Internet Crime Report.

What is the single most common way BEC scams reach accounts payable? By impersonating a vendor the company already pays and requesting a bank-account change, usually by email, shortly before a normal invoice is due. The invoice itself typically matches the PO and rate card; only the payment destination is wrong.

Can money sent in a BEC scam be recovered? Sometimes, if it is reported fast. The FBI's Recovery Asset Team froze more than $507 million in fraudulent domestic wires in 2025, per the same IC3 report, but recovery depends on calling the bank and filing an IC3 complaint within hours, not days.

Should AP ever update a vendor's bank details based on an email alone? No. Confirm any bank-detail change with a phone call to a number already on file before the request arrived, not a number supplied in the email itself, and hold the next payment until the callback confirms it.

Does matching the invoice to the PO catch a BEC-style scam? Not on its own. A BEC invoice is often a real amount for real work matched to a real PO - the only thing wrong is the payee's bank details, which PO matching does not check. See Quittance's review of invoice fraud versus payment fraud for why a matched invoice can still be paid wrong.