The supplier bank-detail gate: stop the invoice that quietly changed its IBAN
One list of the accounts you have actually paid, checked before every payment run
- Twelve months of outgoing bank payments you can export - the trusted list is seeded from what you actually paid, never from the invoice pile
- A phone number per supplier taken from a contract, delivery note or their own website - not from an email signature
- One mailbox and one watched folder that every supplier invoice passes through, with no side channel straight to the person who pays
- A named person accountable for clearing held payments, and a second person who approves any new bank account
- About 8 GB of RAM for the local model that reads the invoices a pattern match cannot
Version history
One list of the bank accounts you have actually paid, checked against every incoming invoice before the payment run — because the wire you send to the wrong account almost never comes back.
The problem
The FBI's Internet Crime Complaint Center logged 24,768 business email compromise reports in 2025, totalling $3.04 billion, at an average above $122,000 per report. 86% of that money moved by wire or ACH. The mechanic is almost always the same and it is boring: a supplier you have paid for years sends an invoice, the account number on it is new, and somebody pays it. Sometimes the supplier's mailbox was taken over, so the thread is genuine and the previous ten messages in it are real. Sometimes it is a lookalike domain nobody read closely. Either way the money leaves on a legitimate, authorised, correctly-approved payment run, which is exactly why the bank will not reverse it.
The control that stops this is not clever. It is a list of the bank accounts you have already paid, and a rule that anything not on that list gets held until someone picks up a phone. Large companies buy this as a product — Trustpair and Eftsure sell it, priced for a business with a treasury department. At small-business scale the open-source shelf is genuinely empty: searching it turns up one research demo and one project with a single star. So this blueprint builds the control out of parts you can verify, and most of them you are probably running already.
The architecture
▼
[ Paperless-ngx — OCR, one archive ]
│ pulls supplier name, amount, account number
▼
[ n8n — the gate ] compares against the list, decides nothing else
├─ account matches the one on file → cleared for the payment run
├─ account differs from the one on file → HELD
├─ supplier not on the list at all → HELD
└─ IBAN fails its own check digits → HELD
▼
[ Baserow — the account list ]
supplier · account paid before · first paid on · approved by · phone number on file
HELD → callback on the number already in your records → approve or reject → written down.
Three parts: an archive that reads documents, a list of accounts you trust, and a rule between them. The important line is the last one. A held payment is released by a phone call to a number you had before the invoice arrived, never to the number printed on it.
Tool choices — and why
Baserow (core MIT, 5.5k stars, pushed 06/08/2026) holds the supplier account list. Any table would do — the reason to use a real database rather than a spreadsheet is the change history: you need to be able to answer "who approved this account, and when" a year later. Grist (Apache-2.0, 11.4k stars, pushed 06/08/2026) is the equally good alternative if you prefer formulas and per-cell access rules.
Paperless-ngx (GPL-3.0, 44.0k stars, pushed 06/08/2026) is the intake. If you already built the receipt and invoice intake blueprint, it is done — this one hangs off the same archive.
n8n (Sustainable Use License, free for internal business use, 199.6k stars, pushed 06/08/2026) is the gate. It compares two strings and writes a decision. That is deliberate: the gate is arithmetic, not judgement.
Ollama (MIT, 177.9k stars, pushed 05/08/2026) reads the invoices a regex cannot. A plain IBAN pattern catches most European invoices on its own; a small local model handles the layouts where the number is split across a table or sits under a logo. The model reads. The rule decides. If you ask a model "does this invoice look legitimate?" you have not built a control, you have built a slot machine that agrees with you.
The check digits are ten lines, not a dependency. Every IBAN carries a mod-97 checksum; validating it catches OCR slips and typos. If you want a library instead, ibantools (MIT or MPL-2.0, v4.5.4, pushed 22/06/2026) does it. Note that a valid checksum proves the number is well-formed, nothing more — a fraudster's IBAN validates perfectly.
Use your bank's free check as a second gate. Since 9 October 2025, under the EU Instant Payments Regulation (EU) 2024/886, euro-area payment providers must offer Verification of Payee free of charge: you supply name and IBAN before authorising, and the bank answers match, close match, no match, or verification not possible. Non-euro-area EU providers follow by 9 July 2027. In the US there is no free equivalent, but the Nacha risk-management rules landing 20 March and 19 June 2026 push account validation on first-use credits down the chain, so ask your bank what it now offers you.
Monthly cost. Software €0. Hosting: €0 extra if this runs on the box already carrying your archive and your automations, otherwise one VPS at roughly €5–12/month. The local model wants about 8 GB of RAM. Your bank's payee verification is free by law in the euro area.
Setup outline
1. Seed the list from your bank statements, not from your invoices. Export twelve months of outgoing payments and build the supplier-and-account table from what you actually paid. Seeding it from the invoice pile imports any fraud already sitting in it.
2. Add a phone number to every supplier row, taken from a contract, a delivery note or the supplier's own website — not from an email signature.
3. Route every supplier invoice into one archive: a dedicated mailbox for the emailed ones, a watched folder for the scanned ones.
4. Build the extraction: regex for the account number and amount first, local model as the fallback for the layouts it misses.
5. Build the gate in n8n. Four outcomes, in this order: unknown supplier, changed account, failed check digits, match. The first three write a HELD record with the old and new account side by side. Only the fourth clears.
6. Give HELD a named owner and a place to live — a Baserow view with a status column, not an email that scrolls away.
7. Write the callback script and put it in the record: who you called, on which number, at what time, and what they said. Two lines is enough. It is your evidence if it ever goes wrong.
8. Run it in report-only mode for one payment cycle: gate flags, nobody blocks. Fix the extraction misses, then turn on the hold.
Pitfalls — the real ones
The number on the invoice is the fraudster's number. This is the whole attack, and calling it is the most common way a good control fails. If the phone number changed in the same message as the bank details, that is not a coincidence, that is the tell.
Domain checks do not catch a hijacked mailbox. Comparing sender domains catches lookalikes and spoofs, and it is worth doing. It does nothing when the supplier's real account has been taken over and the thread is genuine. Only the callback catches that one.
Your own list rots from the inside. Someone will add an account "temporarily" at 17:45 to get a payment out. Require a second person to approve any new account and record who it was — otherwise the list documents your habits rather than constraining them.
Treat "close match" as "no match" the first time. A bank's close-match result on an account you have never paid is the exact situation the control exists for. Close match is only reassuring on an account already on your list.
A hold without an owner gets paid anyway. If nobody is accountable for clearing held items within a day or two, someone releases them from their phone to clear their desk. Assign it, and give it a deadline shorter than your payment terms.
Legitimate changes are common, and that is fine. Suppliers do switch banks and get acquired. The control is not "never change an account", it is "never change one silently". Expect a few calls a month and budget two minutes each.
Check the extraction, not just the gate. If OCR reads the account number wrong, a genuine invoice gets held and trust in the system drops. Spot-check ten a month against the source PDF.
Verified repos
Baserow — core MIT (premium/ and enterprise/ directories under Baserow's own licence), 5.5k stars, active (August 2026)
Grist — Apache-2.0, 11.4k stars, active (August 2026)
Paperless-ngx — GPL-3.0, 44.0k stars, active (August 2026)
n8n — Sustainable Use License (free self-hosted internal use), 199.6k stars, active (August 2026)
Ollama — MIT, 177.9k stars, active (August 2026)
ibantools — MIT or MPL-2.0, v4.5.4, active (June 2026) — optional
Get the next blueprint as it publishes — free, practical, verified tooling only.
Subscribe · Want this audited or extended for your business? DM @RXed_EU
Get this blueprint tailored to your business — free
Tell us what you run and where. We research your sector's specifics — rules, tools, customer habits — and send you a version of this blueprint rebuilt for your situation, usually within 24 hours.