Not caught by looking harder
Ask anyone who's actually caught payment fraud in their own books how they found it, and the honest answer is rarely “we reviewed the invoice more carefully”. A fraudulent invoice, looked at in isolation, is usually designed to look entirely ordinary — that's the point. What actually catches it is a comparison: this invoice, next to the ones from the same supplier that came before it.
That comparison takes real, deliberate effort the first time — pulling a year of history, building a sense of what normal looks like for each supplier, and working through what doesn't fit. This guide explains how to pay that cost once and turn it into a routine, so spotting fraud stops being something that only happens by luck or after money has already left the account.
Why fraud survives a normal review
A normal invoice review checks that an invoice is internally consistent — line items add up, the format looks right, the supplier name is familiar. A well-executed fraud passes every one of those checks, because it's built specifically to. What it usually can't fake convincingly is the pattern of a real, ongoing relationship — the exact amount range this supplier tends to invoice, the exact timing it tends to invoice on, the exact bank account it has always settled to.
A review that never makes that comparison — that treats every invoice as its own self-contained document — misses exactly the signal that would catch it, no matter how carefully each individual invoice is checked for internal consistency.
| Review type | Catches | Misses |
|---|---|---|
| Internal consistency only | Math errors, formatting problems, obviously fake documents | A convincing fraud that matches its own internal logic |
| Pattern comparison | A deviation from the supplier's own established history | Requires history to exist first |
| Both together | The overwhelming majority of realistic fraud attempts | Genuinely novel schemes with no comparable precedent |
Three decisions before you start
Skip them, and every review that follows inherits whatever got decided by accident on day one. Fix them first, and everything else becomes mechanical.
How much history counts as a baseline
Decide the minimum number of prior invoices before a supplier's pattern is trusted enough to flag deviations against — too few, and every early invoice looks like an anomaly.
The flag sensitivity
How far outside the historical range something has to fall before it's worth a person's time — decided once, applied consistently regardless of who's reviewing.
The verification procedure
Exactly how a flagged bank-detail change gets confirmed — which channel counts as trusted, and who's authorised to release a held payment once it's confirmed.
None of these three decisions needs to be perfect on the first attempt — they can, and usually should, be revisited after the first few review cycles once real experience shows whether they were set too tight, too loose, or about right for how the business actually operates.
The nine steps
Pull twelve months of invoices and statements
Every supplier invoice and the corresponding bank statement for a full trailing year, so the comparison has enough real history behind it.
Group every document by supplier
Every invoice and payment tied to the specific supplier it belongs to, not lumped into one undifferentiated pile of transactions.
Establish each supplier's normal range
Typical amount, typical timing, and the bank details normally used — built from that supplier's own history, not a generic rule.
Read every invoice line by line
Amount, date, bank details and description — not just a summarised total glanced at once.
Compare each invoice against its supplier's baseline
Check the specific amount, timing and bank details against what that supplier's history would predict.
Cross-check against the bank statement
Confirm the invoice matches what actually moved, and that it settled to the account on file, not a different one.
Flag anything that breaks the pattern
Amount deviations, timing deviations and bank-detail changes each recorded as their own distinct flag, with the reason attached.
Verify flagged bank-detail changes through a trusted channel
A phone number or contact used before the suspicious invoice arrived, never the contact details the invoice itself supplies.
Log the resolution and fold it back in
Every flag closed out with its outcome, so the next review benefits from what this one already learned.
Handling what you find with a method
Not everything flagged is fraud, and treating every flag as a crisis burns out a team fast. Most flags resolve as genuinely explainable — a price increase, a supplier switching banks and sending proper notice, a one-off large order that was approved through the normal process.
What separates a good process from a bad one isn't the number of flags — it's how consistently each one gets resolved and documented, rather than some being chased down thoroughly and others waved through because the reviewer was busy that day.
A useful habit is to briefly note why each explainable flag resolved the way it did, even when the reason seems obvious in the moment. Six months later, that short note is the difference between instantly recognising a familiar, already-explained pattern and re-investigating something that was actually settled long ago.
A quarter reviewed, one real case
A services business, one quarter, 180 supplier invoices reviewed against a year of prior history.
| Outcome | Count |
|---|---|
| Matched established pattern | 174 |
| Flagged, resolved as legitimate | 5 |
| Flagged, confirmed fraudulent | 1 |
The one confirmed case was a bank-detail change on a mid-frequency supplier, arriving as a routine-looking email update with no phone call. The flag caught the mismatch against the account on file; a call through the number already on record — not the number in the fraudulent email — confirmed the real supplier had never sent it. The payment, still pending, was held before it cleared.
Common mistakes
Reviewing invoices without pulling up supplier history
The single most common gap. Without the comparison, even a careful review is just checking internal consistency, which fraud is built to pass.
Verifying a bank-detail change using the invoice's own contact details
Confirms nothing — a fraudulent invoice that changes the bank account routinely changes the phone number too.
Treating every flag as equally urgent
Burns out the review process fast and makes the team start ignoring flags altogether, which defeats the purpose entirely.
Not logging resolved flags
Loses the institutional memory that would let the next reviewer recognise the same explainable pattern quickly instead of re-investigating from zero.
Each of these four shares a common root: skipping a step that feels optional in the moment but turns out to be exactly the step that would have caught the one attempt that actually mattered.
Best practices
Always verify a bank-detail change through a channel trusted before the invoice arrived, never the invoice's own contact details.
Give a new supplier's early invoices extra scrutiny on the specific details, since there isn't enough history yet for a statistical baseline.
Document every flag's resolution, even the obviously explainable ones — the log is what makes future reviews faster.
Separate the reviewer from the approver where volume allows, so no single person both flags and clears the same payment.
Making it a routine, not a scramble
The version of this process that actually survives contact with a busy month is the one that doesn't depend on someone remembering to do it. Reading every invoice and statement automatically, comparing each one against its supplier's baseline, and surfacing only what deviates turns a multi-day manual comparison into a short review of whatever actually got flagged.
That's the shift this guide's method is built toward — not eliminating the judgment calls, which stay with a person, but eliminating the mechanical comparison work that made doing this consistently, every single period, impractical by hand.
The verification call, done right
A flagged bank-detail change deserves exactly one type of follow-up: a call to a number the business already had on file before the suspicious invoice showed up — not a number printed on the invoice, not a number in the email that announced the change, and not a link in that email either.
Frame the call around confirming a specific detail rather than asking an open question — “can you confirm your payment account still ends in [last four digits]” rather than “did you send this invoice”, which a busy or unaware contact on the other end might answer incorrectly out of politeness rather than certainty.
If the supplier confirms nothing changed, treat the invoice as fraudulent immediately, hold any pending payment, and follow your organisation's incident process. If the supplier confirms the change was genuine, document exactly how it was verified before updating the baseline, so the new bank details are trusted for the right reason, not just because the flag eventually went away.
What you actually need
None of this requires specialised fraud-detection software to get started. A spreadsheet holds the baseline and the flag log perfectly well. What's genuinely slow by hand is reading every invoice and bank statement consistently enough, month after month, to keep that baseline current — that's the specific piece worth automating first, because it's the piece that determines whether the routine survives a busy quarter.
A document reader that extracts supplier, amount, date and bank details the same way every time, whether the invoice is a clean digital PDF or a scanned photo, removes exactly that bottleneck — leaving the comparison and the judgment calls, which is where a person's time is actually well spent.
Resist the temptation to over-build this before it's needed. A working spreadsheet with a documented process behind it, run consistently, catches far more than an elaborate system built once and abandoned because it was too complicated to maintain. Start with what's actually usable every single month, and only add complexity once the basic routine has proven itself.
The same method across multiple entities
A business with more than one entity or location faces a version of this problem that's easy to underestimate — the same supplier might invoice several entities separately, and a fraud that changes bank details on one entity's relationship might not immediately show up on another's, especially if each entity keeps its own separate records.
Running the same baseline method per entity, but comparing supplier identities across entities as a separate check, catches a specific and dangerous pattern: a supplier whose bank details changed on one entity's books but not another's, which is exactly the kind of inconsistency a fraud that targeted only one entity would produce.
The very first review, step by step
The first time through this method is the slowest, because there's no existing baseline and no existing habit to lean on. Start narrower than feels ambitious — pick your ten highest-value suppliers by total annual spend, not every supplier at once, and build their baselines first.
Gather a full trailing year of invoices and statements for those ten suppliers, that's the whole first step. Read each one, group them by supplier, and note the range each supplier's amounts fall into and the typical gap between their invoices. This alone, done for just ten suppliers, usually takes an afternoon and already produces a usable baseline for the relationships that matter most.
Once the top ten are done, expand outward — the next twenty suppliers by spend, then the rest. By the time the full supplier base has a baseline, the routine of reading and comparing new invoices against it is already familiar, so extending it to the last, smallest suppliers is fast rather than another multi-day project.
The log, column by column
A flag log doesn't need to be complicated, but a handful of specific columns make the difference between a log that's actually useful six months later and one that's just a list of dates nobody can interpret.
| Column | Why it matters |
|---|---|
| Supplier and invoice reference | Ties the flag back to the exact source document |
| Signal type | Amount, timing or bank-detail deviation, kept distinct |
| Historical comparison | The specific range or detail the flagged item deviated from |
| Reviewer and date reviewed | Establishes accountability and a timeline |
| Resolution and evidence | How it was verified, and what confirmed the outcome |
Five columns, none of them optional in practice — a log missing the resolution and evidence columns is just a list of suspicions, not a record that actually protects the business or the reviewer who raised the flag.
Three ways to review payments, compared
| Method | Typical time per period | Where it fails |
|---|---|---|
| Ad hoc, no baseline | Minimal, until something goes wrong | Catches almost nothing until it's already too late |
| Manual comparison against a spreadsheet baseline | Several hours | Depends entirely on someone reliably keeping the spreadsheet current |
| Automatic reading plus baseline comparison | Under an hour | Requires setup, and still needs a person for judgment calls |
The honest comparison isn't between a perfect method and an imperfect one — every method here still depends on a person making the final call. What changes is how much of the mechanical comparison work has to happen before that person even gets a chance to make it.
The rhythm that repeats every period
A fiscal year, seen through this routine, has its own texture. Certain months bring a predictable wave of new suppliers — often around a new project or a seasonal push — and those months deserve more attention to fresh baselines, not less, precisely because that's when a fraudulent new-supplier setup is easiest to slip past a busy team.
Year-end, in particular, tends to bring a cluster of one-off large invoices — bonus payments, annual contract renewals, capital purchases — that legitimately look unusual against a normal monthly baseline. Recognising that pattern in advance, rather than being surprised by it every December, keeps the review from either missing a real anomaly buried in the noise or flagging half the department's normal year-end activity as suspicious.
Reviewers who run this process for several years in a row start recognising their own organisation's rhythm without needing to be told — which months run heavy, which suppliers reliably change terms around a renewal date, which categories of spend cluster predictably. That familiarity is itself a form of fraud detection, built entirely from paying attention, period after period.
Building a clear escalation path
A flag that has nowhere specific to go tends to sit unresolved, or gets closed hastily by whoever happens to see it because they don't know who else should look at it. A written escalation path fixes that — not a complicated organisational chart, just a clear answer to “who do I tell, and what happens next” for each type of flag.
A reasonable structure for most businesses has three tiers. The first-line reviewer handles routine flags that resolve quickly and obviously — a known price increase, a supplier that always invoices erratically. Anything that doesn't resolve in a few minutes, or that involves a bank-detail change, escalates to a second tier with more authority — a controller or finance manager who can approve holding a payment. A confirmed or strongly suspected fraud escalates further still, to whoever in the organisation owns incident response, bank communication and, where relevant, reporting to authorities.
| Tier | Handles | Authority |
|---|---|---|
| First-line reviewer | Routine, quickly explainable flags | Can resolve and document, cannot release a held payment |
| Controller or finance manager | Unresolved flags, all bank-detail changes | Can hold or release a payment after verification |
| Incident owner | Confirmed or strongly suspected fraud | Coordinates bank, authorities and internal response |
The specific names attached to each tier matter less than the fact that everyone on the team already knows them before a real flag ever comes up. Deciding who's responsible for what in the middle of an actual suspected fraud, under time pressure, is exactly the wrong moment to be figuring out the org chart for the first time.
What good documentation actually looks like
Not every business needs elaborate documentation for this process, but a few pages, written once and kept current, make an enormous difference the first time someone new joins the review rotation or an external party asks how the business protects itself against payment fraud.
Good documentation for this process typically covers four things: how a supplier baseline gets established and how much history counts as reliable, exactly what triggers a flag and at what sensitivity, precisely how a bank-detail change gets verified and by whom, and where the flag log itself lives and who has access to it. None of this needs to be long — most businesses can cover all four in two or three pages.
The value of writing it down isn't bureaucratic box-checking. It's that the next person who joins the review rotation, or the auditor asking about controls, or the insurer assessing a claim, gets a consistent, complete answer regardless of who they happen to ask — instead of three slightly different informal explanations from three different team members, none of which quite match what actually happens in practice.
Measuring whether the process is working
A fraud review process that never catches anything real for years isn't necessarily failing — it might just mean the business hasn't been targeted yet, or the targeting attempts have been unsophisticated enough that normal approval steps already caught them. What's worth actually tracking isn't just confirmed catches; it's whether the routine itself is being followed consistently.
A few simple measures tell that story well: what percentage of suppliers actually have an established baseline, what percentage of flagged items get a documented resolution within a reasonable window, and whether every single bank-detail change in the period went through the verification step, with no exceptions quietly made for a supplier that seemed too familiar to bother checking.
That last measure — zero exceptions on bank-detail verification — is worth treating as close to non-negotiable. It's precisely the “this supplier is too well-known to need checking” exceptions that create the specific gap a patient fraudster is counting on finding.
Frequently asked questions
Build your first baseline
Start with your ten highest-value suppliers. Read a year of their invoices, and see the pattern before you need it.