Duplicate invoice detection during audit looks for the same supplier invoice recorded more than once in the books. An exact match on supplier and invoice number finds only the cleanest cases, because duplicates usually arise from two entries made by different people in different formats. Effective detection uses several match rules of decreasing strictness, applied to a normalised copy of the purchase register, and separates the three outcomes that matter: booked twice and paid once, booked twice and paid twice, and not a duplicate at all.

Why duplicates happen

Almost none are deliberate. The usual causes are mundane and they determine what the duplicate looks like in the data, which is why understanding them is the starting point for designing the test.

The same invoice entered once from the original and once from a scanned or emailed copy, days apart, often by two people.
A vendor entered twice in the master under two spellings, with one invoice posted against each. The books show two vendors and two transactions; the reality is one.
An invoice re-entered after being cancelled, without the cancellation being completed.
A supplier issuing a replacement invoice for the same supply with a new number, where the original was never reversed.
Data migration or a restored backup loading a period twice.
An advance and the final invoice both recorded as purchases rather than one being adjusted against the other.

Only the first three produce anything an exact match will find, and even then only when the invoice number was typed identically both times.

Normalise before matching

Matching raw fields is the reason most duplicate tests return nothing. Work on a normalised copy, never on the register itself, and keep the original values alongside so an exception can be traced back.

Normalisation rules for Indian purchase data
Field	Normalise by	Because
Invoice number	Upper-casing, stripping spaces, slashes, hyphens and leading zeros, and separating a trailing year segment	INV/0234/25-26, inv-234, and 234 are routinely the same invoice entered by three people
Supplier	Grouping by PAN, then GSTIN, then a normalised name with legal suffixes removed	“Shreeji Traders”, “Shreeji Traders (Mumbai)” and “SHREEJI TRDRS” are one vendor
Amount	Comparing taxable value and total separately, at both exact and rounded-to-the-rupee precision	Rounding differences of a rupee or two between two entries of the same invoice are common
Date	Keeping invoice date and voucher date apart, and comparing on invoice date	The same invoice entered twice will usually have two voucher dates and one invoice date

Normalisation rules for Indian purchase data

Six match rules, in order of strictness

Run them in sequence and assign each hit to the strictest rule that catches it, so the same pair is not reported six times. Expect the strict rules to return few items and the loose ones to return many that are not duplicates at all. That is the correct shape of the output.

Duplicate match rules and what each typically finds
Rule	Match on	Typically finds	False positive rate
1. Exact	Same supplier, same invoice number, same amount	Straightforward double entry from the same document	Very low. Treat every hit as a real exception until explained.
2. Normalised reference	Same supplier group, normalised invoice number, same amount	The same invoice entered in two formats. This rule finds the largest number of genuine duplicates.	Low
3. Cross-master	Same normalised invoice number and amount, different supplier ledgers	Duplicates hidden by a duplicated vendor master. Often paid twice, because the two entries look like different vendors.	Low, and these are the highest-value hits
4. Amount and date	Same supplier group, same amount, invoice dates within a few days, invoice numbers different	Re-issued or replacement invoices, and genuine duplicates where the number was mistyped	Moderate. Recurring identical charges will appear here.
5. Same amount, same day	Same supplier group, identical amount, same invoice date	Split billing, and duplicates where the reference is absent from both entries	Moderate to high. Two identical deliveries on one day are common in some trades.
6. Payment-side	Same supplier group, same amount, payments within a short window, same or absent reference	Duplicate payments, including those against a single booking	Moderate. Instalments and round monthly payments cluster here.

Duplicate match rules and what each typically finds

Rule 3 is the one worth running even if you run nothing else. A duplicate hidden behind two vendor masters defeats the client's own controls, because the system's duplicate-invoice check, where one exists, operates within a vendor account and not across accounts.

Three outcomes, three different findings

Having found candidate pairs, the substantive question is what happened next. The three answers have materially different consequences and should never be reported as one line.

What a confirmed duplicate means
Outcome	Effect on the accounts	What to do
Booked twice, paid once	Purchases and trade payables overstated by the duplicated amount. The payables balance for that vendor will not agree to the vendor's statement.	Quantify and carry to the summary of uncorrected misstatements unless corrected. Report the control weakness to management.
Booked twice, paid twice, not recovered	A cash loss. Payables may be correctly stated because both entries were settled, so the balance sheet can look clean while money has gone.	Quantify. Establish whether the vendor was asked for a refund, and whether the amount is recoverable. Consider whether it indicates a control failure requiring wider testing.
Booked twice, paid twice, recovered or adjusted later	No misstatement at the year end if adjusted before it. A control weakness regardless.	Confirm the recovery or the adjustment against evidence, not against management's word. Record it as a control observation.
Not a duplicate	None	Record why. A pair examined and dismissed is evidence of work performed; a pair silently dropped looks like it was never examined.

What a confirmed duplicate means

A duplicate payment that was recovered before the year end still matters. It shows that the payment control did not prevent the loss and that the recovery depended on someone noticing. That is a reportable control observation even where the financial statements are unaffected.

Following a candidate through

01Obtain both source documentsTwo entries against one invoice, or two invoices. If two physical invoices exist with different numbers for the same supply, this is a vendor billing problem, not a client bookkeeping one, and the conversation is different.
02Check for a reversing entryA credit note, a journal reversal or a debit note raised on the vendor. Many candidates are already corrected and the test simply found both legs.
03Trace both entries to paymentThis is the step that determines which of the three outcomes applies, and it is the step most often skipped. Match on the bank statement, not on the payment voucher alone.
04Check the vendor's ledger and statementA vendor statement showing a single invoice against the client's two entries settles the question without further work. Vendor reconciliation and duplicate testing support each other and should be planned together.
05Look at whether the pattern repeatsOne duplicate is an error. The same vendor, the same approver or the same month appearing repeatedly is a finding about a control, and it changes what else needs testing.

Testing the client's own control

Most accounting systems can warn on a repeated invoice number within a vendor account. Where the client says the control exists, test it rather than accepting it: enter nothing, but examine whether the warning can be overridden, whether overrides are logged, and whether the control operates across vendor accounts or only within one. A control that can be dismissed with no record is a control that has not operated.

Regulatory requirement

For financial years commencing on or after 1 April 2023, the proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014 requires a company using accounting software to maintain its books to use software with an audit trail of each transaction and an edit log of changes, which cannot be disabled. Where an override or a deletion has occurred, that log is the evidence for it. Confirm the current text and the applicability to the entity before relying on this.

What good looks like in the file

The rules applied, stated explicitly, with the normalisation used for each field.
The number of candidates each rule produced, not just the confirmed exceptions.
Every candidate dispositioned: confirmed duplicate, explained, or not a duplicate with a reason.
Confirmed duplicates split by outcome, with the payment position established from the bank record.
Amounts stated separately rather than totalled with unrelated exceptions, because a duplicate payment and an unsupported credit measure different things.
A conclusion that addresses both the misstatement and the control, since a duplicate is usually evidence of both.

How we think about this

Duplicate detection is a rule-based search over a whole population. It is the clearest case in the purchase cycle where sampling adds nothing: a sample of 40 items out of 12,000 will find a duplicate pair only if both members happen to be selected. Lekhya runs these rules across the full register and shows both entries with their source documents side by side. Whether a pair is a duplicate, and what it means, is still decided by the auditor.

This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.

Free tools, no signup

Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.

Duplicate invoice detection during audit