A supplier sends a statement showing a credit balance on your account, and nobody in AP can say where it came from. Tracing it takes an afternoon: the same invoice arrived by email and by post, was keyed twice a week apart, and was paid in two runs. This vendor flagged it. Many duplicate payments are never flagged and sit as credits in a supplier's ledger until someone asks.
Most ERPs check for duplicate invoices. Duplicates still get through, because the second copy rarely looks exactly like the first.
How duplicate payments happen
Re-keyed invoices. The same invoice arrives through two channels, or a reminder copy arrives after the original. It is keyed again with a slightly different reference, a different invoice date or a rounded amount.
Duplicate vendor records. One supplier exists twice in the vendor master, perhaps after an acquisition, a change of name or a new remit-to address. The duplicate check runs within a vendor, so an invoice posted to each record passes.
Reference format variations. INV-0042, INV0042, 0042 and 42 are the same invoice to a person and four different invoices to an exact-match check. Dates keyed in day-month and month-day order cause the same problem.
Credit memos and reversals. An invoice is reversed and re-posted, and the original payment is not matched to the new document. Or a credit memo is entered as an invoice and paid.
Manual payments outside the run. An urgent wire goes out for a supplier who is threatening to stop deliveries. The invoice is later posted in the normal way, nothing links it to the manual payment, and the run pays it again.
We have not found a published duplicate-payment rate we would cite with confidence. The closest broad measure is APQC Open Standards Benchmarking (cross-industry median, all companies): 95.0% of disbursements are first time error free, across 2,479 companies. That covers every kind of disbursement error, not duplicates alone.
Preventive and detective controls for duplicate payments
A preventive control stops the second invoice from being posted or paid. A detective control finds it afterwards. Both matter, and the most useful detective control runs before the money leaves.
| Control | Type | What it catches | Where it falls short |
|---|---|---|---|
| ERP duplicate invoice check set to block, not warn | Preventive | Exact repeats of vendor, reference, date and amount | Format variations; duplicate vendor records |
| Reference entry standard (no prefixes, no leading zeros) | Preventive | Keying variations | Depends on discipline and on OCR settings |
| Duplicate check at vendor creation (tax ID, bank account, address) | Preventive | A second record for an existing supplier | Weak if the master is already untidy |
| Manual payments posted against the invoice before release | Preventive | Payment outside the run followed by payment in it | Urgent requests that skip the rule |
| Near-match review of the payment proposal | Detective, before payment | Fuzzy duplicates in this run against recent history | Needs time in the run calendar |
| Vendor statement reconciliation and periodic recovery review | Detective, after payment | Anything the earlier controls missed | Money has left; recovery depends on the vendor |
Two settings are worth checking this week. One is whether the ERP's duplicate check stops the posting or only warns; a warning AP clicks through daily is a weak control. The other is which fields it compares, a choice the controller should document.
Fuzzy matching: what it adds and where it misfires
Fuzzy matching compares invoices on how alike they are, not whether they are identical. A typical approach normalises the reference (stripping prefixes, spaces and leading zeros), then scores pairs on reference similarity, amount, invoice date, vendor name and bank account. Pairs above a threshold go to a reviewer.
It produces false alarms. Monthly rent, retainers and instalments repeat the same amount by design. Treat recurring payments as a separate class with their own expected schedule, or the review list fills with noise and people stop reading it.
AI has a place here. Error and anomaly detection was among the top AI use cases, at 34%, in Gartner's May and June 2025 survey (183 CFOs and senior finance leaders). In payables, a model can compare the invoice documents, line items included, and say plainly why two look like one: same PO, same delivery note, references differing only by a prefix. It can also link a manual payment to the invoice it settled.
It should not stop a payment on its own. A flagged pair goes to a person who checks the documents and decides whether to hold. Log every flag and every decision, so the controller can see how often the flags are right.
Recovering a duplicate and fixing the cause
When a duplicate is found after payment, ask the vendor for a refund or agree an offset against the next invoice, in writing. Then trace which control failed: a vendor record that should have been merged, a manual payment never linked, a check set to warn. Fix the control as well as the transaction.
Reconciling statements from larger suppliers finds credits they have not mentioned. It is dull work and the last line of defence.
What duplicate payment controls will not fix
They will not catch a payment that is designed to look different. An invoice from a fictitious vendor, or a genuine invoice paid to a changed bank account, is not a duplicate. That is a vendor master problem and needs its own controls.
They will not make up for a vendor master that is already full of duplicate records. Matching on tax ID and bank account helps, but cleaning the master is a separate piece of work that someone has to own.
Frequently asked questions
What causes duplicate payments in accounts payable?
Duplicate payments are usually caused by the same invoice being keyed twice with small differences, by duplicate vendor records, by manual payments that are not linked to the invoice, or by mishandled credit memos and reversals.
Why does the ERP's duplicate invoice check not stop every duplicate?
It does not, because it looks for an exact match on a fixed set of fields. A reference keyed differently or a second vendor record is enough to pass it.
What is the difference between preventive and detective controls for duplicate payments?
A preventive control stops a duplicate invoice from being posted or paid, while a detective control finds it afterwards. The most useful detective control reviews the payment proposal for near-matches before the money leaves.
What is fuzzy matching for duplicate invoices?
Fuzzy matching scores pairs of invoices on how similar they are across reference, amount, date, vendor and bank account, rather than requiring an exact match. Recurring payments need separate treatment or they produce false alarms.
How do you recover a duplicate payment?
Ask the vendor for a refund or agree an offset against the next invoice, and confirm it in writing. Then trace which control failed and fix it.
Where CFOLogic fits
Our AI work on payables starts as a proof of concept on one process, built over the ERP the team already runs. It is read-only by design, and holding a flagged invoice stays a human decision. For the exception-queue approach in practice, see the Command Center demo for purchase-to-pay, which uses a fictional company.