FlowParse
Article August 2026 22 min read

How invoice fraud actually works

Invoice fraud rarely looks like fraud. It looks like an ordinary invoice from an ordinary supplier, sent at an ordinary time, for an amount that isn't even alarming — and that's exactly why it works, and exactly the gap in a normal approval process it's built to exploit.

FlowParse
flowparse.io
flowparse.iosound off is fine
0:00 / 0:00

It rarely looks like fraud

Most people picture invoice fraud as something obviously wrong — a badly formatted document, a strange supplier name, a huge implausible amount. The invoices that actually succeed look nothing like that. They look like an ordinary invoice from an ordinary, familiar supplier, sent at a time that doesn't stand out, for an amount that's well within what that supplier normally charges.

That resemblance to the ordinary isn't an accident — it's the entire design. This article walks through the schemes that actually succeed, why they work even against careful, experienced finance teams, and the specific gap in a typical approval process that each one is built to exploit.

The four schemes behind most invoice fraud

Almost every real-world case falls into one of a small number of recognisable patterns. Knowing the pattern in advance is what makes it possible to recognise a live attempt before it becomes a completed payment.

Vendor impersonation

A fraudster poses as an existing, trusted supplier and requests a change to bank details, then waits for the next routine invoice to be paid to the new account.

Business email compromise (BEC)

A real email account — a supplier's, or an executive's — is compromised or convincingly spoofed, and used to issue an urgent, seemingly authoritative payment instruction.

Ghost vendor

A fake supplier is created from scratch, invoicing for goods or services that were never actually delivered, often relying on weak onboarding checks for new suppliers.

Altered legitimate invoice

A real invoice, intercepted in transit, has its bank details changed before it reaches the person who approves payment.

FlowParse
flowparse.io

Why it works on careful people

It isn't that finance teams are careless. A normal approval process checks that an invoice is internally consistent — the math adds up, the format looks right, it's been through the expected sign-offs. A well-executed fraud passes every one of those checks, because it's built specifically to.

What it usually can't convincingly fake is the pattern of a real, ongoing relationship — the exact amount range a supplier tends to invoice, the exact cadence it tends to invoice on, and above all the exact bank account it has always been paid to. A review that never compares a new invoice against that history has no way to catch a fraud that's internally flawless but historically inconsistent.

FlowParse
flowparse.io

The anatomy of a typical scheme

StageWhat happens
ResearchThe fraudster identifies a real supplier relationship, often via a prior email compromise somewhere in the chain
ContactAn email or letter arrives — from a spoofed or compromised account, or a convincing lookalike domain — announcing new bank details
WaitThe fraudster waits for the next routine, expected invoice rather than requesting an unusual out-of-cycle payment
CollectThe legitimate-looking invoice is paid to the new, fraudulent account before anyone notices the mismatch

The waiting stage is the part most people underestimate. A patient fraudster who lets a routine invoice cycle happen naturally, rather than pushing for an urgent one-off payment, avoids exactly the kind of red flag that trained finance teams are told to watch for.

Every stage in this sequence is designed to look unremarkable on its own — which is exactly why catching it requires comparing against history, not just judging each stage in isolation.

A scheme, traced

A mid-sized business, a five-year supplier relationship, one bank-detail change request that arrived by email.

StepWhat was found
Request receivedAn email, from a domain one character different from the real supplier's
Compared against baselineBank details differed from five years of consistent prior payments
FlaggedHeld pending verification before the next scheduled invoice was due
VerifiedA call to the number already on file confirmed the real supplier never sent the request

The one-character domain difference had gone unnoticed by three people who had each glanced at the email in passing. What actually caught it wasn't a sharper eye — it was the comparison against five years of consistent bank details, a comparison none of those three people had reason to make manually.

FlowParse
flowparse.io

How to close the gap without a forensic investigation

Catching every scheme with certainty would require resources most businesses don't have and don't need. A lighter, more practical approach catches the overwhelming majority: compare every invoice, especially every bank-detail change, against the supplier's own documented history before payment, not after.

That single comparison — this invoice against this supplier's pattern — is the one step most manual review processes skip, simply because holding a year of history in mind while reviewing today's invoices isn't realistic without it being written down somewhere reliable.

FlowParse
flowparse.io

Scenario: the urgent email from the CEO

An email arrives in the accounts payable inbox, apparently from the company's CEO, requesting an urgent wire transfer to close a confidential acquisition — with explicit instructions not to discuss it with anyone else before it's done, and to bypass the normal approval chain given the time pressure.

Every element of the request is designed to short-circuit normal verification: urgency discourages a careful second look, secrecy discourages checking with a colleague, and seniority discourages questioning the instruction at all. The email address, on close inspection, differs from the CEO's real one by a single character.

A policy that treats “urgent, confidential, bypass the normal process” itself as the primary red flag — regardless of who appears to be asking — stops this scheme before it starts, because the request's own urgency is the tell, not something that needs to be separately detected.

FlowParse
flowparse.io

Scenario: the supplier that switched banks

