A duplicate invoice is a second billing document for a charge already recorded or paid. It rarely looks like a copy, which is why exact-match rules on vendor, invoice number, and amount often approve it. Detection depends not on a cleverly written rule, but on how much history the matching system holds and how much variation it tolerates.
A duplicate invoice almost never looks like a copy. It looks like a slightly different document for the same money, which is why the rule you already apply leads to an approval. Here is how each duplicate gets in, and what actually catches them.
Start with the honest version, because most duplicate payments are process failures rather than fraud. Suppliers send the same document more than once, invoices arrive through more than one channel, and people re-key what a system already holds. Nothing in that sequence requires bad intent, and all of it produces a duplicate invoice in the ledger.
Volume makes it worse in a specific way. When an accounts payable (AP) team handles email, a supplier portal, electronic data interchange (EDI) feeds, and PDF attachments in parallel, no single queue shows the whole picture. Duplicate invoice payments across multiple submission channels are one of the pain points AP teams rank highest, and the reason is structural.
Then there is the version that is not accidental. The Association of Certified Fraud Examiners studied 2,402 occupational fraud cases for its Report to the Nations 2026, reporting a median loss of $104,000 per case. The median case lasted 12 months before discovery. Schemes caught within six months cost a median of $40,000, and schemes that lasted more than five years cost a median of $1.1 million.
That duration figure is the argument for treating duplicate detection as a continuous check rather than a periodic recovery audit. A vendor who resubmits one modest invoice every quarter and gets paid twice matches the profile ACFE describes. Each payment looks defensible on its own. Only the sequence gives it away, and the sequence is invisible to a control that reads one invoice at a time. Recovery audits do find this money, months or years later, at a fee. Catching it before payment keeps the money in the business.
A duplicate is a matching problem, and matching problems are governed by what the matcher remembers and how much variation it tolerates.
Keep more history rather than writing cleverer rules. A duplicate needs a prior record to match against. A system with 30 days of history finds the resubmissions that arrive quickly and none that arrive next quarter. On the expense side, our own duplicate expense detection work shows duplicates found growing about 700 percent from month one to month twelve of an audit program. The rules did not improve during that year. The history did.
Tolerance works as a dial rather than a switch. Exact matching produces few false positives and misses most duplicates. Loose fuzzy matching finds nearly everything and buries the team in false hits on legitimate recurring charges. The useful setting is between those, with confidence scoring rather than a binary flag.
Recurring charges are the hard case. A monthly rent, a fixed retainer, or a subscription produces identical vendor, identical amount, and near-identical description every period. Any rule tuned to catch same-vendor-same-amount will flag all of them forever unless it accounts for periodicity.
Timing changes the cost. Catching a duplicate before payment is a queue item. Catching it after payment is a vendor conversation, a credit note, and a reconciliation entry. The same detection logic is worth far more upstream.
One supplier emails the invoice to a named AP contact, uploads it to the portal, and attaches it again to a statement. That is three arrivals, three intake paths, and often three different reference numbers assigned on entry. This is the most common source in fragmented, multi-inbox operations with no shared audit trail.
Channel de-duplication has to happen before the document reaches the enterprise resource planning (ERP) system, because once each copy holds its own document number the ERP sees two distinct records.
A supplier waits past terms, assumes the invoice was lost, and sends it again. Sometimes they generate a fresh invoice number for the resend, and sometimes they add a late fee that defeats an amount-based match. Payment status inquiries and resubmissions rise together, which is why slow AP response times produce duplicates as a side effect.
The tell is a second document from the same vendor for the same goods or services, with a date gap matching your payment cycle.
The same invoice number reaches the ledger as INV-0045, INV0045, inv 45, and 0045. Leading zeros drop, prefixes get stripped on entry, hyphens vary, and optical character recognition misreads a character. Each variant is a different string, so an exact-match rule on invoice number treats them as four separate invoices.
Normalization is unglamorous and it does more work than any other single fix here. Strip non-alphanumeric characters, remove leading zeros, fold case, and match on the normalized form as well as the raw one.
An invoice arrives against a purchase order (PO) and clears three-way matching. A second copy arrives without a PO reference, routes to the non-PO-backed queue, gets coded to a general ledger account, and clears a manager approval. The two are never compared, because they were never in the same queue.
Non-PO-backed invoices deserve the heavier scrutiny for exactly this reason, and they usually get the lighter one.
A credit memo is issued against an invoice, then the corrected invoice arrives with a new number. If the credit is not applied, or is applied against the wrong document, the ledger holds two payables and one credit that nobody matched. The reverse also happens, where a credit is taken twice against the same original.
Watch for a credit and a replacement invoice from one vendor in a short window, with amounts that reconcile only when read as a set.
An employee pays a supplier with a corporate card or personally, submits it on an expense report, and the supplier separately invoices the company for the same service. Hotel deposits, conference registrations, catering, and courier charges are the usual candidates. Neither the AP system nor the expense system sees the other, so both pay.
This one is genuinely cross-system, and it is the reason the travel and expense (T&E) side deserves its own treatment. For the employee-side version, see our companion piece on duplicate expense claims. GBTA research from 2015 found that 19 percent of expense reports contain errors or missing information. Correcting one costs $52 and takes 18 minutes. That research is old, and it is still the most-cited figure in this area.
The standard control checks vendor, invoice number, and amount for an exact triple match. It fails on every scenario above except the laziest one.
The invoice number check fails on formatting variance and on vendors who renumber a resend. The amount check fails on late fees, partial payments, tax recalculation, and rounding. The vendor check fails hardest, because the vendor master usually holds one supplier several times over. Different legal entity names, different remit-to addresses, and records created years apart all split a single supplier into several identities. The matcher then compares across a boundary it does not know exists.
Fuzzy matching adds tolerance on each field and a confidence score across the set. Normalized invoice numbers, edit-distance comparison on vendor names, amount bands, and date-proximity windows all contribute to the score. Scoring matters more than any single signal, because a strong match on two fields with a near miss on the third is the shape of a real duplicate.
Image-level and content-level matching adds what field comparison structurally cannot see. Comparing the document itself catches the re-issued or re-scanned invoice whose extracted fields have all changed. Line-item comparison catches the partial duplicate, where three of five lines already appeared on a prior invoice. Header matching approves that one every time.
State the limit honestly. None of this catches a genuinely distinct invoice for work that was never delivered. That is a billing scheme rather than a duplicate, and it needs contract and receipt evidence rather than better matching.
Our platform treats history as the primary asset. Every new document is compared against what came before it, across channels and across reporting periods, which is what makes the slow-arriving duplicates visible at all. Autonomous AP applies matching at the line level rather than at the header, including on non-PO-backed invoices, so partial duplicates and re-issued documents surface before payment. AP Inbox Service Center gives the intake side a single owner and an audit trail, which removes the multi-channel arrival problem at its source rather than reconciling it afterwards.
AI Agents clear the routine exceptions. The trickier exceptions that cannot be reconciled are sent to a human. See how prepayment invoice processing coverage changes detection rates, or how our agentic AP software works alongside your existing systems.
Before buying anything, normalize your invoice numbers and deduplicate your vendor master, because those two fixes make every match you already run more accurate. Then extend the lookback window, because a duplicate invoice only becomes findable once you hold the record it duplicates. Ask us what a full pre-payment review would surface across your accounts payable history.
A duplicate invoice is a second billing document for a charge already recorded or paid. It takes three forms, an identical resubmission, a re-issued invoice with a new number, or a new invoice repeating line items from an earlier one.
Most come from ordinary process gaps. Suppliers resend after a payment delay, the same document arrives through email and a portal, and invoice numbers are formatted differently on entry. Credit memos go unapplied, the PO and non-PO queues are never compared, and some charges appear on both an invoice and an employee expense report.
It requires vendor, invoice number, and amount to match exactly. Late fees and tax recalculation change the amount, resends change the number, and formatting changes the string. Duplicate vendor master records also split one supplier across two identities, so the comparison never happens.
Fuzzy matching normalizes invoice numbers, compares vendor names by similarity, allows amount and date ranges, and returns a confidence score instead of a yes or no. Image-level and line-level comparison then catch re-issued documents and partial duplicates that field matching approves.
Usually it is not. Most are process failures on the supplier or intake side. A pattern of repeated resubmissions from one vendor that consistently gets paid twice is different. It fits the long-running profile ACFE described for 2026, where the median scheme lasted 12 months before discovery.