Your AP Controls Were Designed to Catch a Bad Invoice, Not a Convincing One

Two identical invoice shapes side by side, one dissolving into pixels at its edge, passing through a filter that only catches the obviously broken one

Your AP Controls Were Designed to Catch a Bad Invoice, Not a Convincing One

The volume of attempts has barely moved. The quality has. That breaks a specific category of control — and it isn't the one most teams are worried about.

Most accounts payable control frameworks contain, somewhere in them, an unwritten assumption: that a fraudulent invoice will look like a fraudulent invoice. Odd formatting. A supplier name that's almost right. An email address with a transposed letter. The control isn't really "three-way match" — it's "an experienced person in AP will notice something is off."

That assumption held for a long time. It is the specific thing that generative AI has quietly removed, and it's worth being precise about how, because the popular framing gets it backwards.

What the numbers actually say

The National Anti-Scam Centre's Targeting Scams Report for calendar 2025, published in March this year, put combined reported scam losses in Australia at $2.18 billion — up 7.8 per cent on 2024, though still well below the 2022 peak of $3.1 billion. Within that, payment redirection scams accounted for $166.8 million, the second-largest category by loss behind investment scams at $837.7 million. Payment redirection is the one that lands squarely in a finance function: business email compromise, false billing, and the change-of-bank-details request that turns out not to be from your supplier.

Alongside it, the FBI's Internet Crime Complaint Center devoted a dedicated section to artificial intelligence for the first time in the report's nearly twenty-five-year history, logging 22,364 complaints carrying an AI-related descriptor and US$893 million in adjusted losses for 2025.

$166.8m
Reported Australian losses to payment redirection scams in 2025 — the second-highest loss category, and the one that runs through an AP function.
22,364
Complaints with an AI-related descriptor logged by the FBI's IC3 for 2025, representing US$893m in adjusted losses — the report's first dedicated AI section in nearly 25 years.

Two honest caveats. Neither of these is breaking news — the Australian figures are from March, the US ones cover last calendar year. And the AI attribution in the FBI data is self-reported, meaning it reflects only what victims recognised as AI. That cuts both ways: the true figure is almost certainly higher, but nobody can tell you by how much.

What the data does support is narrower and more useful than "AI fraud is exploding." In Australia, reported volumes were essentially flat — 481,523 scam reports in 2025 against 494,732 the year before — while losses rose 7.8 per cent. Report volumes in the US data did rise, so this is a claim about the Australian reported picture rather than a global one. Either way, the striking change isn't how many attempts arrive. It's what one looks like when it does.

Why "does this look wrong?" is now a failing control

Sort your AP controls into two buckets.

The first bucket contains controls that work by detecting anomaly — someone reads the invoice and it doesn't feel right, the email tone is off, the logo is slightly wrong, the English is stilted. These have been the workhorse controls in small and mid-sized finance teams for decades, because they're free and they mostly worked.

The second bucket contains controls that work by requiring an independent confirmation — the payment can't proceed unless something outside the request itself agrees with it. Out-of-band verification. Dual authorisation across separate channels. A supplier master file that only changes through a defined process.

Generative tools degrade the first bucket and leave the second bucket entirely intact. A convincing invoice, a cloned voice on a phone call, a plausible email in your CFO's writing style — all of these defeat "does this look wrong?" and none of them defeat "we rang the number we already had on file and asked."

The implication for a finance leader is uncomfortable but clear: any control whose effectiveness depends on a human noticing something unusual should now be treated as a secondary control, not a primary safeguard. Keep it — it still catches the lazy attempts, and it's free. But when you describe your control framework to a board or an auditor, the weight has to sit on the second bucket. A framework that rests primarily on vigilance is describing a hope, not a control.

The one that matters most: a change to a supplier's bank details is not an administrative update. It is a payment instruction affecting every future invoice from that supplier. If your process treats it as a data-entry task that anyone in AP can action from an emailed request, you have a single point of failure with no ceiling on it.

Three controls that still hold

Out-of-band verification against details you already held. Not the phone number in the email signature. The number in your supplier master file, or on last year's contract. This is the single highest-value control in the whole set, and its effectiveness comes entirely from the fact that the attacker doesn't control the channel.

Dual authorisation that can't be satisfied through the same channel the request arrived on. Two approvers who both only ever saw the same email is one approver with extra steps. The second approval has to be anchored somewhere the request didn't come from.

A supplier master file with a change process, not a change form. Every bank detail change dated, evidenced, verified by a named person against a previously held contact, and reportable. If you can't produce a list of every bank detail change in the last six months in under five minutes, that's the gap.

The process that should deliberately get slower

Nearly every automation conversation in AP is about speed — faster coding, faster approval, faster payment runs. That's mostly the right instinct, and it's where the genuine efficiency sits.

Bank detail changes are the exception, and they should be carved out explicitly. Introduce a mandatory cooling period between a change being requested and it being usable for payment. Notify the supplier on their previously held contact details that a change was made. Neither of these improves throughput; both of them convert a same-day loss into a caught attempt.

This is worth saying plainly to whoever is selling you AP automation: the correct answer to "we can process bank detail changes instantly" is that you don't want that.

Where AI belongs — on your side of the ledger

The useful application isn't a tool that reads an invoice and decides whether it's genuine. That's the same failing control, relocated.

The useful application is pattern work across your own history — the kind of comparison that's tedious and therefore never done. Flagging a payment to a bank account that has never been used for that supplier before. Flagging a supplier whose invoice frequency or amount profile has changed sharply. Flagging invoices that arrive just under an approval threshold. Flagging a new supplier paid within days of being created.

None of those judgements are hard. They're just impossible to do consistently by eye at volume, which is exactly the division of labour that works: the AI produces a short list, a person decides. The measure of whether it's working is not how many alerts it raises but whether the alerts get actioned — an anomaly report nobody reads is worse than no report, because it looks like a control in your framework.

Before supplier and payment data goes into an AI tool: supplier bank details, payment histories and approval records are among the most sensitive data a finance function holds. Confirm whether the vendor retains customer inputs for model training before anything is uploaded, and prefer a tool where it doesn't — you want to be able to answer that question in writing, not from memory.
This post is general commentary based on publicly available information and does not constitute legal or financial advice. Always seek independent professional advice before acting.

A thirty-minute review worth doing this week

Four questions. If you can't answer one of them from memory, that's your answer.

1. How many supplier bank detail changes were processed in the last six months, and who verified each one?

2. If a request to change bank details arrived by email today, what is the documented next step — and is it written down anywhere, or does it live in one person's habits?

3. Can a payment be approved twice by people who only ever saw the same email?

4. What's the largest single payment that could leave the organisation without a second person independently confirming the destination account?

The last one is the number to take to your board. Not a statistic about fraud trends — your own figure, calculated from your own delegations. It reframes the conversation from "are we worried about AI" to "here is our maximum single-transaction exposure, and here is what we propose to do about it."

What's your maximum single-payment exposure?

If nobody has calculated it, the control framework is describing an intention rather than a position. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations.

Talk to PFL →
Timothy, CPA is Managing Director of Professional Financelink (PFL), providing senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations. 20+ years in finance leadership across NFP, NDIS and SME.

Comments

Popular posts from this blog

Google Gemma 4 Just Launched — And It Might Solve Finance's Biggest AI Privacy Problem

Claude vs Gemini for Australian Finance: An Honest Comparison After 12 Months of Using Both

Why NFP Boards Are Finally Talking About AI — And What the Finance Team Should Do Before They Ask