A long-standing supplier sends a routine notice: due to an internal restructuring, future payments should go to a new bank account. The email is professionally written, references real past invoice numbers, and arrives from what looks like the supplier's usual contact.

Nothing about the email itself looks obviously wrong — which is exactly the point. What would catch it is a verification call placed to a phone number the business already had on file before the email arrived, not any number the email itself provides, confirming directly with a known contact that the change is genuine.

In a real version of this scenario, that call revealed the supplier had never sent any such notice — the account belonged to the fraudster, and the professional tone and real invoice numbers had been lifted from a previously compromised email thread.

FlowParse
flowparse.io

What made this particular case findable at all wasn't suspicion of the email itself, which read as entirely genuine — it was the fact that the new account simply didn't match anything in years of recorded prior payments, a mismatch invisible to anyone reading the email alone but immediate the moment it was compared against documented history.

What businesses actually do about it

Situation foundTypical response
A bank-detail change requestHold any pending payment and verify through a previously trusted contact before releasing it
A confirmed fraudulent invoiceReport to the bank immediately, request a recall, and notify the relevant authority
A suspicious but unconfirmed emailEscalate for a second opinion rather than deciding alone under time pressure
A pattern of near-miss attempts on one relationshipAdd extra verification specifically for that supplier going forward

None of these responses require a specialist fraud investigator on staff — they're specific, practiced steps that work because the team already knows them before the moment they're actually needed.

Three businesses, three levels of control

The same underlying exposure to fraud, handled with three different levels of rigour.

BusinessWhen it catches a schemeRoom to act
A — no baseline comparisonAfter the payment has already clearedMinimal — recovery odds drop fast after transfer
B — informal 'we'd notice' confidenceSometimes, if someone happens to rememberLimited — depends entirely on memory
C — documented baseline, verified changesBefore the payment is releasedWide — the transfer never happens

Business A and Business C face exactly the same attempts — the difference isn't in how often fraud is attempted, it's in how much time and evidence exists to catch it before the money actually moves.

FlowParse
flowparse.io

Common mistakes

Verifying a bank-detail change using contact details from the request itself

Confirms nothing — a fraudulent request routinely supplies its own fraudulent contact details.

Treating urgency as a reason to skip verification instead of a reason for more of it

Urgency and secrecy are the two most common pressure tactics precisely because they work.

Assuming a well-formatted, professional invoice can't be fraudulent

Professional presentation is trivial for a motivated fraudster to replicate; it proves nothing about authenticity.

Relying entirely on staff training without a documented verification step

Training helps, but a specific, mandatory procedure catches what an unaided, busy reviewer misses.

Waiting for an annual review to check for patterns of attempted fraud

By then, a live scheme has had months to succeed before anyone connects the dots.

FlowParse
flowparse.io

Building a simple verification routine

None of this requires a dedicated fraud team. A short, written routine covering four points is enough for most businesses to move from “we'd probably notice” to a concrete, repeatable process.

How every bank-detail change gets verified, and through exactly which trusted channel.

Who's authorised to approve a change once verified, so it's never a single person's informal call.

How urgent or confidential payment requests get handled, with urgency itself treated as a signal for more scrutiny.

Who reviews the flagged list each period, and how resolutions get documented for next time.

Four sentences, and the difference between a business that hopes it would catch a scheme and one with a specific, practiced routine for actually doing it.

FlowParse
flowparse.io

Why banks and insurers care

A receiving bank asked to recall a fraudulent transfer moves faster and more effectively the sooner it's notified — many banks measure the window for a realistic recall in hours, not days, which is precisely why the speed of detection matters as much as the detection itself.

Cyber and crime insurance policies that cover this kind of loss typically ask, at claim time, what verification process was in place before the fraudulent payment was released — a documented routine, consistently followed, is exactly the evidence an insurer looks for when assessing whether reasonable care was taken.

For a business preparing for a sale or a significant financing round, due diligence increasingly includes a look at fraud controls specifically — a documented, followed verification routine is a straightforward answer to that question; an informal “we'd probably notice” is not.

FlowParse
flowparse.io

How this differs by industry

A business with a small, stable supplier base — a professional services firm working with the same handful of vendors for years — faces a relatively contained version of this problem: fewer relationships to monitor, and deviations from a well-established pattern stand out more clearly.

A business with a large, frequently changing supplier base — construction, wholesale distribution, businesses onboarding new vendors constantly — faces a structurally harder version, because a fraudulent new supplier can hide among dozens of genuinely new, legitimate ones with equally thin history.

Neither situation calls for a different underlying method — comparing every invoice against documented history and verifying every bank-detail change. What changes is how much weight to put on thin-history relationships, which deserve closer scrutiny precisely because there isn't yet enough pattern to lean on.

FlowParse
flowparse.io

A business that caught it in time

A regional distributor working with around 60 active suppliers had never formally compared incoming invoices against supplier history — payments were approved based on whether the invoice itself looked legitimate and had the right sign-offs.

