The one detail that should rarely move
Most facts about a supplier relationship change occasionally over the years — prices go up, contact people move on, invoice formats get refreshed. A supplier's bank account is different. For most relationships, it stays exactly the same for years, sometimes for the entire life of the relationship.
That stability is precisely why a change matters so much when it happens, and precisely why it's the field fraudsters most often need to alter to redirect a payment. This page describes how every supplier's bank details get tracked across every invoice, and how a change gets flagged the moment it appears, before the next payment is released to it.
Why fraudsters target this specific field
A fraud that changes an amount is easy to catch — the number itself looks wrong next to history. A fraud that changes a supplier's bank details is harder, because the rest of the invoice can be entirely accurate: correct supplier name, correct amount, correct invoice number. The single altered field is the only thing actually wrong, and it's a field most manual reviews never think to check against history at all.
That combination — everything else convincingly correct, one quiet change buried in a field nobody routinely compares — is exactly what makes vendor impersonation schemes disproportionately effective, and why they deserve a dedicated, always-on check rather than being folded anonymously into a general review.
Once you know this is the field to watch, the fix is straightforward in principle — compare it against history every time, without exception. The difficulty was never conceptual; it was doing that comparison consistently, by hand, across every supplier, every single month.
What gets tracked per supplier
| Field | Notes |
|---|---|
| Account number | Compared exactly against every prior invoice from the same supplier |
| Routing or sort code | Tracked alongside the account number, since either changing alone is a signal |
| Bank name | Where present, checked for consistency with the account details |
| Date of first use | For each distinct set of details, so a genuinely old account isn't treated as new |
| Invoice reference | For traceability back to exactly which document introduced a change |
Five fields, tracked per supplier — not a single snapshot taken once and assumed to stay correct, but a running record checked afresh with every new invoice.
From a read invoice to a flag
Every invoice's bank details are compared against the full set of details previously recorded for that supplier. A match against any previously used, valid account passes without a flag. A set of details that doesn't match any prior record is flagged, with the specific prior details shown alongside the new ones for direct comparison.
The flag doesn't distinguish in advance between “probably fraud” and “probably a legitimate bank switch” — both look identical from the reading alone, and deciding which one it is requires exactly the kind of verification a person, not an automated reader, is positioned to do.
A year of invoices, one real change
A mid-sized business, twelve months, 58 active suppliers tracked continuously.
| Outcome | Count |
|---|---|
| Suppliers with no change all year | 55 |
| Flagged change — confirmed genuine | 2 |
| Flagged change — confirmed fraudulent | 1 |
Three changes across 58 suppliers over a full year — two were legitimate bank switches, each confirmed in a two-minute call. The third was the fraudulent one, caught because the flag held the pending payment before it was released, giving the business time to verify and refuse it.
How it works
Upload invoices and statements
PDF, scan or photo — individually or in a batch.
Each supplier's bank details are read
Account number, routing details and bank name, per invoice.
Compared against that supplier's history
Every new set of details checked against everything previously recorded for the same supplier.
Export with flags attached
Any deviation exported with the prior and new details shown side by side.
Verifying a genuine change
A flag is the start of a short, specific process, not the end of one. Call the supplier using a phone number your business already had on file before the change request arrived — never a number printed on the invoice or the email that announced the change, since a fraudulent request routinely supplies its own fraudulent contact details.
Confirm a specific detail — the last few digits of the new account, for instance — rather than asking an open question that a distracted or unaware contact might answer imprecisely. Once confirmed through that trusted channel, the new details can be added to the supplier's record as a second valid account, so future invoices using it don't trigger another flag.
From one supplier to a full ledger
Remembering one supplier's bank details from memory is manageable. Remembering dozens or hundreds, across every supplier a business pays, isn't — and that gap is exactly where a change slips through unnoticed in a manual process, especially for less frequent suppliers that don't come up often enough to stay memorable.
At that volume, the value isn't only catching fraud — it's that every supplier, not just the large, familiar ones, gets the same consistent tracking, closing the gap that fraudsters specifically look for: a smaller, less frequent relationship where nobody would immediately notice a quiet change.
Who this is for
Accounts payable teams
A verification checkpoint built into the payment process, not an extra manual task bolted on top.
Finance leaders and controllers
A defensible, documented record of every bank-detail change and how it was verified.
Bookkeepers and accountants
The same consistent tracking applied across every client's supplier base.
Businesses with a growing supplier base
Protection that scales automatically as new suppliers are added, without extra manual setup.
When a change is actually legitimate
Not every flagged change is a fraud attempt. Suppliers genuinely switch banks — moving to a bank with better rates, consolidating accounts after a merger, or simply changing providers for their own reasons entirely unrelated to your business.
A flag doesn't block the payment or make the accusation for you — it holds the change up for the one verification step that quickly separates the two cases. A two-minute phone call resolves a legitimate change permanently; the same flag, on a fraudulent request, is the difference between a payment that's stopped and one that's gone.
That asymmetry — a small cost for a legitimate change, a large benefit for a fraudulent one — is exactly why the verification step is worth the minor friction every single time, with no exceptions carved out for suppliers that feel too familiar to bother checking.
A history that gets more valuable over time
A supplier's bank-detail history is most useful precisely when it's deepest — a relationship with five years of consistent details behind it makes a sudden change far more conspicuous, and far more clearly worth scrutiny, than the same change would be against only a few months of thin history.
That depth builds automatically simply by reading every invoice the same consistent way from the start, so the protection this tracking provides genuinely strengthens the longer a supplier relationship runs — exactly the opposite of how most manual processes work, where institutional memory of “what this supplier's account has always been” tends to fade rather than sharpen as staff change over the years.
A new supplier versus a changed one
It's worth being precise about a distinction that's easy to blur: a brand-new supplier providing bank details for the first time is a fundamentally different event from an existing supplier changing details it has used for years, even though both can superficially look like “new bank details showed up.”
A first-time supplier has no prior details to deviate from, so there's nothing to flag as a change — the details are simply recorded as the starting point. What deserves scrutiny there is different: confirming the supplier itself is legitimate, not confirming that its bank details match something they've always used, which by definition doesn't exist yet.
An existing supplier changing details, by contrast, is compared against real prior history — and that comparison is exactly what this tracking is built around. Keeping the two cases distinct matters because the right response to each is different: new-supplier scrutiny focuses on verifying the relationship itself, while existing-supplier scrutiny focuses on verifying that a specific, unexpected change is genuine.
When more than one person handles verification
In larger accounts payable teams, the person who first notices a flagged change is rarely the same person who ultimately approves the payment. That handoff is exactly where a verification step can quietly get skipped — each person assumes the other one handled it, and the change gets accepted without anyone actually having made the call.
A documented flag that stays visibly open until someone explicitly records how it was verified — who called, which number, what was confirmed — closes that gap. The next person in the chain sees clearly whether verification already happened or is still outstanding, instead of assuming silently in either direction.
This matters most for smaller, less frequent suppliers, precisely the ones a busy team is most likely to wave through on the assumption that someone else already checked. A visible, shared record removes that assumption entirely.
Warning signs that go beyond the bank details themselves
A bank-detail change is the clearest single signal, but it's rarely the only thing worth noticing about a suspicious request. A handful of accompanying details, seen together with a flagged change, raise the odds considerably that something is genuinely wrong rather than a routine administrative update.
| Accompanying signal | Why it raises concern |
|---|---|
| Request also updates the contact phone number | Removes the ability to verify through the previously known number |
| Framed as urgent, ahead of a normal invoice cycle | Discourages the careful comparison that would normally catch it |
| Email domain subtly different from the supplier's usual one | A common technique in vendor impersonation, easy to miss at a glance |
| Explicitly asks to bypass a normal approval step | A legitimate supplier has no reason to request this |
None of these alone proves fraud — a supplier genuinely might update its contact number the same week it switches banks. But when several of them appear together alongside a flagged bank-detail change, the combination is worth treating with real seriousness rather than assuming the simplest, most convenient explanation.
After a change is confirmed genuine
Once a bank-detail change has been verified through a trusted channel and confirmed genuine, the new details should be recorded clearly as the supplier's current account, with the change itself — when it happened, how it was verified, who confirmed it — kept as part of that supplier's permanent history rather than discarded once the immediate question is resolved.
That record matters for two reasons beyond the immediate verification. First, if a question ever comes up later about why payments moved to a new account at a specific point, the answer is already documented rather than needing to be reconstructed. Second, if the account changes again unexpectedly soon after, that short interval between changes is itself worth extra scrutiny — a supplier that genuinely just switched banks rarely switches again within weeks.
What this doesn't do
Doesn't confirm fraud
It flags a deviation from documented history. Confirming whether a change is genuine or fraudulent remains a human step.
Doesn't make the verification call
It gives you the flag and the comparison. Calling a trusted contact to confirm stays a manual step, by design.
Doesn't block or release payments
It reads and flags. Holding or releasing a payment stays inside your existing approval workflow.
Doesn't work without history
A brand-new supplier has no baseline yet — the very first invoice simply establishes it.
This boundary is deliberate. A tool that silently approved or blocked bank-detail changes on its own would be making a decision with real financial consequences without anyone reviewing it — a flagged, verified change is slower than an automatic one, and for exactly that reason far safer.
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 tracking sensitive payment routing data, that isn't a footnote — the details are on the security page.