Why Duplicate Invoices Are the Most Common AP Error

Ask anyone who has run an accounts-payable function what actually loses money, and duplicate payments will be near the top. Not fraud. Not price disputes. The same bill, paid twice.

It is worth understanding why it is so persistent, because the reasons explain why a single check never solves it.

How the same bill arrives twice

The vendor chases. An invoice is sent, nothing is paid within terms, and the vendor’s system re-sends it. Now you hold two copies, and if the first was mislaid rather than paid, only one of them is “the” invoice.

Two routes into the building. One copy is emailed to accounts payable, another is handed to the person who ordered the goods, who forwards it. Two people, two entries, one bill.

A statement is treated as an invoice. A monthly statement lists invoices already received. Somebody enters a line from it as a fresh document.

A corrected re-issue. The vendor notices an error and sends a corrected version — often under the same invoice number.

A re-scan. The same physical document goes through the process twice, days apart, and the second scan produces a slightly different file: a different resolution, a different scanner, a stamp added by hand.

A number series change. The vendor changes their invoice numbering. The same bill appears under a number that looks entirely new.

None of these require anyone to be careless. They are the normal consequence of documents moving through more than one channel.

Why one check never covers it

Each obvious check catches a different subset, and misses the rest.

Match on file content. Catches an exact re-send. Misses a re-scan, a re-issue, and anything that arrived by a different route with a different covering page. Two files that a human would call identical differ in a single byte and the check sees nothing.

Match on vendor plus invoice number. Catches most genuine repeats. Misses the number-series case entirely, and — importantly — over-matches on corrected re-issues, which carry the same number deliberately.

Match against already-posted invoices. Catches the case where the first copy was processed weeks ago and has left the queue. This one is easy to omit, because it requires looking outside the tool’s own records into the ledger.

Match on vendor, amount and nearby date. Catches the number-series case, and the statement-line case. Also produces false positives — a vendor who bills the same round amount every week will trip it constantly.

The right structure is several checks with different outcomes, not one check with one outcome. Strong signals supersede automatically. Weak signals produce a warning and a note, and let the document through.

That last part is easy to get wrong. A near-duplicate heuristic that blocks trains people to click past it, which is worse than not having it.

The case that matters most: a corrected re-issue

This is the failure mode worth being explicit about, because getting it wrong is worse than having no duplicate detection at all.

A vendor sends invoice INV-4471. You receive it. They notice an error — wrong quantity, wrong tax, a missing line — and send a corrected INV-4471.

Same vendor. Same invoice number. Different content.

A system that keys on vendor plus invoice number and stops there will mark the corrected version a duplicate and discard it. The wrong version stays live. Nobody is told. The correct copy of a bill somebody has to pay has just been destroyed by a control that was working as designed.

The safe rule is asymmetric:

• Identical bytes → supersede automatically. A true duplicate costs nothing to discard.
• Same number, different bytes → send it to a person, as an exception. It might be a re-issue. It might be something worse.

Superseding a true duplicate costs nothing. Superseding a revision loses the only correct copy. When the two outcomes are that unequal, fail towards the human.

What a superseded document should do

Not vanish. A confirmed duplicate should be marked and kept, linked to the document that survived, and visible to anyone who goes looking for it.

Two reasons. First, the audit trail: “we received this twice and paid once” is a stronger record than silence. Second, and more practically, a correctly detected duplicate that quietly disappears from every queue and tile is indistinguishable from a lost file. Somebody will spend an afternoon looking for it.

The message at the moment of detection — this is a duplicate of the document you received on the 3rd — is worth more than the record afterwards, because it is the only moment anyone is actually looking.

The organisational half

No amount of detection fixes a process where the same invoice legitimately enters through three doors.

If you are getting a lot of genuine duplicates, the cheapest fix is usually upstream: one intake channel, told to vendors, enforced internally. Detection is the safety net. A single front door is the actual solution.