Duplicate Payment Control & Recovery

This is not about adding approval steps. Most companies already have payment controls. Those controls do not prove past payments were clean — duplicates still pass through duplicate vendor records, retyped invoice numbers, statement payments, manual payments outside AP, and unapplied credits, then sit unseen for years.

APQC’s Open Standards Benchmarking reports a median of 1.5% of annual disbursements processed as duplicate or erroneous, across 1,686 companies; CFO.com’s APQC data shows roughly 0.8% for top performers and 2% for bottom performers. These count the number of disbursements affected, not dollars lost. Even top performers report some — good controls reduce duplicates, they don’t eliminate them.

Sources: APQC Open Standards Benchmarking; CFO.com discussion of APQC duplicate/erroneous payment data.

Use this when:

• the company has never run a historical duplicate-payment review;
• AP approves payments but never reviews them after release;
• the same vendor may exist under more than one record;
• invoice numbers are sometimes blank, shortened, or retyped;
• vendors send both invoices and monthly statements;
• manual payments (check, ACH, card) can bypass AP matching;
• credit memos are issued but not always applied.

The core question: can finance prove past supplier payments were not duplicated? If not, you need this routine. It is the back-end check many lean finance teams may not run consistently.

Each transaction looks valid on its own. Duplicates only show up when payments are compared against each other.

• Two records for one vendor. “ABC Inc.” and “ABC, Inc.” — the ERP sees two vendors, so duplicate logic never connects the payments.
• Same invoice entered twice. One copy by email, another by paper or portal, both entered as separate bills.
• Statement paid alongside the invoice. An invoice is paid, then paid again when it appears on a statement.
• Invoice number retyped. “INV-10045” becomes “10045” or “10045A” — exact-match checks miss it.
• Manual payment bypasses the bill. The invoice is in AP but also paid by check, ACH, or card outside the normal flow.
• Credit memo never applied. The vendor issues a credit; the company pays the gross amount anyway.

Adding more pre-payment checks creates approval bloat — rechecking thousands of clean payments to catch a few exceptions, slowing everything down. Better to let normal controls run, then sweep the payment data afterward. The worst outcome is not paying twice; it is paying twice and never knowing.

Rule: finance periodically compares paid transactions against each other, recovers confirmed overpayments, and tightens only the control gaps the review proves. A monitoring and recovery rule — not a reason to slow every payment.

Owner: Controller or AP Lead owns the sweeps and recovery; AP staff run the data pull; the ERP administrator supports the export. In small companies, the controller does all of it.

Two routines, same logic:

1. Historical recovery sweep. A look-back over past payments to find duplicates that already left. Go back as far as clean data and your right to recover allow — often 2 to 6 years, depending on records, contracts, and recovery rights. For material recoveries, confirm the window with the contract or policy owner before escalating externally. Run once at adoption, then repeat annually after year-end close. One of the golden rules of accounts payable: once the prior year is closed, run a full sweep across all of that year’s vendor payments — e.g. in January, before the books are truly behind you.
2. Forward monthly sweep. Run the same logic monthly on recent payments so new duplicates are caught while still fresh and recoverable.

The passes (used by both routines):

1. Pass 1 — exact. Same vendor + same invoice reference + same amount to the cent + same currency. Highest confidence; review first.
2. Pass 2 — same amount. Same vendor + same amount + same currency within a date window, ignoring reference. Catches blank or retyped invoice numbers.
3. Pass 3 — broken vendor link. Same amount across different vendor IDs sharing a tax ID, bank account, address, or similar name; also same-amount pairs paid once by bill and once manually.

Exact-amount matching is the starting point, not the whole test — it misses partial payments, rounding, currency conversion, and credits applied to one side. A flag is a review item, not a verdict.

A repeatable payment-data review — via ERP report, BI tool, AP automation, or Excel.

Step 1 — Pull the data. Export paid AP transactions with at least vendor ID, vendor name, invoice reference, invoice date, payment date, amount, currency, payment document/check reference, and payment method. Add tax ID and bank account if available. More fields make false positives easier to clear.

Step 2 — Run the three passes (above). Start with Pass 1 across the full population, then widen.

Step 3 — Confirm before recovery. For each flag, check: same invoice or obligation? already reversed, voided, or credited? a legitimate recurring charge? credit applied to another balance? already resolved later? Only confirmed duplicates move to recovery.

Step 4 — Recover and log. Log each confirmed duplicate: vendor, invoice number, payment dates, amount, root cause, proof, vendor contact date, refund or credit requested, amount recovered, amount written off, date closed. Request a refund or applied credit; escalate unresponsive vendors by materiality. For large historical populations, an external recovery-audit firm (usually contingency-based) is an option, not a substitute for finance ownership.

Step 5 — Fix only the proven gap. Don’t answer every duplicate with another approval layer. Fix the root cause: duplicate vendor records → clean the vendor master; inconsistent references → tighten invoice-number entry; statement payments → stop paying from statements; manual payments → define when allowed and how they reconcile; missed credits → add a credit-review step. Targeted correction, not bureaucracy.

SAP. Export vendor line items and payment documents — vendor, company code, reference, invoice/posting/payment dates, amount, currency. Don’t build around one transaction code; the test is whether finance can export paid supplier items and compare them. Confirm specifics with your SAP config owner.

Other systems. QuickBooks, NetSuite, Oracle, Dynamics, Sage, Xero and AP tools all export vendor/payment reports. If you can export vendor, reference, date, amount, and status, the routine runs — check the available date range.

Excel. Fine for small and mid-sized volumes:

1. Tight key (Pass 1), columns A–D = vendor, invoice no., amount, currency: =A2&"|"&B2&"|"&TEXT(C2,"0.00")&"|"&D2 in column E.
2. Count it: =COUNTIF($E:$E,E2) — any count above 1 is a review item.
3. Loose key (Pass 2): vendor + amount, then filter by date window.
4. Vendor-master test (Pass 3): compare tax IDs, bank accounts, addresses, and names across records.

Large or dirty files may need Power Query, BI, or ERP reporting support. The logic stays the same.

The worst duplicate is the one that stays invisible. Don’t estimate leakage by multiplying spend by the benchmark — it counts disbursements affected, not their value.

Worked example — Harbor Tackle Co. 7,200 supplier disbursements a year:

Dollar impact depends on the payments actually confirmed. Track real recovery, not estimates. Across several years, the same benchmark produces a much larger candidate population — which is why the first historical sweep may surface the largest review population.

Metrics: payments reviewed; candidates flagged; confirmed duplicates; dollars refunded; dollars credited; unrecovered amount open; root causes fixed.

The review also shows whether AP data is clean, whether vendor records are duplicated, whether manual payments bypass process, and whether existing controls work.

• It becomes another approval layer. If it slows every payment instead of reviewing data afterward, it has missed the point.
• The export is incomplete. Without vendor, reference, amount, and date, detection is guesswork.
• Flags aren’t resolved. A list of candidates is worthless unless each is confirmed, cleared, or recovered.
• False positives drown the review. Tag or separate recurring rent, subscriptions, and retainers.
• Recovery isn’t owned. Finding a duplicate isn’t getting the money back — it needs an owner, a log, and follow-up.
• Findings turn into blanket bureaucracy. One duplicate shouldn’t spawn five new approval steps. Fix the specific failure.
• The look-back is skipped. Monthly reviews only catch new issues — they don’t recover old duplicates in prior years.