A duplicate attachment, a duplicate invoice record and a duplicate payment are different problems. Good detection preserves the evidence and routes the candidate to finance instead of deleting records or deciding payment automatically.
Look beyond an exact invoice-number match
Oracle documents an optional duplicate-invoice check using a combination of supplier, invoice type, amount, currency and date. That illustrates why invoice number alone is not the only useful signal. It is a configured product feature, not a claim that every account or integration already performs those checks. Read Oracle's duplicate invoice check documentation.
A repeated invoice can arrive through two mailboxes, a portal and email, or a supplier's reminder. It may carry a changed filename or punctuation in its reference. Conversely, two recurring charges can legitimately have the same amount. A candidate match needs context before it becomes a confirmed duplicate.
Use layered checks with different meanings
| Check | Signal | Review limit |
|---|---|---|
| Same file content | A document was received again. | Does not establish whether one invoice record or payment already exists. |
| Same supplier and exact reference | A strong duplicate-record candidate. | Check invoice type, legal entity and whether the document corrects an earlier issue. |
| Normalized reference match | Punctuation or spacing may differ. | Normalization can merge genuinely distinct references. |
| Similar commercial fields | Amount, date, currency and supplier overlap. | Recurring invoices, deposits and credits need interpretation. |
Store the original reference unchanged. Put any uppercase, whitespace or punctuation normalization in a separate comparison field. Preserve leading zeros and document the rule; “INV-4812” and “INV-04812” cannot automatically be assumed equivalent. Supplier identity should come from a reviewed supplier record, not just a display name.
A fictional candidate review
Finance already has supplier S-204's invoice INV-04812 for $1,840 in USD, dated 3 October. A second email includes a file named reminder-final.pdf showing “INV 04812”, the same currency, amount and date. The normalized reference and commercial fields flag it for review.
Similar records need different checks.
- Existing invoice
- S-204, INV-04812, $1,840 USD, 3 October
- Reminder document
- INV 04812, same supplier, currency, amount and date
- Outcome
- Candidate for finance review; preserve both sources
View data
| Evidence | Meaning |
|---|---|
| Existing invoice | S-204, INV-04812, $1,840 USD, 3 October |
| Reminder document | INV 04812, same supplier, currency, amount and date |
| Outcome | Candidate for finance review; preserve both sources |
Fictional worked example from the article. Apply your organization’s controls.
Download imageThe reviewer opens both sources and checks the existing invoice's state. If the second file is the same invoice, record it as additional evidence linked to the existing record. If it is a corrected invoice, establish what changed and follow the organization's replacement or credit process. Do not silently overwrite the original invoice.
A different supplier's $1,840 invoice is not the same candidate. Nor does a new monthly invoice become a duplicate just because its amount matches last month's bill. Invoice type and service period can explain apparent similarity.
Keep the review decision explicit
- Candidate: a rule found a possible match; no final conclusion yet.
- Confirmed duplicate: finance identifies the existing record and records the evidence.
- Distinct invoice: the reviewer explains the difference and permits normal processing.
- Correction needs handling: revised commercial data requires the appropriate finance process.
- Unresolved: missing evidence or identity prevents a reliable decision.
Payment authorization remains with finance and its approved controls. The workflow can create a review hold or task according to policy, but it should not mark a payment cancelled, reverse an entry or email a supplier rejection just because a similarity score is high.
Check retries and simultaneous arrivals
A second detection pass can occur before the first record is saved. Keep a stable intake reference and make the final duplicate check against the current ledger part of the controlled posting process. Retrying an intake should reopen its known record rather than append another candidate with no connection.
Test with repeated files, changed filenames, missing invoice numbers, similar supplier names, credit notes, installment invoices and corrected documents. Track confirmed duplicates, false alerts and unresolved candidates separately. A high alert count is not evidence of prevented losses.
This check complements the three-way matching process. An invoice can match its order and receipt while still repeating an invoice already entered. Use the readiness check to clarify supplier identity, posting ownership and exception handling before automating the queue.