After introducing a baseline comparison, following the method described in this article, the first month surfaced two bank-detail change requests among the routine flow of invoices. One was genuine — a supplier had actually switched banks and could confirm it by phone immediately. The other did not check out: the phone number on file for that supplier had no record of any such change, and further investigation confirmed the request had come from a spoofed domain.

The payment tied to the fraudulent request was still pending at the time it was flagged, and was held before it ever reached the fraudulent account. The same comparison, run every period going forward, now catches this kind of attempt as a matter of routine rather than luck.

FlowParse
flowparse.io

What happens after a fraud succeeds

When a fraudulent payment does clear, the window to act well is short and closes quickly. The first hours matter most — contacting the receiving bank to request a recall, notifying the sending bank's fraud team, and reporting to the relevant authority, all as close to immediately as possible.

Recovery is never guaranteed, and it becomes markedly less likely the longer a fraud goes unnoticed — funds moved through a fraudulent account are often transferred onward within hours, specifically to make recall harder. This is the practical argument for detection speed over detection perfection: catching a scheme a day late is dramatically better than catching it a month late, even if neither is instant.

A documented incident afterward — what was found, when, and what the resolution was — feeds directly into the next section's multi-year history, turning a single bad experience into durable, institutional protection against the next attempt.

FlowParse
flowparse.io

It's also worth being candid internally about what happened, rather than treating it as an embarrassment to bury. A business that discusses a near-miss or a real loss openly with its own team tends to catch the next attempt faster, because the people who process payments have actually seen what a real scheme looked like, not just an abstract description of one.

What a multi-year flag history teaches you

A single flagged attempt answers an immediate question: was this one thing real. A history of flags, tracked over several years, answers a more useful one: which suppliers or which types of request draw the most attempts, and whether the volume of attempts is rising as the business grows and becomes a more visible target.

Building that history doesn't require a separate project — it's simply every flag and its resolution, kept as a record instead of discarded once resolved. Each period adds a data point that, combined with the ones before it, reveals a pattern no single incident could show on its own.

Businesses that reach several years of this kind of record often find attempts cluster around specific, identifiable moments — right after a public announcement that names a supplier or an executive, for instance, which gives a fraudster the specific names and context needed to write a convincing request.

FlowParse
flowparse.io

That kind of specific, timing-aware pattern is worth more to a controller than a general instruction to “stay vigilant” — it points directly at the moments when extra scrutiny actually pays off.

Preventing the next attempt, not just catching this one

Catching a single fraudulent request feels like a win, and it is — but it doesn't address whatever made the attempt plausible in the first place. If a fraudster successfully spoofed a supplier's domain once, the same supplier relationship is a known, proven target for a repeat attempt.

The more durable response is process-level: flag that specific supplier relationship for permanent extra verification, review whether the original information leak — often a prior email compromise somewhere in the chain — has actually been closed, and share the specific pattern with the team so the next similar attempt is recognised even faster.

FlowParse
flowparse.io

Weighing the cost of controls against the risk

Not every business needs the same intensity of fraud controls. A business paying a handful of long-standing, well-known suppliers faces a smaller version of this problem than one onboarding new vendors constantly and processing hundreds of payments a month — the right level of investment should reflect that difference.

A useful way to calibrate is to weigh the modest cost of a verification routine — mainly time, not money — against the size of a single successful scheme, which is often larger than an entire year of the routine's combined cost. For most businesses handling any meaningful volume of supplier payments, that comparison settles the question quickly.

FlowParse
flowparse.io

That calibration is worth revisiting periodically, particularly as the business grows — more suppliers and more payment volume both increase the surface area for an attempt, and a routine sized for an earlier, smaller version of the business may need to grow alongside it.

Revisiting it alongside an annual insurance renewal is often the most natural trigger — a broker will frequently ask directly about verification practices, which makes the review happen on schedule rather than depending on someone remembering to raise it on their own.

What we don't do

We don't confirm that a specific invoice is fraudulent

We flag a deviation from documented history. Confirming fraud, and deciding what to do next, stays a human judgment call.

We don't perform the verification call

We give you the flag and the comparison. Calling a trusted contact to confirm a change stays a manual step, by design.

We don't recover funds after a fraud succeeds

That's a matter for your bank and, where relevant, law enforcement — we're not part of that process.

We don't replace a documented fraud policy

We're a detection layer that feeds your existing process, not a substitute for having one written down.

What we do is the part that has to happen before any of that: an honest, consistent reading of every invoice and statement, so the comparison you rely on is based on real documents, not memory or a spreadsheet nobody keeps current. For that, see unusual payment flagging, and for the routine to build around it, see how to spot payment fraud in your books.

A useful rule of thumb: the sooner a suspicious request is compared against real history and verified, the more options remain for stopping it calmly. Caught before payment, it costs a phone call. Caught after, it costs a much longer, much less comfortable conversation — with far worse odds attached.

Frequently asked questions

Build your own baseline

Read your supplier invoices and see the pattern behind each relationship — before a scheme has a chance to exploit it.

Keep reading