How the same vendor invoice reaches you twice
A vendor sends an invoice. Six weeks later, the same invoice arrives again.
Nobody did anything wrong. Their bookkeeper re-sent an open item. Or the rep attached it to a chase email. Or it came once by post and once by attachment.
The document is the same. The file is not. That gap is the whole problem, and it is where most duplicate checking quietly fails.
Why checking the file misses it
The obvious defence is to fingerprint the file. Hash the bytes on arrival, keep the hashes, and refuse anything you have seen before.
That works, and it is worth doing. It catches the genuinely identical file — the same attachment forwarded twice, the same PDF uploaded after being emailed.
But it only catches the identical file. Change one byte and the fingerprint changes completely. That is the property that makes hashing useful, and here it is also the limitation.
Any of these produce a different file from the same invoice:
- The vendor re-exports it from their accounting system on a different day.
- Someone scans a paper copy rather than attaching the original.
- A mail gateway flattens or re-compresses the attachment.
- The vendor adds a line to the footer, or a new logo.
None of those change what you owe. All of them defeat a byte check completely.
What actually identifies the document
The document already carries its own identity. Your vendor printed it on the page: the invoice number.
So the check that survives a re-scan works on what the document says, not on how it arrived. Read the invoice number, and compare it to every invoice number you have read before.
With one correction, which matters more than it sounds.
An invoice number is only unique within one vendor
Invoice numbers are assigned by the vendor, from the vendor's own sequence. Two vendors will both eventually issue an invoice numbered 1042.
Match on the number alone and you block the second one. A real bill from a real vendor gets refused, because an unrelated company used the same counter.
That failure is worse than the one it prevents. A missed duplicate is caught at reconciliation. A blocked legitimate invoice is a vendor calling about a late payment.
So the pair is what identifies a document: this vendor, and this document number. Both, or neither.
How this works here
Both checks run, because they catch different things.
Every document is fingerprinted on arrival. The same bytes never produce a second set of rows, however they got here — uploaded, or emailed.
Then a separate check compares the vendor and the document number against what you have already had. That one catches the re-scan and the re-export.
It is one of the checks every line passes before a number is released to you. Not a setting to switch on, and not something to configure per vendor.
This check blocks. It stops the document rather than flagging it, because a duplicate that reaches your spreadsheet has already done its damage. Some checks warn instead — that choice is made per check, and deliberately.
What this does not do
It will not catch a vendor who re-issues the same charge under a genuinely new invoice number. That is not a duplicate document. It is a billing dispute, and no amount of reading the PDF settles it.
It also has nothing to compare against on the very first document from a new vendor. With no history, the check says so rather than reporting a pass it did not earn.
See it on one of your own
Take a vendor invoice off your desk and drop it in here. Every line comes back, with every check shown. Nothing is stored and there is no sign-up.