Open a single $1 billion spend file and 0.35% is an unremarkable number: $3.5 million. Multiply that rate across the UK and US mid-market and the same fraction becomes $53 billion a year.
That is the arithmetic behind the quietest line item in most enterprises. Not fraud, not a bad acquisition, not a failed system implementation. Just money that left through a seam between two systems that never quite agreed.
Two datasets, published months apart
In 2026, two vendors published research on the same problem from opposite ends of the pipeline.
Xelix, which sells accounts payable controls, analyzed 481 million invoices processed through its platform and reported that companies leak an average of 0.35% of annual spend, or $3.5 million for every $1 billion spent. Its report, dated March 12, 2026, breaks the leakage into four sources: duplicate payments, invoicing errors such as omitted discounts or wrong tax, missed credit notes, and outright fraud.
The $53 billion headline requires care. The company states it derived the figure by applying its own customer benchmarks to the broader population of UK and US businesses with turnover above $130 million and more than 250,000 invoices annually, then added that actual rates may vary by industry, size and AP maturity. It is a modeled market estimate built on real platform data — not an audited total.
apexanalytix took a different sample: $3.25 trillion in corporate spend and more than 400 million invoices, reported in its 2026 Global Overpayment Report and covered by CFOtech New Zealand on June 9, 2026. Its loss distribution tells a more useful story than any total.
| Loss category | Share of losses |
|---|---|
| Duplicate payments | 18% |
| Payments tied to canceled invoices, contracts or services | 14% |
| Pricing discrepancies | 13% |
| Remaining categories, including returns and unclaimed rebates | Balance |
Read those three lines again. A duplicate is a data problem: the same supplier, a near-identical invoice number, a matching amount. A canceled commitment is a coordination problem. A pricing discrepancy is a contract-versioning problem. Only the first would be caught by a rule that says \"same invoice number, same amount, already paid.\"
The invoice arrives already wrong
apexanalytix's central argument is the one finance leaders should carry into a budget meeting: many overpayments begin in operational handoffs that accounts payable does not own.
A service is canceled and the cancellation never reaches the central payment system. Goods are returned to a warehouse and credited in the inventory system but never matched to a financial credit. Negotiated pricing is updated in a contract repository and not in the invoicing system. In each case, the invoice entering AP is already incorrect, and the team processing it is measured on speed and accuracy of payment, not on whether the underlying transaction should exist.
Phil Beane, president of global transaction compliance solutions at apexanalytix, framed it plainly: \"AP leaders are responsible for making payments accurately and efficiently, but many overpayments begin in operational handoffs they do not fully own.\"
That is a governance statement disguised as an observation. If the error originates in a handoff, then fixing it inside AP is treating a symptom at the last possible moment.
Why ERP controls miss most of it
Xelix's report is direct on this point. Rules-based controls, including those built into ERP systems, routinely miss near-duplicates and cannot learn from past mistakes. Manual supplier reconciliation typically covers only 10 to 15 percent of suppliers. Emails and spreadsheets remain in the workflow.
The structural reason is straightforward. A rules-based control encodes what someone anticipated. A near-duplicate invoice — one digit different, issued two days later, for the same purchase order — was not anticipated. Neither was a credit note sitting in a supplier statement that nobody pulled.
And there is a second problem the research surfaces: timing. A discrepant payment caught the day it appears can be corrected against the counterparty. The same discrepancy found at month-end close, after the cycle has closed, usually becomes a write-off. Detection delay is not a reporting inconvenience. It is the mechanism that converts recoverable money into an accounting entry.
Payroll and commissions: the same shape, thinner evidence
The published 2026 research concentrates heavily on accounts payable, because that is where the vendors who fund the research sell. Two adjacent categories almost certainly behave the same way and are far less measured.
This is inference, labeled as such. A commission calculation is a reconciliation between a contract, an order, a return and a payment — four records in at least three systems, each with its own effective date. A payroll discrepancy is a reconciliation between a hire record, a time record, a rate change and a deduction schedule. Both have exact duplicates, near-duplicates, stale rates and timing gaps. Both are typically checked by sample or by exception rather than in full.
What the research does supply is the cost of not checking. A June 4, 2026 analysis cites Datos Insights finding, in a June 2025 vendor landscape report hosted by FIS, that financial institutions without mature pricing governance experience revenue leakage of 5 to 15 percent of potential earnings through unauthorized discounts, inconsistent pricing policies and inadequate monitoring of fee waivers. The same piece cites an FIS survey of more than 1,000 C-suite executives and business leaders estimating an average $98.5 million in annual losses from operational inefficiency across billing, data collection and reporting workflows.
Both are third-party findings relayed through a vendor blog, not primary documents retrieved here. Treat them as directional. The direction is consistent with everything else in this article.
What governed AI actually changes
The distinction that matters is not AI versus no AI. It is sampling versus coverage, and after-payment versus before-payment.
Manual reconciliation covers a subset of suppliers. Rules-based controls cover anticipated patterns. A model trained on a company's own payment history can compare a candidate transaction against every prior transaction, contract version and supplier record, and flag the ones that deviate — including deviations nobody wrote a rule for. That is a coverage change, not a cleverness change.
Three patterns are worth pursuing, and each is bounded.
- Pre-payment duplicate and near-duplicate detection. Score every invoice against history before release, not a sample after close.
- Obligation tracking across systems. Match cancellations, returns and credit notes to the payments they should have reduced, and surface the unmatched ones with an owner and an age.
- Contract-to-invoice price validation. Check each billed line against the effective contract version, and flag where the two disagree.
None of these replace a system of record. All of them read from systems that already exist.
Four conditions that decide whether it pays
1. The finding has an owner and a dollar value. An exception queue that ranks a $4 rounding difference alongside a $40,000 unrecovered fee is a queue nobody works.
2. The model is allowed to abstain. A detector that must classify every transaction will classify some wrongly and confidently. A confidence floor converts an unbounded risk into a measurable coverage rate.
3. Consequential actions stay staged. Recommendations should write to a review table with the underlying evidence visible, not directly to the payment run. A human approves; the system records what changed.
4. The audit trail is queryable without the vendor. When a controller is asked why a payment was released, the answer has to come from records the company holds.
Integration without replacement
The practical objection is always the same: we cannot rip out the ERP. Nobody is asking you to.
Most of this work sits at the boundary. Read supplier master, invoice history, purchase orders and payment records through interfaces the ERP already exposes. Write findings to a separate review store. Push approved actions back through the same APIs. The ERP remains authoritative; the control layer stays additive and removable.
The hard part is not connectivity. It is field ownership. If the warehouse system holds the authoritative on-hand quantity and the ERP displays it with a lag, then any reconciliation reading ERP inventory will produce confident, wrong conclusions — and it will do so consistently, which makes it harder to notice.
An illustrative calculation, clearly labeled
Constructed to show the method. No real company or result is described.
A distributor spends $500 million a year with suppliers. At the Xelix benchmark rate of 0.35%, gross leakage is roughly $1.75 million.
Assume a detection program recovers 40% of it — $700,000 — and costs $250,000 in platform, integration and internal review time in year one. Net benefit is $450,000. In year two, integration cost drops out and the figure improves.
Now the honest caveats. The 0.35% rate comes from a vendor's customer base and may not transfer. Recovery rates depend entirely on how quickly items are found. And a program that produces findings nobody investigates recovers nothing while costing the same.
Why prevention beats recovery audits
Xelix's report is pointed about the alternative. Recovery audits are described as reactive and expensive, charging fees of 15 to 25 percent of funds recovered and addressing only a fraction of potential losses.
Paul Roiter, the company's chief executive, put it bluntly: \"We're calling time on recovery audits. They don't solve financial leakage. They usually only address a small proportion of potential losses. Not to mention, they're expensive, and they don't stop the leakage from happening. It's far better to prevent leaks before the money leaves the building.\"
That is a vendor arguing for its own product category, and the argument still holds on the merits. A 20 percent contingency fee on recovered cash means the leakage rate has to be large before recovery is worth doing — and the fee is paid whether or not the underlying process changes.
The approval-rate trap
Every program of this kind eventually reports an approval rate, and that number is usually read backwards.
A reviewer approving 98% of flagged exceptions is not evidence of a good model. It is evidence the review step has stopped functioning — either the flags are wrong, or the reviewer is clicking through. The useful metric is agreement: sample approved items monthly and ask whether a reviewer would approve the same item today.
What to measure
| Signal | What it tells you | Weak proxy to retire |
|---|---|---|
| Recovered versus identified dollars | Whether findings convert to cash | Exceptions flagged |
| Detection lag | Days between a discrepancy appearing and surfacing | Report delivery date |
| Reviewer agreement on sampled approvals | Whether human review is real | Approval rate |
| Write-offs attributable to undetected error | The cost of the gap | Recovery audit fees |
| Suppliers reconciled in full | Coverage, not sample size | Percent of suppliers reviewed manually |
The question a CFO should ask
The interesting number in this research is not $53 billion. It is 18 percent — the share of leakage that a simple duplicate rule should already catch. If a mature controls environment is still losing on duplicates, the controls are checking the wrong thing at the wrong time.
The rest of the loss distribution is a map of organizational seams: cancellations that never reached finance, returns that never became credits, contract terms that never reached the invoice. Those are not detection failures. They are handoff failures, visible only to something that reads across all of them at once.
That is the realistic promise of governed AI in finance. Not autonomy over the payment run. Coverage over the seam — with a person still signing, and a record explaining why.
Hashtags
#FinancialControls #EnterpriseAI #CustomSoftware #SystemsIntegration #BusinessAutomation #CFO #ERPIntegration #DataGovernance #AIGovernance #RiskManagement #OperationalExcellence #AccountsPayable #RevenueLeakage #DigitalTransformation #ITLeadership #InternalControls #BusinessStrategy #DataIntegrity #WorkflowAutomation #SupplyChain