Fraud rarely looks dramatic
Ask anyone who has actually caught a fraudulent payment how they found it, and the answer is rarely a dramatic discovery. It's usually smaller than that — an invoice from a familiar supplier for an amount that felt slightly off, a payment that landed a few days earlier than usual, an account number that didn't quite match the one on file. None of it screamed fraud. It just didn't fit the pattern.
This page describes how that kind of deviation gets caught systematically instead of by accident — every invoice and statement read, a baseline of normal built per supplier from real history, and a flag raised the moment something breaks it. The result doesn't decide that a payment is fraudulent; it puts the deviation in front of a person early enough that a decision is still possible, before the payment has already cleared and the money is gone.
Why unusual payments are hard to catch by eye
A single invoice, looked at on its own, almost always looks plausible. The supplier name is real, the format matches what that supplier usually sends, the amount is a normal-looking number. What makes it unusual only becomes visible next to the invoices that came before it — and holding a supplier's last twelve months of invoices in your head while approving this month's batch isn't something most finance teams have time to do.
That gap — between what a single document shows and what a pattern across many documents would reveal — is exactly where payment fraud tends to survive. Not because anyone was careless, but because the comparison that would catch it requires holding far more information at once than a person reviewing invoices under a deadline realistically can.
That's not a criticism of anyone doing the reviewing — it's a structural limit of doing this comparison by memory. The fix isn't asking people to remember more; it's making the comparison itself something the process does automatically, every time, regardless of how busy the month has been.
What counts as unusual
| Signal | What it means |
|---|---|
| Amount deviation | Materially larger, smaller, or oddly precise compared to this supplier's history |
| Timing deviation | Arrives well outside the supplier's normal invoicing cadence |
| Bank detail change | Payment account differs from the one used in prior transactions |
| Threshold proximity | Sits just under an approval limit, invoice after invoice |
| New payee, high amount | A first-time supplier paid a large sum before any track record exists |
Five signals, none of them proof of fraud on its own — a genuine price increase produces an amount deviation too. What matters is that each one gets surfaced instead of silently absorbed into an approval that happens on autopilot.
What gets read from every document
| Field | Notes |
|---|---|
| Supplier name and identifier | Used to group every document into the correct baseline |
| Amount | The exact figure, per line item where itemised |
| Invoice or transaction date | For establishing and checking cadence |
| Bank account details | Where present on the invoice or statement |
| Reference or invoice number | For traceability back to the source document |
Five fields, read from every document — not a summary written weeks later from memory, but what the document itself states, kept linked to its source for whenever a flag needs a second look.
Building a baseline per supplier
A single global rule — flag anything over a fixed amount, say — misses far more than it catches, because normal looks completely different from one supplier to the next. A logistics supplier might invoice a wildly different amount every month; a software subscription might invoice the exact same figure for years. Treating both the same way either buries real anomalies in noise or drowns the team in irrelevant flags.
Instead, every supplier accumulates its own history as invoices are read — typical amount range, typical timing, the bank details normally used. A new invoice is compared against that supplier's own pattern, not a generic threshold applied uniformly across every relationship the business has.
A quarter of invoices, one flagged
A mid-sized services business, one quarter, 210 supplier invoices across 34 suppliers.
| Result | Count |
|---|---|
| Matched supplier's normal pattern | 206 |
| Flagged — amount deviation | 3 |
| Flagged — bank detail change | 1 |
Three amount flags turned out to be a genuine annual price increase across three suppliers, confirmed in minutes. The bank detail change was a real one — a supplier that had switched banks and sent a courtesy notice that had gone unread in a shared inbox. The invoice was legitimate; had it not been, the flag would have caught it before payment.
How it works
Upload invoices and statements
PDF, scan or photo — one at a time or a full month's batch.
Each document is read
Supplier, amount, date, bank details and reference, per document.
Compared against the baseline
Every new document checked against that supplier's established pattern.
Export
Excel, CSV or JSON, with flagged items and their reasons kept as separate fields.
From one invoice to a full ledger
Checking one invoice against a supplier's recent history is a quick manual task. Doing it for every invoice a business receives, every month, across every supplier, is a different problem — not because any one comparison is hard, but because the number of comparisons required grows with every new supplier and every new invoice.
At that volume, the value isn't only speed — it's that every supplier gets the same level of scrutiny, instead of the handful of large, familiar suppliers getting careful attention while a smaller, less frequent supplier's invoice slips through with barely a glance.
Cross-checking against the bank statement
An invoice states what was billed. The bank statement states what actually moved. Comparing the two catches a specific and dangerous pattern: an invoice that matches everything on paper but settles to an account that doesn't match the supplier's known details — a classic sign of a compromised or impersonated supplier.
Because FlowParse reads both invoices and bank statements, a payment can be checked not just against the invoice that requested it, but against the account it actually settled to — catching a mismatch that reviewing the invoice alone would never reveal.
Living with false positives
A system that never flags anything wrong is also, almost by definition, a system that never flags anything real. Some flags will turn out to be entirely legitimate — a genuine price increase, a supplier moving to a faster invoicing schedule, an approved one-off large order. That's expected, not a flaw.
What matters is how quickly a false positive can be dismissed. Every flag carries the specific reason and the comparison data behind it, so confirming “yes, this is a known price increase” takes seconds, not a full re-investigation — the cost of a false positive stays low, while the cost of a missed real one stays high.
Who this is for
Finance teams
A second pair of eyes on every invoice, without adding a manual review step to every approval.
Accounts payable
Deviations flagged before payment runs, not discovered afterward during a reconciliation.
Controllers and finance leads
A documented baseline and flag history to point to when a payment is questioned.
Bookkeepers and accountants
The same consistent scrutiny applied across every client's supplier base.
Each of these groups reaches for the same underlying thing: a comparison against real history that's already been done, rather than one that has to be reconstructed from memory whenever a question about a specific payment comes up.
This isn't duplicate-payment detection
It's worth being precise about what this page covers. Catching the same invoice paid twice is a related but separate problem, with its own failure modes — see duplicate payments and how they survive every control you have for that specific case, and the reconciliation engine for how invoices get matched to bank statements generally.
Unusual payment flagging is about a single invoice or transaction that breaks a supplier's established pattern — a genuinely new, one-off deviation — rather than the same document appearing twice. The two problems overlap in places, but the signal each one looks for is different, and conflating them tends to miss both.
What happens after something is flagged
A flag is a starting point, not a conclusion. The typical next step is straightforward: someone with context on the supplier relationship — accounts payable, the budget owner, or a controller — looks at the flag alongside the original document and the comparison data, and decides whether it's explainable or needs a call to the supplier on a known, verified number rather than any contact details on the invoice itself.
That last point matters more than it might seem. A common pattern in supplier impersonation fraud is an invoice that also updates the contact phone number — calling “to confirm” using that new number just confirms the fraud. A flagged payment is worth verifying through a channel the business already trusted before the invoice arrived, not one the invoice itself supplied.
Whatever the outcome, the flag deserves a documented resolution, not just a quiet dismissal. A short note — what was checked, who checked it, what was confirmed — turns a one-off review into something the next person can actually learn from, rather than a decision that lives only in one reviewer's memory until they forget it.
A history that gets sharper over time
A baseline built from one month of invoices is useful but thin. The same baseline built from two or three years of real history is sharper — it distinguishes a supplier that genuinely varies month to month from one that's remarkably stable, and it absorbs known seasonal patterns instead of flagging them as anomalies every single year.
That improvement isn't something that has to be configured — it's a natural effect of reading every invoice the same consistent way from the start, so each supplier's pattern keeps accumulating rather than resetting every time someone tries to reconstruct it from memory or a spreadsheet nobody kept fully up to date.
Tuning sensitivity to your business
No single sensitivity setting is right for every business. A business with tight, predictable supplier pricing can run with a narrower tolerance, catching smaller deviations, without drowning in false positives. A business with naturally variable supplier costs — commodity-linked pricing, freight surcharges that shift monthly — needs a wider tolerance, or every routine fluctuation would generate a flag nobody has time to review properly.
Getting this setting right matters more than it might seem. Too narrow, and the team starts ignoring flags because most of them are noise, which defeats the entire purpose. Too wide, and a real deviation slips through the threshold unflagged. The right calibration usually emerges after the first month or two of real use, once a team has a feel for how many flags is a reasonable number to review consistently.
A useful starting point is to set sensitivity slightly tighter than feels comfortable, then loosen it based on actual experience — false positives are annoying but cheap to dismiss with the comparison data attached, while a sensitivity set too loose from the start risks missing exactly the kind of deviation the whole system exists to catch.
What this doesn't do
Doesn't confirm fraud
It flags a deviation from an established pattern. Confirming whether it's actually fraudulent remains a human judgment call.
Doesn't block payments
It reads and flags. Stopping or releasing a payment stays inside your existing approval workflow.
Doesn't replace verification calls
A flagged bank-detail change still deserves a call through a previously trusted channel before payment.
Doesn't work well with zero history
A brand-new supplier has no baseline yet — flagging accuracy improves as real invoices accumulate.
This boundary is deliberate. A tool that silently decided a payment was fraudulent and blocked it would be making a business decision no one asked it to make — a flagged, explainable deviation is far more useful than a system that's either always right or completely trusted, neither of which describes any fraud detection honestly.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Invoices are never used to train AI models.
For a business handling supplier payment data, that isn't a footnote — the details are on the security page.