The fraud moved upstream. Most AP automation is still guarding the invoice.

On July 1 the Journal of Accountancy published a guide to AI-fuelled AP and AR fraud, and one line in it describes the whole problem better than any product pitch I have read this year: "Fraudsters are using AI tools to intercept invoice PDFs in transit and alter bank account numbers in a way that is visually indistinguishable from the original document." Same logo, same layout, same font, same total. One field changed. The account the money lands in.

Read that and the instinct is to reach for a better scanner. Sharper OCR, tighter duplicate detection, a machine that reads the PDF and catches the swapped digits. That instinct is wrong, and it is wrong in a way worth an entire post, because the con that actually drains the account does not touch the invoice at all.

The AFP put numbers on the year in April. Seventy-six percent of organisations reported attempted or actual payments fraud in 2025, which was a slight decline on the year before. Business email compromise hit 74%. Only 17% of organisations use AI to defend against any of it. So the volume did not explode. If anything it dipped. What changed is not how much fraud there is, it is how convincing a single attempt can be for someone with no particular skill. Jonathan Marks at BDO put it in one line: "What AI has done is dramatically lower the competence threshold." You no longer need a forger. You need a prompt.

Everyone is writing this as an AI story. Deepfaked voices, cloned finance directors on a Zoom call, generated invoices you cannot tell from the real one. It reads like a thriller, and the thriller framing sells AI features to defend against AI attacks. I do not think the AI is the door. The AI is just what walked through it.

The door was open before the AI showed up

Here is the con that does not bother with your invoice. The attacker does not fake a bill. They send a bank change request. A short, polite email from what looks like your supplier, or a phone call, asking you to update the account on file because they switched banks. You update the vendor record. One field. From that moment every legitimate invoice that supplier ever sends you routes money to the attacker, and so does every real approval your team signs off in good faith. Automatically. Faithfully. Your three-way match still passes, because the invoice is genuine. Your duplicate detection stays quiet, because nothing is duplicated. The system does exactly what it was built to do, against standing data that is now a lie.

Finexio named the gap plainly last month: the vendor master sits outside the audit cadence. Invoice-level controls inspect transactions. They do not inspect the vendor's bank details, because those are treated as reference data, a field on a record, the digital equivalent of a mailing address. And Clay Kniepmann at Anders described the far end of the same weakness, criminals building complete vendor identities with AI-generated W-9s and websites that pass a surface-level onboarding check. The whole attack surface is standing data that everyone assumes is settled. It is the one thing your automation trusts without re-checking, so it is the one thing worth corrupting.

This is a data-model problem wearing an AI costume. The open door has been there since someone decided that editing a supplier's bank account belonged to the same low-friction workflow as fixing a typo in their address.

Why we split the table in two

Calabash keeps two separate homes for a supplier's bank account, and it is deliberate. There is the account a supplier submits during onboarding and KYC, which lives with their business-partner profile. And there is the account treasury has independently vetted, which is the only account a payment run is ever allowed to disburse against. They are parallel by design. The vetted one is the source of truth for money leaving the building. The submitted one is a claim, not a payment instruction.

The practical effect is small and, I think, the whole point. A bank detail cannot become payable just because a form field changed. A supplier can update what they submitted all day. Nothing moves until someone with the authority to vet it moves it across to the treasury side, on the record, which is the same boring work of supplier bank verification we have written about before. The bank change email that would quietly reroute every future invoice at most changes a claim. It never reaches the account that pays.

I will admit the uncomfortable part. More than once during the build, the sensible engineering instinct was to collapse those two tables into one. Two parallel records holding a bank account looks like duplication, and duplication looks like a smell you clean up. Every time it came up, keeping them apart felt like friction we were choosing on purpose, and defending "on purpose" is harder than defending "obvious." Then you read a week of coverage like this one and the friction is the feature. The gap between what a supplier says their account is and what treasury has confirmed it is, that gap is not overhead. That gap is the control.

None of this is exotic. The consensus practitioner advice landing across every AP piece this cycle is two lines. Never use the contact details in the change request itself, pull the supplier's number from your own system instead. And require two people to approve any bank detail change. Both are just segregation of duties, the last human control that voice cloning has not fully beaten yet. The reason I keep coming back to the architecture is that a control you have to remember to run is a control someone eventually skips at 4pm on a Friday. A control the data model enforces runs every time, whether anyone is paying attention or not.

If you run AP or treasury, the test is simple and slightly uncomfortable. Ask what happens in your system when a supplier's bank account changes. If the answer is that a field updates and the next payment run just uses it, you are guarding the invoice while the money leaves through the vendor master. That is the same question we laid out in how to evaluate a treasury platform, pointed now at the one record everybody forgets to audit.

Sign up at calabash.app/b2b and bring us the last time a supplier told you they were changing banks. We will walk through exactly what our vetted-account flow does with that request, where it stops, and who has to touch it before a single payment run can see the new number. If your current setup already stops it cold, we will tell you, and you can go spend the afternoon on a real problem instead.