Finance Index
How does duplicate invoice detection work - and how do duplicate payments happen?
Reference guide to duplicate invoice detection, including invoice workflow, coding, approvals, ERP impact, and AP controls.
Duplicates happen through innocent mechanics: a vendor re-sends an unpaid invoice, the same bill arrives by email and mail, two entities both receive a copy, or a resend carries a tweaked invoice number. Detection works by comparing each incoming invoice against history on multiple fields - vendor, invoice number, amount, date - with exact matching catching identical resubmissions and fuzzy matching catching the near-misses (INV-001 vs INV-001A, same amount, same week) that exact rules wave through.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Duplicate invoice detection work | Duplicates happen through innocent mechanics: a vendor re-sends an unpaid invoice, the same bill arrives by email and mail, two entities both receive a copy, or a resend carries a tweaked invoice number. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Vendor impact | Yes - this is the case that separates real detection from an ERP uniqueness constraint. | Keeps vendor records and payment decisions reliable. |
| Prevent duplicates when the same | Channel-independent detection: every intake path must feed one duplicate-checked queue, with checks comparing against all invoices regardless of how they arrived. | Helps finance decide what to do next. |
| Payment impact | Industry recovery-audit studies consistently find duplicate and erroneous payments in the range of a few tenths of a percent up to ~2% of AP spend - small percentages that compound into real money at volume. | Keeps evidence clear and reduces control risk. |
| Related terms | Both, deliberately: intake checks catch duplicates when resolution is trivial (delete the copy); payment-run checks are the last gate before money moves and catch anything that entered through a side door. | Keeps evidence clear and reduces control risk. |
Vendor slightly changes the invoice number on a resend and it slips through - can detection catch near-duplicates?
Yes - this is the case that separates real detection from an ERP uniqueness constraint. Fuzzy detection scores similarity across fields jointly: a 95%-similar invoice number with identical vendor, amount, and date is almost certainly the same bill, while a similar number with different amounts may be legitimate sequential billing. Near-duplicate hits should flag for human review rather than hard-block, because the reviewer needs to distinguish resend, revision, and genuine new invoice - but the flag has to fire at intake, while the decision is cheap.
How do I prevent duplicates when the same invoice arrives by email and mail and through a portal?
Channel-independent detection: every intake path must feed one duplicate-checked queue, with checks comparing against all invoices regardless of how they arrived. If your portal feed and your email capture maintain separate histories, each channel is blind to the other - the most common multi-channel duplicate hole. Pair it with one declared channel of record per vendor, so the second copy is expected noise rather than a surprise.
What percent of invoices are duplicates, and how much do duplicate payments cost companies per year?
Industry recovery-audit studies consistently find duplicate and erroneous payments in the range of a few tenths of a percent up to ~2% of AP spend - small percentages that compound into real money at volume. The cost is asymmetric: detection at intake costs seconds; recovery after payment costs weeks and sometimes the cash.
What duplicate-check controls should exist at intake vs at payment run?
Both, deliberately: intake checks catch duplicates when resolution is trivial (delete the copy); payment-run checks are the last gate before money moves and catch anything that entered through a side door. A single check anywhere is a single point of failure.
My ERP only checks exact invoice number per vendor - what duplicate scenarios does that miss?
The big four: altered invoice numbers on resends, the same invoice under two vendor records, cross-entity duplicates where each entity's ERP instance sees only its own history, and duplicates entered before posting (the ERP can't check what hasn't reached it). ERP uniqueness constraints are a backstop, not a detection system.
Should AP run a periodic duplicate payment audit, and how do recovery audit firms find duplicates we missed?
Yes - even with good intake controls, run a periodic self-audit using fuzzy matching across vendor, amount, and date windows. Recovery firms find misses with exactly those techniques (plus vendor-master dedup and statement reviews) and typically charge contingency; a self-audit first keeps that fee for findings you could have caught yourself.
Same vendor exists twice in our vendor master under slightly different names, and duplicates slip between them - how do I catch cross-record duplicates?
Fix the master: merge duplicate vendor records and add match-key controls (TIN, bank account, normalized name) at vendor creation. Detection that includes vendor-similarity scoring helps in the meantime, but duplicate vendors break more than duplicate checks - they fragment spend history, 1099s, and payment terms too.
Stampli perspective
Stampli applies duplicate detection in layers across the invoice lifecycle - checks can run at upload, review, dispatch, release, and export - so a duplicate caught at intake never reaches a payment run, and one that enters later still hits downstream gates. Stampli AI flags duplicates proactively along with related risk signals (first-time vendors, unusual documents, unusually high amounts), and the flag, the reviewer's decision, and the resolution are all documented on the invoice record - turning duplicate control from memory and luck into an auditable workflow.