Diagnose the alert before adding AI
If an export already contains a stable supplier ID and invoice number, start with deterministic comparison. AI is not needed to discover that two normalized keys are identical. It becomes useful only when a human-readable explanation or a bounded near-match review is required.
Oracle's current duplicate-invoice documentation describes checks that combine supplier, invoice type, amount, currency, and date instead of relying on the invoice number alone. Microsoft's vendor invoice workflow documentation treats a duplicate number as an alert that a user can correct and resubmit. Neither mechanism turns a matching field into proof of fraud.
Build two different detection lanes
Lane 1: deterministic exact candidates
Construct a key from the fields your accounting policy allows. In the synthetic exercise the exact rule is:
case_normalized_supplier
+ invoice_type
+ currency
+ signed_amount
+ invoice_date
+ punctuation_normalized_invoice_numberThe sign belongs in the key. A USD 1,250 standard invoice and a USD -1,250 credit memo are not interchangeable. Keep the original strings beside every normalized value so a reviewer can see what changed.
Lane 2: possible duplicates
A near-match is a question, not a verdict. For example, Acme Ltd and ACME LIMITED may refer to the same supplier, but case normalization alone does not prove that “Ltd” and “Limited” are an approved alias. The record should name the unresolved field and route both source documents to an authorized reviewer.
The eight-row fixture contains four traps
| Rows | Observed relationship | Expected treatment |
|---|---|---|
A001 ↔ A002 | Same invoice facts after number normalization; supplier alias unverified | Possible duplicate |
A006 ↔ A007 | All permitted exact-key fields agree | Exact candidate |
A004 | Credit memo with a negative signed amount | Protected non-candidate |
A005 | Different supplier, despite matching number, amount, and date | Protected non-candidate |
A003, A008 | Same-amount invoices with different numbers and dates | Protected non-candidates |
Download the duplicate-invoice review register to inspect or adapt all six resulting records. The candidate rows include matching and unresolved fields; the non-candidate rows retain the reason they were protected.
What happened in the answer-blind run
The Temporary Chat prompt defined the classification policy, provided all eight source rows, and required JSON. It did not name either candidate pair.
The model returned INV-A006 ↔ INV-A007 as EXACT_DUPLICATE and INV-A001 ↔ INV-A002 as POSSIBLE_DUPLICATE. It kept the credit memo, different supplier, and two different-number invoices outside the candidate pairs. The offline gate compared unordered pair identities and classifications, checked all eight source IDs, and required HUMAN_REVIEW_REQUIRED.
Near-match portion of the blind contract
POSSIBLE_DUPLICATE may be used only when invoice fields align
but supplier identity or OCR normalization still needs review.
Compare every row; include each pair once.
Do not infer fraud or take a payment action.
Return the matching fields and unresolved fields separately.The test result is narrower than “AI detects duplicates”
The accepted output proves that this one run handled the eight-row fixture. It does not measure false-positive or false-negative rates on a real AP population. Three post-run mutations were then rejected: promoting the unresolved supplier pair to exact, deleting the Pine Works exact pair, and adding the credit memo as a candidate. Those are checker tests, not additional model trials.
The complete blind-test reproduction pack contains the prompt, retained JSON, CSV, screenshot, validator, test report, and file hashes. Run the Python gate after extraction, then read the pair reasons; a passing summary cannot replace document review.
Investigate a candidate with source documents
- Verify that both rows belong to the same legal supplier and payable entity.
- Compare invoice images, purchase references, goods or services, tax, and remittance details.
- Check whether either item is a correction, reversal, recurring charge, installment, or credit.
- Inspect posting, approval, payment, and void history in the authoritative system.
- Record the disposition, reviewer, evidence references, and date.
- Apply any payment control only through the approved AP process.
Common failure patterns
| Failure | Why it is dangerous | Control |
|---|---|---|
| Absolute-value matching | Turns credits into invoice duplicates | Preserve signed amount and document type |
| Global supplier-name fuzzing | Can merge unrelated legal entities | Use verified supplier aliases or stable IDs |
| One composite confidence score | Hides which evidence is weak | List matching and unresolved fields |
| AI-triggered payment hold | Moves an uncertain classification into a consequential action | Separate review output from payment controls |
Where the exception goes next
If a payment appears twice on the bank side, reconcile the relevant period with the bank statement and cash ledger workflow. If the question is whether purchase order, receipt, and invoice agree, use the three-way match process. For scanned expense evidence rather than supplier invoices, use the receipt extraction and verification workflow.
Completion rule
The candidate register is ready for AP review when the source population is accounted for, exact rules are deterministic, possible matches expose their uncertainty, protected rows remain visible, and no operational payment state has changed. A pair becomes a confirmed duplicate only after the responsible reviewer resolves the underlying obligation from authoritative records.
