Duplicate invoices: What are they and how to prevent them
Senior Manager Content Marketing at Medius
- Introduction
- What are duplicate invoices?
- Why duplicate invoices happen
- How do you detect a duplicate invoice before it is paid?
- Where duplicate detection breaks down
- AI-driven matching and what it changes
- What duplicate invoices actually cost
- Resolving a duplicate that has already been paid
- Building controls around detection
- Ready to prevent duplicate invoices with Medius?
- Frequently asked questions
Hear what's covered in this article:
Duplicate invoices are prevented by normalizing invoice and supplier data before comparison, checking each incoming invoice against history on several fields rather than the invoice number alone, and routing every intake channel into a single queue so there is one record to check against. Exact matching catches only identical resends. Most duplicates that reach payment differ from the original by a character, a date, or a vendor record.
What are duplicate invoices?
Duplicate invoices, also known in the industry as double invoices, occur when the same bill is processed more than once. They take three main forms: an identical invoice submitted twice, the same invoice altered slightly before resubmission, or one invoice arriving through two channels. The second and third forms are the ones that reach payment, because the first is what most systems are already configured to catch.
Why duplicate invoices happen
Most duplicate invoices are not deliberate. They come from an invoice emailed and then mailed in paper form, a supplier resubmitting because payment was slower than expected, data entry error, or the same bill entering through two systems after a merger or migration. They also come from the supplier record rather than the invoice: when one company exists twice in the vendor master under slightly different names, two copies of the same bill look like invoices from two suppliers. Poor supplier data is a cause of duplicate payments in its own right.
A smaller share are deliberate. A supplier may resubmit with the date or invoice number altered, counting on a system that matches on exact values. Internal fraud works the same way, with an employee processing the second copy for personal gain. Both rely on the same weakness, which is a check that compares invoice numbers and stops there. Duplicate submission is one of the recognized AP fraud types.
How do you detect a duplicate invoice before it is paid?
Detection is a comparison problem, and the comparison is only as good as the data going into it. Before any matching rule runs, incoming invoices have to be normalized: separators and leading zeros stripped from invoice numbers, case ignored, and every variant of a supplier name mapped to one vendor record. Without that step, INV-0921 and inv921 are two different invoices, and so are two spellings of the same company.
Once the data is consistent, matching runs against invoice history on a set of fields rather than one:
Vendor ID: not vendor name, since names vary and IDs do not
Invoice number: after normalization
Invoice date: usually within a tolerance window rather than an exact match
Amount: the field fraudsters are least willing to change
PO number: matters most when a supplier reuses invoice numbers across periods
Exact matching requires vendor, invoice number, and amount to be identical to something already in the system. That catches a straight resend and nothing else. A single changed character, a trailing space, or a date moved by two days defeats it, which is why exact matching alone leaves most of the real risk in place.
Fuzzy matching closes that gap by flagging the same vendor and amount paired with a similar invoice number or a nearby date. It produces false positives, and that is the tradeoff to manage rather than eliminate. A rule tight enough to never flag a legitimate recurring invoice will also miss near-duplicates. The practical way to set it is to run a candidate rule against the last year of invoices and count both results: how many known duplicates it catches, and how many clean invoices it stops. Matching the invoice against the purchase order and goods receipt is a separate check that answers a different question, which is whether the invoice should be paid at all.
None of this works if invoices arrive through channels that do not share a history. Email, supplier portal, EDI, uploads, and scanned mail all have to write into one queue. A duplicate that arrives through a channel outside that history is invisible to every rule above, no matter how well tuned. The specific capabilities to look for when evaluating software follow from that requirement.
Where duplicate detection breaks down
Teams that have detection configured still pay duplicates, and the reasons are consistent:
Split vendor records: The same supplier exists twice in the vendor master, so two copies of one bill compare as invoices from two different companies. No matching rule recovers from this, because the vendor key is wrong before the comparison starts.
Off-cycle payments: A rush check or manual payment made outside the AP system leaves no history to match against. The invoice looks new because, as far as the system knows, it is.
Migration gaps: After an ERP change or an acquisition, history that was not carried into the new system is invisible. Duplicates spanning the boundary pass cleanly.
Checks that run too late: A duplicate check that fires after approval rather than before it does not prevent anything. It converts the problem into a recovery exercise, which succeeds less often and costs more.
Replacement invoices: A supplier reissues an invoice with a late fee added or a discount applied, under a new total. Matching rules do not resolve this, because the second invoice is genuinely different from the first. Only a human or a policy decides whether it replaces the original or sits alongside it.
The first three are data problems wearing a detection costume. They get fixed upstream, in the vendor master and the intake process, not by tightening a matching rule.
AI-driven matching and what it changes
Rule-based matching asks whether fields are equal. Model-based matching asks how similar two invoices are across many fields at once, including ones a rule would not consider: line item descriptions, payment terms, delivery address, contact details, and the supplier’s own history of submissions. The output is a similarity score rather than a yes or no.
That changes the workflow more than it changes the catch rate. Scores get banded, so the clearest matches are held automatically, a middle band routes to a reviewer, and low scores pass through. The value is in the middle band, where a rule would have had to either flag everything or nothing. It also means the system can explain which fields drove the score, which is what lets a reviewer make a decision rather than just clear a queue.
Pattern recognition adds a second layer: suppliers with a history of duplicate submissions, invoice numbering that varies in ways that look deliberate, and timing that clusters around payment runs. None of this removes the need for clean supplier data. A model comparing two vendor records it believes are two companies reaches the same wrong answer a rule does, faster. The underlying capability set is worth understanding before evaluating any of it.
What duplicate invoices actually cost
A duplicate that reaches payment costs more than the duplicated amount. It has to be identified, confirmed with the supplier, and recovered, which takes longer and succeeds less often than preventing it would have. In the meantime the payment has distorted cash position, the accrual, and the supplier’s account balance, and the reconciliation work to unpick it lands on the same team that missed it. Strained vendor relationships and potential harm to the company’s reputation follow from the same event.
The second cost is signal. A duplicate that reaches payment means a check that should have been routine did not happen, and auditors read it exactly that way. Frequent duplicates raise questions about what else is passing through unexamined, which is a more expensive conversation than the invoice.
Resolving a duplicate that has already been paid
When an AP team identifies a potential duplicate, the first action is to verify its authenticity by comparing it against existing records, such as purchase orders and previously paid invoices. Check the supplier record at the same time. A flagged pair that turns out to involve two vendor IDs for one company is a master data fix, not just an invoice decision, and leaving it unfixed guarantees the next one.
If it is confirmed as a duplicate and payment has not gone out, the invoice is rejected and the supplier notified, with the reason documented so the pattern is visible if it recurs. If payment has gone out, recovery means a refund or a credit applied against future invoices, and which one is appropriate usually depends on whether the relationship is ongoing. Record which it was. Recovery outcomes are the only way to know whether detection is actually improving.
Building controls around detection
Detection is one layer. The controls around it decide whether a flag becomes a prevented payment: who can approve an exception, whether the person entering an invoice can also release payment, and what happens to invoices that fall outside the standard workflow. Those controls are worth building deliberately, because detection tuned perfectly inside a weak approval process still ends in a paid duplicate.
Ready to prevent duplicate invoices with Medius?
Medius combines invoice automation, comprehensive AP automation, and fraud and risk detection so duplicates are caught at intake rather than found in reconciliation. Book a demo to see how matching, supplier data validation, and exception handling work together on your own invoice volume.
Frequently asked questions
A duplicate invoice is the same bill processed more than once. It can be an identical resubmission, the same invoice altered slightly before being sent again, or one invoice that arrives through two channels such as email and a supplier portal.
By normalizing invoice numbers and supplier names first, then comparing each incoming invoice against history on vendor ID, invoice number, date, amount, and PO number together rather than any one field. Exact matching alone catches only identical resends.
Usually because it matches on exact values within a single system. A changed character, a shifted date, a supplier that exists twice in the vendor master, a payment made outside the system, or history lost in a migration will all defeat an exact-match check.
Fuzzy matching flags invoices that are similar rather than identical, typically the same vendor and amount paired with a near-identical invoice number or a nearby date. It catches near-duplicates that exact matching misses, at the cost of some false positives.
Most are not. The majority come from process and data errors such as multi-channel submission, resubmission, or duplicate vendor records. A smaller share are deliberate, usually a resubmission with the date or invoice number altered to defeat an exact-match check.
