AI for Internal Finance Teams — Free webinar on using Claude/AI for variance commentary. June 4, 11 am AEST. Register now →

Implementing Duplicate Invoice Detection Workflows in Practice

Step-by-step guide to implementing duplicate invoice detection in Xero and MYOB, including control checkpoints for accounting practices.

Joey Hotz · 15 January 2026 · 5 min read · Updated 4 May 2026

TL;DR

Duplicate invoices enter AP through predictable routes -- resent invoices, multi-channel submissions, and supplier billing errors. Catching them at intake allows simple rejection, while catching them after payment requires reversals and supplier negotiations. Effective detection goes beyond exact invoice number matching to include fuzzy supplier name, amount tolerance, and date window checks.

Duplicate invoices enter AP systems through predictable routes: the same invoice emailed twice, a supplier resending after a payment query, a bookkeeper entering a bill that had already been processed through a different channel, or a supplier numbering system that reuses references across periods. This is one of several AP control gaps covered in the accounts payable fraud vulnerability guide. The mechanism is usually mundane. The consequence is a payment that is difficult to recover and, in most cases, avoidable at the point of intake.

Where does detection need to happen?

The critical timing issue is pre-ledger versus post-payment. Xero and MYOB both include basic duplicate detection - they warn when a bill with the same supplier and reference number already exists. What this misses is the second category of duplicate: same supplier, same amount, different reference number. A supplier that resends an invoice with an incremented reference, or an attacker who resubmits with a slightly altered one, passes through the native check unchallenged.

Detection that runs before the invoice enters the coding and invoice approval workflow queue - comparing supplier, amount, date window, and invoice number as a combined signal rather than any single field - catches both categories. Detection that runs only at ledger entry catches the first category and misses the second. Detection after payment catches nothing except the size of the problem.

What does reliable detection logic check?

A single-field check - reference number only, or amount only - is unreliable in both directions. Reference-only detection misses re-submissions where the number has been adjusted. Amount-only detection generates false positives for suppliers with consistent pricing: a materials supplier charging the same weekly rate for three months looks like a duplicate every week.

The combination that works: supplier identity from the vendor master data, invoice reference number, invoice amount, and a date lookback window of 60 to 90 days. A match across three or four of these fields is a reliable duplicate signal. A partial match triggers human review rather than automatic rejection, because some legitimate invoices genuinely share characteristics with prior bills.

A bookkeeper at a wholesale distributor in Adelaide managing 130 invoices per month implemented automated duplicate detection through a structured AP workflow. In the first month, three invoices were flagged: two were genuine re-submissions from suppliers following up on late payment, one was a data entry error from a new accounts staff member who hadn’t checked the queue before entering manually. All three were caught before ledger publication. The alternative was catching them after payment, which requires a reversal entry in the accounting system, a supplier communication, and - if the supplier has already processed the payment - recovery proceedings that take days rather than minutes.

What the review process looks like

Automated detection should flag rather than auto-reject. The reviewer’s role is to confirm whether a flagged invoice is a genuine duplicate or a legitimate re-submission. The distinction matters: a supplier who sends the same invoice twice after not receiving payment confirmation is not attempting fraud - they need a response, not a rejection.

The review decision and its outcome should be captured in the audit trail regardless of which way it resolves. The guide to building an audit-ready approval matrix explains how to structure audit trails that capture these exception decisions alongside standard approvals. A flag with no recorded outcome is a control gap in the audit trail - you know the system identified something unusual, but there is no record of what was decided or by whom.

When a duplicate is confirmed, the investigation should determine the source: supplier billing error, double-channel submission, or internal processing error. Each source has a different process fix. A supplier who consistently resends after payment goes to a communication workflow change. A double-entry from a new staff member goes to an onboarding process review. Neither is fixed by rejection alone.

The maintenance problem most businesses skip

Duplicate detection is not a one-time configuration. Suppliers change reference numbering systems. New suppliers enter with unfamiliar patterns. Staff turnover changes who applies the detection logic and whether they understand why it exists.

The most common failure mode is a detection system that was configured once and never reviewed. An 18-month-old detection rule built around ten active suppliers may generate excessive false positives for the forty active suppliers the business now has - or, worse, may miss legitimate duplicates because the patterns have changed. A quarterly review of flagged invoices, false positive rates, and supplier-level patterns keeps the detection logic current without requiring a full reconfiguration.


Sources: ATO - Record-keeping requirements for business · ATO - E-invoicing and invoice processing in Australia


Further reading: Best AP Automation Software Australia 2026 · What a Modern AP System Needs to Do · The Real Cost of Manual AP

Frequently asked questions

How does duplicate invoice detection work in AP automation?
Duplicate invoice detection checks incoming invoices against the historical bill register and the current approval queue, comparing supplier, amount, invoice number, and date. A match or near-match triggers a flag before the invoice enters the approval workflow. Detection at this stage allows rejection or consolidation before approval, avoiding the reversal and supplier communication required after a duplicate payment is made.
What are the most common causes of duplicate invoices in accounts payable?
The most common causes are suppliers resending invoices after not receiving payment confirmation, the same invoice arriving through multiple channels (email and post), invoices submitted by different people within the business without awareness of the duplicate, and supplier billing system errors that generate multiple invoices for the same delivery. Volume and multiple invoice intake channels both increase duplicate frequency.
Why should duplicate detection happen at intake rather than after posting?
Catching a duplicate invoice at intake allows simple rejection - the invoice is not processed. Catching it after approval and payment requires a reversal transaction in the accounting system, a supplier communication to arrange return of funds, and possible bank recovery proceedings if the supplier does not respond. The earlier in the workflow a duplicate is caught, the lower the cost of resolution.
What detection logic does AP automation use beyond invoice number matching?
Advanced duplicate detection checks fuzzy matches on supplier name, amount within a tolerance range, and date within a rolling window - not just exact invoice number matches. Suppliers occasionally reissue invoices with new numbers for the same charge. Amount-based detection catches these. Cross-supplier detection can also flag the same amount and date appearing from related entities.

Ready to automate your AP?

Go beyond capture and basic workflows. Pulsify codes, validates, routes, and syncs every invoice automatically.