Detect duplicate invoices with business keys and review

File hash. The same invoice can arrive as a PDF, scan and photograph. The files differ while representing one transaction. A file hash detects identical bytes, making it a useful first filter for exact repeats. It does not reliably identify a newly scanned copy of the same invoice.

Invoice number. Invoice number alone is also insufficient. Different suppliers can use identical numbers, numbering schemes can change and records belonging to separate companies must not be merged. Matching needs business context.

ERP practice. ERP systems reflect this distinction. SAP's duplicate-invoice documentation identifies fields such as supplier, company code, reference, date and amount as relevant checks or configurable criteria. SAP Duplicate Invoice Check, checked on 26 September 2026. Actual behaviour depends on the product and configuration and needs testing in your environment.

Duplicate-invoice detection works in five layers, each with its own comparison and intended outcome:

Original and normalised values. Retain original values alongside normalised comparison values. Whitespace and case can be standardised for search, but do not remove leading zeroes or meaningful number components indiscriminately. Aggressive normalisation can make genuinely different invoices appear identical.

Explain every warning. Every warning should explain what matches and what differs. “AI says duplicate” is not enough for accounting to decide. Show both originals, the compared fields and existing processing state together.

Search scope. Consider how far back the comparison should search. Restricting it to today's inbox can miss a repeated invoice already processed last month. Conversely, an unrestricted number-only match across years and suppliers will create unnecessary warnings. Agree the search scope with accounting.

Repeated, corrected and recurring invoices and credit notes each need different handling:

• Repeated submission: someone forwards the same invoice because they did not know it had already arrived. Connect the new intake event to the existing case, preserve provenance and avoid preparing another payment.
• Corrected invoice: the reference is unchanged but the amount or lines differ. This needs business review. Do not overwrite the earlier version silently. Record which version applies and how any processing already performed must be corrected.
• Recurring service: monthly invoices from one supplier can have the same amount. Without service period or an appropriate reference, blocking solely on supplier and amount is too broad. Similarity should initially create a review task.
• Credit note: Credit notes also need separate handling. Referring to an earlier invoice number does not make a credit note a duplicate of the original invoice. The sign of an amount does not fully establish the business meaning either.

A company receives supplier A's invoice R-2026-081 for EUR 1,200. Two days later the same invoice arrives as a scan. Supplier B then submits its own R-2026-081 for EUR 900, followed by A sending a corrected version for EUR 1,150. This invented example is intended for rule testing.

The four incoming documents of this invented example lead to four different actions:

The first invoice creates the case. The scan has a different hash, but its business key matches. Amount and currency support the match, so the additional submission can be connected to the existing case. Supplier B's document is a separate transaction because its supplier identity differs.

The corrected version from A is neither discarded nor accepted automatically. Matching identifiers with a changed amount create a hold. The owner checks whether the original was posted or paid and determines the accounting correction required. The document history remains available.

Include all four cases in acceptance. Testing only two identical PDFs proves the easiest part while leaving the important business decisions unresolved.

Why retries create duplicates. A workflow can submit an invoice twice even when it arrived only once. A timeout after destination creation is a typical cause. Document checking therefore needs a stable case identifier and deliberate retry behaviour alongside it.

Submission state and destination identifier. Store submission state and the acknowledged destination identifier. When a response is missing, first establish whether the transaction already exists. Repeating a request must not automatically mean creating a new record. Also test concurrent intake: two simultaneous runs must not both decide that no record exists using stale information.

Depends on the interface. The implementation depends on the actual interface. Ask the provider to explain uniqueness, repeated delivery and destination reconciliation. OCR capability alone does not solve this operational problem.

Test an interruption. Include a deliberate interruption in testing. The operator should be able to identify the uncertain case, inspect the destination and resume without losing the original or creating another invoice. A process that requires deleting records blindly is not ready for unattended operation.

Measures. Track true duplicates found, duplicates missed and legitimate invoices incorrectly held separately. A high number of warnings may simply indicate overly broad rules. Add review time and the age of unresolved holds.

Review screen. The review screen needs an owner, clear decisions and a recorded reason: connected to existing case, independent transaction, corrected version or unresolved. A decision to release a suspected duplicate should remain explainable. Do not delete documents automatically because a rule found similarity.

Where to start. Start with the most common intake channels and include records awaiting approval as well as already posted invoices. The goal is an understandable defence against repeated processing that still allows legitimate invoices to proceed and preserves the history of corrections.

These guides and service pages cover the decisions next to duplicate-invoice detection:

• AI document processing: capture, review and transfer
• Automate invoice capture without hiding field errors
• Match purchase orders, delivery notes and invoices
• n8n retries without duplicate business actions

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.