Duplicate payments: how much is normal, and how to stop them
Every accounts payable team pays some invoices twice. The useful questions are how many, why, and whether your controls would notice. Here is how to find them and keep them from coming back.
Duplicate payments are rarely fraud. They are the by-product of busy teams, several systems and invoices that arrive by post, by email and through a portal at the same time. That makes them common, and it also makes them findable.
How much is normal?
You will hear many figures quoted for the share of payments that are duplicates. Rates vary widely by industry, system and how mature the controls are, so treat any benchmark with care. The only number that matters is yours, and you can measure it in a week.
Why standard ERP checks miss them
Most ERPs block an exact duplicate: same vendor, same invoice number, same amount. Real duplicates are rarely exact.
- Invoice numbers typed differently: INV-1043, 1043, INV1043
- The same supplier under two vendor codes
- Amounts that differ slightly because of tax, rounding or currency
- A credit note and a reissued invoice, both paid
- One invoice paid from two entities in a shared-service setup
The tests that find them
| Test | What it catches |
|---|---|
| Fuzzy invoice number match within a vendor | Typing and format differences |
| Same amount and date across vendors that share bank details | One supplier, two codes |
| Same invoice number, amount within a small tolerance | Tax or rounding differences |
| Same invoice across company codes | Shared-service duplicates |
| Payments after a matching credit note | Paid, refunded, then paid again |
Run them over two or three years of payments. Rank the results by value and confidence, and review the top of the list first.
Recover, then prevent
Recovery is the quick win: most suppliers return a duplicate once you show them the two payments. Prevention is the lasting one.
- Clean the vendor master. Merge duplicate vendors, block the dormant ones and put bank detail changes behind approval.
- Standardise invoice numbers at capture, before they reach the ERP.
- Check before payment, not after. Run the same tests on every payment run, so a duplicate is stopped rather than recovered.
A payments look-back gives you the first number, with every pair of payments and the evidence behind it. Moving the same tests in front of the payment run is what keeps the number small.