You have segregation of duties. You have three-way matching. Invoices route through approval workflows, and your ERP flags suspected duplicates at the point of entry. Yet duplicate payments still occur, often in material amounts, and they stay hidden for years.
The reason is structural. Each control addresses one failure mode, but duplicates slip through the gaps between them.
Why Three-Way Matching Does Not Prevent Duplicates
Three-way matching confirms that an invoice corresponds to a purchase order and a goods or services receipt. It validates the current transaction forward — does this invoice tie to something we ordered and received? — but it does not look backward across the history of what you have already paid.
If a vendor resubmits an invoice with a different invoice number, or changes the invoice date, or splits a single charge across two invoices, the three-way match will succeed each time. The control is not designed to detect that you have paid for the same underlying delivery twice.
Why Approvers Miss Duplicates in the Workflow Queue
Invoice approvers see one document at a time. They validate business justification, verify budget availability, confirm correct GL coding, and check that the expense is reasonable. The screen does not present a side-by-side comparison with every prior invoice from the same vendor, nor does it highlight similar amounts paid in prior periods.
The approver’s mandate is forward-looking: should we pay this? Duplicate detection is backward-looking: have we paid this before? The workflow is not built to answer the second question.
Why ERP Duplicate-Detection Rules Have a Narrow Aperture
SAP, Oracle and JD Edwards all include duplicate-checking logic, typically based on exact matches within a defined tolerance. The system flags an invoice if another invoice from the same vendor, with the same invoice number and an identical or very close amount, has been entered recently.
This catches the most obvious duplicates: a clerk accidentally processing the same PDF twice in one session. It does not catch:
- Invoices from the same vendor under different vendor master records — common in SAP when subsidiaries, regional offices or legacy systems each maintain their own vendor file
- Invoices with different invoice numbers for the same deliverable, particularly when a vendor reissues an invoice after a dispute or payment delay
- Amounts that differ slightly due to currency conversion, rounding, or partial payments
- Duplicates separated by more than the system’s lookback window, which is often 90 days or less
- Non-PO invoices, where there is no purchase order number to anchor the comparison
These scenarios are not edge cases. They represent a predictable proportion of real-world duplicate activity.
The Systemic Patterns That Create Duplicates
Certain transaction types and process configurations are structurally more vulnerable.
Non-PO Invoices
Invoices processed without a purchase order — often recurring services, legal fees, consulting, software subscriptions, and employee expense reimbursements — lack the anchoring logic of three-way matching. Duplicate detection relies entirely on data-entry consistency and manual vigilance, both of which degrade under volume pressure.
Decentralised Procurement in Multi-Entity ERP Instances
Large organisations running SAP or Oracle across multiple legal entities often allow each entity to maintain its own vendor master data. The same supplier appears under different vendor IDs, sometimes with slight name variations. A duplicate-detection rule that requires an exact vendor-ID match will not correlate payments made by two subsidiaries to the same economic counterparty.
Invoice Resubmission After Payment Delays
When payment is delayed — due to a missing PO, a dispute over quantity or quality, or a held invoice pending budget approval — vendors frequently reissue the invoice with a new invoice number and current date. If the original invoice is later released and paid, both payments go through. The new invoice number bypasses the duplicate check, and the time gap means the two transactions may never appear on the same exception report.
Partial Payments and Invoice Splitting
Some vendors submit a single project or milestone in multiple invoices, either because of internal billing-system constraints or to work around payment-amount thresholds. If the AP team processes these as separate line items without a common reference, and if a consolidated invoice is later submitted and paid, the total paid exceeds the total owed. The ERP sees distinct invoice numbers and distinct amounts; the duplicate logic does not trigger.
How Duplicates Are Found
Duplicate identification is a structured data exercise. It requires analysing the entire paid invoice population across multiple dimensions simultaneously:
- Vendor name and address, normalised for variations in punctuation, legal suffixes and abbreviations
- Payment amount, with tolerance bands to catch rounding differences and currency-conversion discrepancies
- Invoice date and payment date, examined over a wide window — often 12 to 24 months
- Invoice description or line-item detail, where available, to identify the same service or deliverable described in different wording
- Bank account details, to detect payments to the same beneficiary under different vendor names
This cross-comparison generates a candidate list. Each candidate is then reviewed against source documents — purchase orders, contracts, delivery confirmations — to determine whether two payments represent two separate obligations or a single obligation paid twice.
The work is detail-intensive, but it follows a repeatable methodology. It does not require process reengineering or system changes. It is a forensic backward look through data that already exists.
What Happens After Recovery
Once duplicates are confirmed, the recovery process is straightforward. The vendor’s finance contact is approached with documentation. Most vendors, presented with clear evidence, issue a credit note or cheque without dispute. The interaction is a factual correction, not an accusation, and does not damage the commercial relationship.
Recovered funds flow back through the normal accounts-receivable process. There is no restatement of prior-period financials; duplicate payments are operational errors, not accounting misstatements.
If your AP spend exceeds $50 million annually and you run SAP, Oracle or JD Edwards, a percentage of that spend has been paid twice. The controls you rely on were not built to catch it. A single backward sweep through your paid-invoice data will surface it — and the cash comes back.
Frequently asked questions
Why do duplicate payments happen even with three-way matching?
Three-way matching validates invoice-to-PO-to-receipt alignment but does not compare the current invoice against all prior payments. If a vendor resubmits an invoice with a different invoice number or date, the match succeeds. The control checks forward to the order, not backward through payment history.
What makes SAP environments particularly vulnerable to duplicate invoices?
SAP allows the same vendor to be registered multiple times under different master record numbers, often with slight name variations. Payments to what is operationally the same supplier can scatter across vendor codes, so duplicate-detection rules that rely on exact vendor-ID matching will miss them. Decentralised procurement in multi-company SAP instances compounds this.
How do invoice-level approval workflows fail to catch duplicates?
Approvers see one invoice at a time and validate business justification, budget availability and proper coding. They are not shown a side-by-side comparison with prior invoices from the same vendor for similar amounts. The approval queue is forward-looking; duplicate detection requires a backward look across the entire paid population.
Can ERP built-in duplicate checks be relied on completely?
Built-in checks typically flag exact matches on vendor ID, invoice number and amount within a narrow time window. They miss fuzzy duplicates: slightly different amounts due to currency rounding, different invoice numbers for the same service, invoices paid months apart, or submissions through different legal entities. A significant proportion of real-world duplicates fall outside these narrow parameters.
What transaction types are most prone to undetected duplication?
Non-PO invoices — particularly recurring services, consulting fees, software subscriptions and expense reimbursements — carry higher risk. Without a purchase order and goods receipt to anchor the transaction, duplicate detection depends entirely on data-entry consistency and manual review, both of which are inconsistent under volume pressure.
How do you recover duplicate payments without disrupting vendor relationships?
Recoveries are handled as factual corrections, not accusations. Documentation is compiled, the vendor finance contact is approached with specifics, and a credit or cheque is requested. Most vendors cooperate when presented with clear evidence. The process is routine commercial hygiene, not conflict.
