Learn

Duplicate payments: how to detect what exact-match checks miss

TL;DR: Duplicate and erroneous invoices cost companies 0.3–0.7% of AP spend, or an average of $3.5M per $1B of spend (SSON/Xelix analysis of 481M invoices, 2026). Many survive because ERP controls match exact invoice fields, while real duplicates often differ by a character, vendor record, or legal entity. Detecting them requires fuzzy matching across systems and, where the ledger is ambiguous, review of the source documents.

Why do duplicate payments happen?

They rarely come from paying the same clean invoice twice. More common paths include:

  • Near-duplicates. The same invoice is resubmitted with a transposed digit, an added suffix, or a character read incorrectly, or it is keyed manually after arriving electronically.
  • Vendor-master duplicates. One supplier has two records because of legal-form variants, abbreviations, or spelling differences.
  • Cross-entity gaps. Two group entities or ERPs pay one invoice, and neither system sees the other payment.
  • Exception-queue pressure. Median AP exception rates run at 11–14% of invoices (SSON R&A, 2026), so resubmission can be faster than investigation.
  • Migrations and acquisitions. Open items are re-keyed during system cutovers, increasing the risk of duplicated records.

Manufacturing has the highest measured exposure at 0.72% of spend, including 0.66% attributed to duplicates. The corresponding rates are 0.52% in healthcare, 0.45% in pharma, and 0.44% in retail and CPG (SSON/Xelix, 2026).

Why doesn't our ERP catch them?

ERP duplicate controls, including standard SAP checks, typically compare exact fields such as invoice number and vendor. A one-character change, a second vendor record, or another entity can allow the invoice through. The evidence that resolves the ambiguity is often in the PDF: the same layout, line items, and delivery reference. Ledger-only controls do not inspect that evidence.

See the broader distinction between ledger-based AP controls and document-level investigation, or review the data needed for a lookback audit.

How do you find duplicate payments across the full population?

A full-population review combines fuzzy matching across entities and ERPs, vendor-master normalization, and source-document comparison where ledger fields are inconclusive. That is the accounts-payable portion of a lookback recovery audit.

In one cloudsquid customer deployment, agents audited 100% of one year's AP transactions in under two hours. In a separate cloudsquid customer result, monitoring at a US beverage manufacturer surfaced a $50K duplicate invoice.

How do you prevent the next duplicate?

Run the same checks before the payment run: screen each invoice against payment history, open items, related entities, and vendor-master changes before money moves. Ambiguous cases should be flagged for review rather than guessed at. The accounts payable use case shows how historical recovery becomes pre-payment control.