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.
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.
The anatomy of a typical scheme
| Stage | What happens |
|---|---|
| Research | The fraudster identifies a real supplier relationship, often via a prior email compromise somewhere in the chain |
| Contact | An email or letter arrives — from a spoofed or compromised account, or a convincing lookalike domain — announcing new bank details |
| Wait | The fraudster waits for the next routine, expected invoice rather than requesting an unusual out-of-cycle payment |
| Collect | The 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.
| Step | What was found |
|---|---|
| Request received | An email, from a domain one character different from the real supplier's |
| Compared against baseline | Bank details differed from five years of consistent prior payments |
| Flagged | Held pending verification before the next scheduled invoice was due |
| Verified | A 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.
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.
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.
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.
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 found | Typical response |
|---|---|
| A bank-detail change request | Hold any pending payment and verify through a previously trusted contact before releasing it |
| A confirmed fraudulent invoice | Report to the bank immediately, request a recall, and notify the relevant authority |
| A suspicious but unconfirmed email | Escalate for a second opinion rather than deciding alone under time pressure |
| A pattern of near-miss attempts on one relationship | Add 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.
| Business | When it catches a scheme | Room to act |
|---|---|---|
| A — no baseline comparison | After the payment has already cleared | Minimal — recovery odds drop fast after transfer |
| B — informal 'we'd notice' confidence | Sometimes, if someone happens to remember | Limited — depends entirely on memory |
| C — documented baseline, verified changes | Before the payment is released | Wide — 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
