.svg)
According to Peakflo's 2026 AP controls guide, duplicate payments cost businesses between 1 and 5% of total AP spending annually. The average company makes duplicate payments on 0.1 to 0.8% of invoices processed. On a £10 million payables run, even the lower end of that range represents £10,000 to £80,000 leaving the business that should not have.
Some of it comes back through recovery audits. Much of it does not. Suppliers who receive a duplicate payment are not legally required to flag it, and many do not.
The more significant problem is that duplicate payments are almost entirely preventable. They are not the result of sophisticated fraud or complex system failures. They are the result of a predictable set of process gaps that allow the same invoice to be processed and paid more than once. Closing those gaps is straightforward with the right controls. Leaving them open is expensive.
This guide covers what causes duplicate payments, why manual detection consistently misses them, and what changes when automation handles the detection that human review cannot do reliably at volume.
A duplicate payment is any second payment made against an invoice or obligation that has already been settled. It is a controls failure, not usually fraud, though fraudsters exploit the same gaps that allow honest mistakes to occur.
The most obvious duplicates are easy to catch: the same invoice number, the same supplier, the same amount, submitted twice. Exact-match rules in any ERP will catch these.
The costly duplicates are the fuzzy ones. As Corpay's July 2026 analysis explains: "Invoice references get stripped of prefixes, punctuation, and leading zeros. Vendor names get standardized against the master record. Amounts and dates get compared within a tolerance band instead of exactly. Once the fields are normalized, 'INV-5521' and '5521-OPS' both reduce to 5521, and a comparison against the same vendor and the same amount produces a high similarity score."
These are the duplicates that pass exact-match detection and require fuzzy matching to catch. And they are the ones that most AP environments are not set up to identify.
APQC's 2024 Open Standards Benchmarking found that top-performing organisations see 0.8% of annual disbursements go out as duplicate or erroneous payments. Median organisations sit at 1.5%. Bottom performers reach 2.0%. On a £200 million payables run, even the median rate is £3 million leaving the business incorrectly.
29% of AP managers identify duplicate payments as a main operational difficulty, according to the Payables Practitioner Network survey. The number reflects how persistent the problem is even in teams that are aware of it.
Understanding where duplicates originate is the starting point for preventing them. The causes are consistent across organisations.
Invoices arrive through email, supplier portals, EDI, paper, and increasingly structured e-invoice formats. When these channels feed into different systems or different inboxes, the same invoice can enter the AP workflow more than once without either entry being aware of the other.
A supplier sends an invoice by email. The AP team does not respond quickly. The supplier follows up with a resubmission through the portal. Both versions enter the queue and both get processed. The invoice reference numbers differ slightly because the portal generated a new one. Exact-match detection does not catch it.
When invoice data is entered manually into the ERP, keying errors create invoices that look different from the original even when they represent the same payment obligation. An invoice number entered as "INV-2024-0345" might be re-entered as "2024345" in a follow-up. Both proceed through the approval workflow independently because no match is found.
Finance teams spending 12 to 15 hours weekly on manual invoice entry are creating the conditions for this class of error continuously. Volume and time pressure are the two factors that most reliably increase manual entry error rates.
Suppliers resubmit invoices for legitimate reasons: the original was lost, payment was delayed, or the supplier's own system generated a new invoice number for a follow-up. The original and the resubmission represent the same transaction but arrive as different documents. Without systematic comparison across the full invoice history, both can progress to payment.
Businesses with multiple entities, departments, or locations may process invoices through different workflows that do not share a centralised duplicate check. An invoice from a supplier who works across two sites of the same group can be submitted to each site's AP function and processed independently by both.
This is particularly common in multi-location retail and hospitality operations, where site-level AP processing creates duplication risk that centralised detection could prevent.
Manual duplicate detection relies on an AP team member checking each incoming invoice against existing records. At low volumes, this is feasible. At any meaningful scale, it is not.
The structural problem is that manual review checks what an individual remembers or can find in the time available. It does not systematically compare every incoming invoice against every processed invoice over the past 12 months, across every data field, within tolerance bands that account for normalised variations in reference numbers and amounts.
Deloitte's AP Controls Benchmark 2025 research quantifies the gap directly: AI-powered duplicate detection catches 98% of duplicates before payment, compared to 63% for manual review processes. That 35-percentage-point gap represents the duplicates that pass manual scrutiny and result in incorrect payments.
The gap is not a reflection of the quality of the AP team. It reflects what is structurally possible when a person is comparing documents rather than a system running fuzzy matching across a full transaction history. The most diligent AP professional cannot replicate what a correctly configured detection system does continuously and automatically.
Effective duplicate payment prevention requires a layered approach. No single control catches everything. Each layer catches what the others miss.
The first control is upstream of detection: consolidate all invoice submission channels into a single intake point. When email, portal, EDI, and paper all feed into the same centralised intake system, the duplicate check applies to all incoming invoices regardless of channel. A supplier who submits through two channels generates one entry point into the system, not two independent ones.
A vendor master with duplicate supplier records is a structural precondition for duplicate payments. If the same supplier appears as "Acme Supplies Ltd" and "Acme Ltd" in different parts of the system, invoices from that supplier can be processed against different records without triggering a match.
Regular vendor master deduplication, including comparison across name variations, bank account numbers, and VAT registration numbers, removes the structural conditions that make certain duplicates invisible to the detection layer.
Exact-match duplicate detection catches invoices with identical reference numbers. Fuzzy matching catches the variations that suppliers and manual entry generate: different prefixes, transposed digits, normalised amounts within tolerance bands, and date ranges that account for resubmission timing.
Modern AP automation platforms reduce duplicate payment risk by 95 to 99% compared to manual processing through exactly this combination: fuzzy matching across multiple fields simultaneously, applied to every incoming invoice before it enters the approval workflow.
For purchase-order-based businesses, requiring that every invoice reference a valid, open purchase order eliminates one of the most common conditions for duplicate payments. An invoice submitted without a PO reference cannot be matched against an order, which forces it into a verification workflow that checks its legitimacy before approval.
This does not prevent all duplicates, and it is not applicable to every business or invoice type. But for organisations with disciplined procurement, it removes a significant category of duplicate payment risk at the earliest stage of the AP workflow.
Only 17% of organisations currently use AI to help combat payments fraud, according to AFP's 2026 Payments Fraud and Control Survey, despite 76% having experienced attempted or actual fraud in 2025. The gap reflects how recent the availability of AI-powered detection tools is, and how much opportunity remains to close it.
AI duplicate detection operates differently from rule-based systems in two important ways.
It learns from the transaction history. Rather than applying fixed rules to each incoming invoice in isolation, an AI system builds a model of normal invoicing patterns for each supplier: typical amounts, reference number formats, submission timing, and payment cycles. An invoice that deviates from that baseline in multiple dimensions simultaneously is flagged, even if it does not match any previously processed invoice exactly.
It normalises before comparing. Before any comparison is made, the AI system normalises the data: invoice references are stripped of formatting, supplier names are standardised against the master record, amounts are compared within tolerance bands, and dates are assessed within a window that accounts for resubmission timing. The comparison that follows is between normalised records, not raw data fields. The result is that "INV-5521" and "5521/OPS" are correctly identified as probable duplicates rather than as distinct invoices.
The output is a confidence score on every potential match. High-confidence matches, where multiple normalised fields align within tolerance, are flagged for automatic hold. Lower-confidence flags, where only partial matches exist, are surfaced for human review with the relevant context already assembled.
Dost's AP automation platform includes duplicate detection as a standard component of the processing workflow, not as an optional add-on.
Every incoming invoice is compared against the full invoice history before it enters the approval queue. The comparison uses fuzzy matching across supplier identity, invoice reference, amount within tolerance, and date range. Near-duplicates that pass exact-match rules are identified and flagged before any human action is required.
The intelligent data extraction that reads incoming invoices normalises the data at the point of capture. Reference numbers are standardised, supplier names are matched against the vendor master, and amounts are extracted at line-item level for comparison against both the purchase order and the historical record.
When a probable duplicate is identified, it is held automatically and surfaced to the AP team with the original invoice, the incoming invoice, the specific fields where the match is strong, and the confidence score. The team has everything needed to make a decision without conducting their own investigation from scratch.
The approval workflow enforces segregation of duties that prevents the same person from creating a vendor and approving their invoices, which closes the organisational gap that intentional duplicate submission schemes typically exploit.
And because Dost integrates in real time with the ERP, the payment confirmation that closes an invoice in Dost simultaneously updates the ledger in Business Central, SAP, Sage, or Oracle. There is no window between approval and ERP update in which a second payment could be initiated against the same invoice without detection.
Book a demo to see how Dost's duplicate detection works across your AP workflow.
The most consistent root cause is multiple invoice submission channels feeding into a workflow that does not have centralised duplicate detection across all of them. A supplier submits an invoice by email and then resubmits through the portal when payment is delayed. Both versions enter the system through different paths, generate slightly different reference numbers in the process, and both proceed through approval independently. The second most common cause is manual data entry error, where the same invoice is entered twice under slightly different references. Both are preventable with centralised intake and fuzzy matching detection.
Duplicate payments are typically the result of process failures: a supplier resubmission that was not caught, a data entry error, or a multi-channel submission that was not detected. They are usually honest mistakes, by either the supplier or the AP team. Invoice fraud involving duplicates is deliberate: a fraudster submits the same invoice twice, with minor variations in reference or amount, intending for both to be paid. The detection controls that prevent honest duplicates also catch the deliberate ones, because the pattern they look for is the same: two invoices from the same supplier for similar amounts with similar references within a defined time window. The difference is intent, not the control required to stop it.
Most ERP systems, including Business Central, SAP, and Sage, have basic duplicate invoice detection based on exact matching of invoice reference numbers. This catches the most obvious duplicates but misses the fuzzy variations that are most common in practice: different prefixes on the same invoice number, slight amount differences, or the same transaction submitted under different document types. A dedicated AP automation platform with fuzzy matching and a full transaction history provides meaningfully more robust detection than what most ERPs offer natively.
Duplicate payments are among the most consistently preventable losses in accounts payable. They are not the result of sophisticated attacks or complex system failures. They are the result of predictable process gaps: multiple invoice submission channels without centralised detection, exact-match rules that miss normalised variations, and manual review that cannot compare at scale.
The financial exposure is real. Between 0.8% and 1.5% of disbursements go out as duplicates in the median organisation. On any meaningful payables run, that is a material amount of cash that leaves without a corresponding obligation.
The prevention is equally real. AI-powered fuzzy matching that compares every invoice against the full transaction history catches 98% of duplicates before payment, compared to 63% for manual review. The gap between those two figures is the business case for moving from human-dependent detection to systematic automation.
See how Dost's duplicate detection works across your AP process.
.png)
.png)
