Duplicate payment detection: the audit controls that catch it before the second check clears

Duplicate payments are one of the most common findings in accounts-payable control reviews, and one of the easiest to misunderstand: most people picture an exact duplicate — same invoice, same amount, paid twice — and assume basic software would catch that automatically. The duplicates that actually slip through rarely look identical. They look similar enough to be missed by eye and different enough to slip past a naive exact-match check.

Why an exact-match check is not enough

A vendor resubmits an invoice with a slightly altered reference number after a system migration. A different accounts-payable clerk keys the same invoice from a scanned copy weeks after the original was processed from an email attachment, unaware it had already gone through. An invoice is legitimately split across two payment runs for cash-flow reasons and one half is then paid again by mistake. None of these produce a byte-identical duplicate. All of them produce a real duplicate payment.

What actually catches near-duplicates

Effective duplicate detection compares on a combination of signals rather than exact string match: normalized supplier identity (so "Acme Corp" and "ACME CORPORATION" resolve to the same vendor), amount, and a date window rather than an exact date match — a genuine duplicate is often submitted or paid days or weeks apart, not on the same day. Checking the full historical population, not just the current batch, matters just as much as the matching logic itself: a duplicate paid in March against an original from November will never be caught by a check that only compares within the current month's run.

Why manual sampling misses this structurally, not occasionally

A human reviewer checking a sample of invoices for duplicates has to hold the entire supplier's payment history in working memory, or search for it manually, for every invoice reviewed — practically impossible at any real volume, and the exact reason near-duplicate payments concentrate among high-volume, trusted suppliers rather than one-off vendors. The supplier a reviewer trusts most, and therefore scrutinizes least, is statistically the one most likely to have a genuine near-duplicate slip through, precisely because nobody is checking each new invoice against that supplier's full history by hand.

What to actually check for, beyond the obvious case

• Same amount, different reference number, within a plausible resubmission window.
• Split payments that were never reconciled against each other — two partial payments that together equal a single invoice, where one leg gets paid a second time independently.
• Credit notes issued but never applied — not technically a duplicate payment, but the same category of recoverable error: money the business is owed that a systematic check, not a memory-dependent manual review, is what actually surfaces.

Why duplicates concentrate among trusted suppliers, not unfamiliar ones

The intuitive assumption is that fraud and error risk concentrate among unfamiliar or infrequent suppliers — a one-off vendor nobody has dealt with before feels like the obvious place to look closely. The opposite pattern shows up consistently in near-duplicate payment cases: the suppliers with the highest invoice volume and the longest trusted relationship are the ones whose invoices get the least individual scrutiny per document, precisely because familiarity breeds a lighter review. A reviewer who has processed two hundred invoices from the same long-standing supplier without incident has little reason, on any single new invoice, to stop and cross-check it against the full history — and that is exactly the condition under which a near-duplicate slips through unnoticed.

This is a structural property of how manual review allocates attention, not a commentary on any specific reviewer's diligence. Attention is a limited resource, and it gets spent where risk feels highest, which is rarely where a near-duplicate actually originates. A systematic check does not allocate attention this way — it applies the same comparison logic to every invoice against the full historical population regardless of how familiar or trusted the supplier is, which is precisely why it catches the cases a risk-intuition-driven manual review structurally misses.

What resolution looks like once a duplicate is confirmed

Finding a near-duplicate is the first step, not the last — confirming it typically means pulling both documents side by side, checking whether the second payment actually cleared, and determining whether the correct path is a refund request, a credit against a future invoice, or an internal adjustment if the payment has not yet gone out. None of that resolution work is eliminated by the detection step; what changes is that it happens on a specific, evidenced pair of documents rather than starting from "we suspect something might be off," which is a meaningfully faster and more confident starting point for whoever handles the follow-up.

Related reading

• Audit evidence standards: what ISA 230 and PCAOB documentation rules actually require
• Dormant liabilities and escheatment: what an audit should flag before the state does

FAQ

How far back should duplicate-payment checks look?

As far back as the audit's document population extends — a genuine near-duplicate has no natural time limit, and restricting the check to the current month or quarter is exactly the gap that lets cross-period duplicates through undetected.

Is duplicate-payment detection only relevant for large accounts-payable volumes?

The mechanism that lets near-duplicates through — a trusted, high-volume supplier nobody double-checks by memory — scales with volume, but a smaller business with a handful of recurring high-value suppliers faces the same structural blind spot on a smaller population.

What happens once a duplicate is found — is the money automatically recovered?

No — a finding identifies the duplicate and its evidence; recovering the money still requires contacting the supplier for a refund or credit note, which is a business decision, not something a document check performs on its own.