A comparison that repeats every period
The fraud report a CFO glances at — nothing significant this month, a couple of flags resolved as legitimate — looks, from their side of the table, like a simple, uneventful fact. From the side of whoever produces it, it's the result of a routine that ran quietly all month: every invoice and statement read, every supplier checked against its own documented history.
Where that routine most often gets stuck isn't the review of what gets flagged. Confirming a handful of deviations is quick once the comparison data exists. The slow, error-prone part is building that comparison in the first place — reading enough history, consistently enough, to know what “normal” even means for each of dozens or hundreds of supplier relationships.
This page walks through what that routine actually looks like in practice, what it costs to run by hand versus with automatic reading, and the specific scenarios a finance team is likely to encounter once it's running.
Where finance teams actually lose time
None of these five is a single dramatic failure — each is a small, recurring gap that a finance team tolerates because no single month is bad enough on its own to justify fixing it. Added up over a year, they're usually the largest real vulnerability in a fraud control process, well before any actual attempt occurs.
Retyping invoice and statement data from PDFs by hand
The single biggest time cost in most routines, and the least visible to anyone above the person actually doing it.
Reviewing invoices without pulling up supplier history
The comparison that would catch most fraud never happens, simply because holding a year of history in mind isn't realistic under a deadline.
Verifying a bank-detail change using the request's own contact details
Confirms nothing, and is one of the most common ways a genuinely careful reviewer still gets caught.
Explaining a flag that turned out to be a legitimate price increase
A deviation that looks like a problem is sometimes just normal business change — and untangling which one takes longer without the comparison data already attached.
Rebuilding the whole process after a staff change
Undocumented routines and unwritten institutional memory of 'what looks normal' leave with whoever built them.
A realistic monthly routine
Gather invoices and statements
Every supplier, every account, at the same point in the month — accounting system export where it exists, PDF via email elsewhere.
Read every document
Supplier, amount, date and bank details, for every transaction, not just a summarised total.
Compare against each supplier's baseline
Confirm every new invoice matches that supplier's established pattern, catching a deviation before payment.
Flag every deviation
Logged with the date it was found and the reason, so it's never counted as resolved before it actually is.
Verify bank-detail changes specifically
The highest-priority flag type, verified through a channel trusted before the request arrived.
Log resolutions and compare against the trend
How many flags this period, how they resolved, and whether that pattern is shifting over time.
Notice that only step two — reading every document — is purely mechanical. Steps one, three, four, five and six all involve a decision at some point: which documents count as this month's, whether a deviation is really a price increase or a genuine concern, how to prioritise a flagged item. Removing the friction from step two is what frees up the team's time for the decisions that genuinely need a person, instead of retyping numbers a document already states clearly.
Who owns each step matters more than it seems, too. In teams where “whoever has time” reviews the flagged list, the routine quietly degrades the first busy month — a flag gets waved through without real verification, nobody notices until it's too late, and the gap that let one fraud through stays wide open for the next attempt. Naming an owner for steps one through five, even if it isn't always the same person every month, is a small organisational decision that stops the routine eroding silently.
The cost of doing it by hand, honestly
For a business with a couple hundred active suppliers, manually building and checking a comparison against history commonly takes the better part of a day per month — more in a month where a genuine bank-detail change needs chasing down and verifying.
| Approach | Typical time per month | Where it fails |
|---|---|---|
| Fully manual, no baseline | 4-8 hours, when attempted at all | Relies entirely on memory of what's 'normal' for each supplier |
| Spreadsheet template, manual entry | 2-4 hours | Still depends on someone reading every document correctly and consistently |
| Automatic reader plus baseline comparison | Under an hour | Requires initial setup; still needs a person for judgment calls |
At a fully loaded cost of $40-60 an hour for finance staff, the gap between the first and third rows is roughly $160-420 a month — $1,900-5,000 a year — for a task that produces the same underlying protection either way. The bigger, far less predictable cost is what a single undetected scheme costs when it succeeds, which routinely exceeds that entire annual figure many times over in one incident.
What changes
Hours back, every month
Mechanical reading and comparison drop from hours to minutes, freeing time for the verification calls that genuinely need a person.
A documented, defensible process
Every flag links back to the specific comparison that produced it, ready for whenever an auditor, an insurer or a colleague asks why.
A routine that survives a staff change
Documented steps and a running baseline, not tribal knowledge of 'what looks normal' that leaves with whoever built it.
A trend, not just a snapshot
Monthly flag counts accumulate into a real history — useful for spotting whether attempts are increasing as the business grows.
None of these four changes requires a large upfront investment or a specialist hire — they emerge from the same underlying shift: reading documents consistently enough that a real comparison against history becomes possible every single period, instead of only when someone has unusual spare time to attempt it manually.
Who does what, once the routine exists
A monthly routine works best as a chain of clearly separated tasks, not one person doing everything under pressure. Splitting it also lets the routine survive an absence or a staff departure, which a single-person process never does.
| Step | Typically owned by | Judgement required |
|---|---|---|
| Gathering invoices and statements | Accounts payable | Low — mostly downloading and collecting |
| Reading and comparing against baseline | Automatic, or a staff member as a fallback | Low — the comparison is arithmetic |
| Flagging deviations | Fixed process, with escalation when unclear | Medium — needs context on a supplier's usual pattern |
| Verifying flagged bank-detail changes | Controller or a designated verifier | High — this is the real judgement the routine exists for |
| Reporting to the CFO or the board | Controller or CFO | High — framing and anticipating follow-up questions |
The pattern worth noticing: the two lowest-judgement rows — gathering and comparing — are also the two that consume the most time in a manual routine, while the two highest-judgement rows — verification and reporting — take up the controller's time but relatively little of it. Automating the low-judgement rows doesn't change who owns the high-judgement ones; it simply stops mechanical work from eating into the hours that should go to real decisions.
Scenario: the new supplier
A business onboards a new supplier, generating a handful of invoices in the first month, none of them yet backed by any meaningful history, from a contact nobody on the finance team has spoken to more than once.
In a fully manual routine, this is exactly the relationship most likely to be waved through without real scrutiny — there's no established pattern to notice a deviation from, and a busy team defaults to trusting a professional-looking invoice on its own merits.
A routine built around explicit baseline confidence treats this correctly instead — flagging the relationship as low-confidence-baseline rather than either ignoring it or blocking it outright, which prompts exactly the kind of extra scrutiny a brand-new relationship deserves until real history accumulates.
Scenario: the urgent request
An email arrives late on a Friday afternoon, apparently from a senior executive, requesting an urgent wire transfer to close a time-sensitive deal — explicitly asking that it bypass the normal approval chain given the deadline.
Without a clear policy, producing the right response under that pressure falls entirely on whoever happens to receive the email, at exactly the moment — end of week, under time pressure — least conducive to careful judgment.
With a documented policy that treats urgency and a request to bypass process as the primary red flag itself, regardless of apparent seniority, the response is already decided in advance: escalate, verify through a known channel, and never let time pressure substitute for the normal check.
Scenario: the near miss
A mid-sized supplier's bank details change via an email that looks entirely legitimate — correct tone, correct format, referencing real past invoice numbers, sent from what appears to be the usual contact.
A flag is raised automatically the moment the new details don't match five years of consistent prior records. A verification call, placed to the phone number already on file — not the one in the email — reveals the real supplier never sent any such notice.
The pending payment tied to that invoice is held before release. Nothing dramatic happens; the incident is logged, the pattern shared with the team, and the routine continues the following month exactly as before — which is precisely what a fraud control process working as intended looks like from the inside.
What makes this scenario worth highlighting isn't how dramatic it is — it's how undramatic it is. No heroics, no last-minute scramble, just a documented step that happened exactly as designed because the process existed before it was needed, not improvised in the moment it mattered most.
What the CFO wants to see
A clear summary, with confidence to answer a follow-up question about any flagged item.
A trend, not just this month's count — whether attempts are increasing, decreasing or steady.
Flags broken down by signal type, not merged into one figure that hides whether it's mostly amount deviations or bank-detail changes.
Every flag's resolution stated plainly, instead of requiring the CFO to ask what happened to a specific item.
None of these four is achievable from a single month's total alone, or from a snapshot with no history behind it. All four are what a consistent monthly routine, built on real data, produces naturally as a byproduct of simply doing it the same way every month.
Scenario: the growing supplier base
A business that grows from 40 to 200 active suppliers over a couple of years faces a problem that's rarely planned for with the same attention given to revenue growth itself: the routine that worked well for 40 suppliers gradually stops holding up at 200, not because it's wrong, but because the manual comparison time scales linearly with every supplier added, while finance headcount doesn't.
A routine built around automatic reading and baseline comparison doesn't suffer that same limit — the additional time a new supplier requires is almost entirely the work of the first few invoices establishing its baseline, not manually holding every relationship's history in mind every single month. That's exactly the kind of growth that makes the difference between the two routines visible, not in the abstract but in how many hours finance actually spends on verification instead of data entry.
Many businesses discover this advantage at exactly the wrong moment to fully appreciate it — during the growth itself, when time to rethink processes is already scarce. Building the routine before growth arrives, rather than during it, is what makes the transition smooth instead of a scramble, with fraud exposure already rising from the first new suppliers onboarded under pressure.
A useful test for any growing business is simple: pick the supplier most recently onboarded, and ask how quickly its payment activity reached the same level of documented scrutiny as your longest-standing relationships. If the answer is measured in months rather than weeks, that gap is exactly where a consistent, automatic comparison method pays for itself fastest.
What this doesn't replace
Not a documented fraud policy
It feeds detection into your existing process — it doesn't replace having a written policy, verification procedure or incident response plan.
Not the verification call itself
It gives you the flag and the comparison. Calling a trusted contact to confirm a change stays a manual step, by design.
Not fraud insurance or bank recovery
It reduces the odds a scheme succeeds and improves how fast it's caught if one is attempted — it doesn't replace insurance coverage or a bank's recovery process.
Not a substitute for staff awareness
The routine catches deviations from documented patterns; a trained, alert team still matters for everything a pattern alone can't cover.
Why traceability matters more than it seems
Every flag in a finance team's monthly fraud report should be able to answer one question immediately: what exactly deviated, and from what. In a review built by hand, that answer usually lives in someone's memory or a hastily written note — finding it again months later, when a similar pattern reappears, takes longer than rebuilding the comparison from scratch would have.
This matters more than it seems, for three situations that recur. The first is a routine, non-hostile question from a colleague or auditor about why a specific payment was held for verification weeks earlier — a common ask that still needs answering within the day, not after a week of searching. The second is a new controller taking over, where the entire flag history needs reviewing and every past decision needs a documented reason behind it. The third is simpler and more common still: the controller themselves, three months later, trying to remember why a particular flag was ultimately cleared.
A routine where every comparison is generated directly from retained documents, instead of summarised once into a note that becomes the only record afterward, answers all three automatically. Traceability isn't a feature bolted onto the routine — it's a natural effect of comparing against the document every time instead of trusting a remembered impression.
Starting this month
Take this month's invoices and statements — your longest-standing suppliers, the ones you'd trust least to bother checking manually — and read them together as a trial, alongside your existing process, not in place of it just yet.
Compare the time spent against a typical month, and check whether anything surfaces that a purely manual review would have missed. Most finance teams that run this comparison once don't need further convincing — either nothing unusual turns up, which is itself reassuring, or something does, which makes the case on its own.
For the method this routine is built on every month, see unusual payment flagging and how to spot payment fraud in your books.