Detect a possible duplicate by comparing the supplier, currency, date, amounts and invoice lines alongside a cleaned-up reference. A reference such as INV-00482 may resemble INV 00482, but that resemblance should open a review, not decide whether the invoice is payable. Keep both original documents and show the finance reviewer what agrees, what differs and what is missing.
The workflow below is a proposed approach for accounts payable teams. Its rules and thresholds are starting points for evaluation, not tested controls or native accounting-product features.
1. Define the review boundary before matching invoices
Use the workflow to prepare a duplicate-review queue, not to reject invoices or change payment instructions.
Start with incoming supplier invoices and compare them with both recorded bills and other incoming documents. Otherwise, two copies received before either is captured could escape a ledger-only check. Separate the document identity from the accounting record identity: receiving the same PDF twice is not necessarily the same problem as capturing two bills for one obligation.
Proposed review outcomes are potential duplicate, distinct invoice, correction or replacement, and insufficient evidence. None is an invoice approval. A finance reviewer must decide what happens next under the business’s existing authority limits.
Assign a queue owner and a backup. Record who can investigate, who can authorise record changes, and who can decide payment consequences. Do not let an unattended queue become an unofficial payment hold.
This is a scoped accounting automation task: organise evidence for a finance decision while keeping accounting and payment authority with people.
2. Capture comparable fields and retain their evidence
Build a comparison record that points back to the original invoice and accounting entry.
The proposed minimum data dictionary is:
| Field | Capture and comparison treatment |
|---|---|
| Document and record IDs | Keep separate identifiers and links to originals. |
| Supplier identity | Store the selected supplier ID, printed name and unresolved identity conflicts. |
| Reference | Retain raw text and a separate normalised value. |
| Dates | Distinguish invoice date, receipt date and service or delivery period. |
| Currency and amounts | Store currency, subtotal, stated VAT, gross total and credit/debit direction separately. |
| Lines | Retain descriptions, quantities, unit amounts, line totals and source locations. |
| Supporting identifiers | Capture purchase order, delivery note and contract references where present. |
| Availability | Mark each value as present, missing, ambiguous or unreadable. |
Do not replace missing VAT with zero or assume that an unlabelled amount includes VAT. A finance professional should assess tax treatment when it affects the decision.
If AI extracts these fields, a constrained schema can make the output consistent. Source: OpenAI’s Structured Outputs documentation describes schema adherence, but a correctly shaped response is not proof that the extracted values are correct. Validate important fields against the document.
3. Normalise references without erasing meaningful differences
Create a comparison-only reference and preserve every original character for inspection.
A proposed first pass trims surrounding whitespace, converts letters to a consistent case and removes spaces or separators for an additional comparison key. Keep the less aggressively cleaned version too. This lets the reviewer distinguish a formatting match from a match that required stronger assumptions.
For example, the hypothetical references INV-00482 and inv 00482 share a separator-free key. Do not automatically strip leading zeroes, remove every prefix or replace letters with similar-looking digits. AB-482 and CD-482 might belong to different invoice series. An apparent O versus 0 difference may be an extraction error, but the image must support that interpretation.
Run exact raw-reference matching first, then normalised matching, then a proposed fuzzy comparison such as a single insertion, deletion or substitution. Treat that final comparison as candidate evidence only.
Short references need extra caution. A one-character difference in a long reference can mean something quite different from a one-character difference in 12.
4. Find candidates through more than one search route
Search within a verified supplier first, then use separate routes for altered or missing references.
A proposed initial candidate search uses the same supplier and currency with one of these conditions:
- The raw or normalised reference matches, without requiring a nearby invoice date.
- The reference differs by one character and the invoice dates fall within a proposed seven-day window.
- The gross total matches and dates fall within that window, even if the reference is absent.
- Purchase order, delivery note or line evidence suggests the same underlying supply.
The seven-day window and one-character rule are proposed settings. Broaden them only after examining what they miss. A late resend can fall outside a short date window, which is why a strong reference search should not depend on it.
Do not silently merge suppliers because their names look similar. Flag a possible master-data problem for a person to resolve. Branches, trading names and similarly named entities require context.
Include relevant paid and closed records when looking for prior invoices. Payment status helps the reviewer understand consequences; it should not hide an otherwise useful candidate.
5. Rank evidence rather than trusting one similarity score
Give reviewers explicit match reasons and contradictions instead of an unexplained percentage.
A proposed high-priority flag requires verified supplier identity, the same currency, matching gross totals, and supporting evidence such as a normalised reference match plus matching lines. A changed service period or delivery note should remain visible even when other fields agree.
A proposed ordinary review flag could cover a slightly different reference with matching amounts and nearby dates, but incomplete line evidence. Missing supplier identity, unreadable totals or unclear currency should enter an information exception rather than receive a confident duplicate label.
Compare gross amounts with gross amounts and subtotals with subtotals. Begin with exact monetary comparisons after consistent decimal parsing. If the team later proposes a rounding tolerance, document its purpose and require an explanation for the difference. A tolerance must not quietly absorb changed VAT, freight or quantities.
Line evidence is useful because identical totals can describe different purchases. Compare quantities, unit amounts, delivery identifiers and service periods, not just descriptive wording. Reordered lines may still describe the same supply; a new month of the same service may not.
6. Assemble a review pack and restrict system actions
Show both invoices, the matching fields, the differences and the proposed reason for review in one place.
The proposed pack includes original references, supplier identity evidence, date differences, amount comparisons, line-level observations, prior record status and missing fields. Link each observation to its source. Avoid a summary such as “probably duplicate” without the underlying comparison.
Use deterministic code for arithmetic and reference cleaning. AI may help organise descriptions or explain differences, but it should not invent a missing purchase order or decide that a supplier is legitimate.
Source: OpenAI’s function-calling documentation distinguishes a model’s tool request from the application code that executes it. For this design, expose only narrowly scoped read operations and review-pack creation. Do not expose payment, supplier-bank-change or invoice-deletion tools.
Source: n8n’s human-review documentation describes pausing selected tool calls for approval. That is a technical review mechanism, not a substitute for finance authority. Human judgement is still needed for accounting changes, payment consequences and security controls.
The custom AI agent glossary entry provides terminology for the optional agent component. This workflow does not require an agent to perform every step.
Reusable duplicate-review rule set
Use this proposed rule set as a starting procedure, then approve any changes through the finance owner.
Proposed duplicate-review rules
| Condition | Queue outcome | Human check |
|---|---|---|
| Verified supplier, same currency and gross total, matching normalised reference and lines | High-priority potential duplicate | Compare originals and confirm whether they describe one obligation. |
| Verified supplier, same currency and total, reference differs by one character, dates within a proposed seven days | Potential duplicate | Check line details, purchase order and delivery evidence. |
| Same supplier and amount, but different service periods or deliveries | Possible distinct invoice | Verify the separate period or delivery before closing the flag. |
| Missing reference, but matching totals and supply evidence | Potential duplicate with missing data | Inspect the original and request clarification if needed. |
| Supplier, currency or total is unresolved | Information exception | Resolve the missing or conflicting field; do not infer it. |
| Invoice appears corrected, replaced or offset by a credit note | Accounting exception | Finance determines the document relationship and accounting treatment. |
- Preserve originals and comparison values.
- Attach match reasons, contradictions and source links.
- Record reviewer, date, outcome, rationale and related record IDs.
- Keep review outcomes separate from approval, rejection and payment actions.
- Reopen the case when material new evidence arrives.
7. Evaluate flags and missed cases before operational use
Run the proposed process in shadow mode and compare its suggestions with human-reviewed examples.
Build an evaluation set containing ordinary distinct invoices, confirmed duplicate pairs, recurring charges, corrected documents, missing references and extraction failures. Have finance reviewers establish the expected outcomes from the evidence. Keep a separate set for checking revised rules so that tuning does not simply fit the examples already seen.
Measure both unnecessary flags and missed duplicates. Also record information exceptions, reviewer disagreement and the effort needed to resolve each case. Check results by supplier and document type; a rule that works for stock purchases may generate noise for monthly services.
Inspect a sample of unflagged invoices, not just the queue. Otherwise, the team learns about false alarms but not missed cases. Recheck records when new supplier formats appear or extraction software changes.
The AI agents versus automation comparison can help decide which steps should remain fixed rules. The custom AI agent workflow resource is relevant if evidence retrieval needs a more flexible design. Any benefit must be evaluated in your own process.
Worked walkthrough: a distinct invoice, a duplicate and missing evidence
Treat these fictional records as examples of human handling, not evidence of system performance. All dates, amounts and identifiers below are hypothetical.
Normal distinct invoice: A supplier’s October maintenance invoice is MAINT-1026, dated 1 October 2026, for R2,300. Its September invoice is MAINT-0926, for the same amount. The supplier and total agree, but the documented service months differ. The reviewer checks the contract and closes the duplicate flag as distinct. Normal invoice approval still follows separately.
Likely duplicate: A recorded bill is INV-00482, dated 28 September 2026, for R11,500. A new document reads INV 00482, with the same supplier, currency, date, quantities and delivery note. The proposed normalisation rule flags the pair. The reviewer compares originals and checks the existing record and payment history. If both describe the same obligation, finance records a confirmed duplicate and decides the authorised next action. The workflow does not delete either document or stop payment itself.
Missing and ambiguous evidence: Another document has no readable reference and totals R11,500. Its line descriptions resemble the earlier bill, but its delivery note is obscured. The reviewer cannot establish duplication from the amount alone. They request a clearer copy or independent supply evidence, record the unresolved point and assign an owner. A responsible finance person decides any payment timing implications.
Frequently asked questions
Resolve these questions through evidence and finance judgement rather than a stronger similarity score.
Should we remove leading zeroes from supplier references?
Not by default. Preserve the original and make any zero-stripping rule supplier-specific after checking that the supplier does not use the difference meaningfully. A proposed extra comparison key can surface a candidate, but it should not replace the reference used in the accounts record. Review examples from that supplier before adopting the rule, and keep a way to reverse it.
What if identical monthly invoices keep being flagged?
Compare the service period, contract and supporting supply evidence. The same supplier and amount do not establish a duplicate. A proposed recurring-charge exception should require a documented distinct period, not merely a supplier label saying “monthly”. Continue checking for two invoices covering that same period. Review any exception periodically, because changing formats can remove the evidence on which it relied.
Can a confirmed duplicate be automatically rejected or deleted?
Keep that outside this proposed workflow. Confirmation prepares a finance decision; it does not establish the correct accounting treatment or authorise supplier communication. A resend, replacement invoice or credit-note relationship may require different handling. Preserve the documents, record the finding and route the next action to the authorised person. Payment, tax and record-retention consequences require appropriate human judgement.
If your business needs help defining the review queue, evidence fields and exception ownership, consider Symaxx’s broader AI automation service. Get in touch to discuss a review-first scope, with proposed rules evaluated before they affect finance operations.