This is a composite, illustrative scenario built from how duplicate-invoice exceptions typically surface in a purchase audit, not an account of a named client. A vendor was paid twice for the same delivery because the second invoice used a different invoice number and arrived four days after the first. The sample-based vouching that had already run found nothing, because both invoices individually looked clean; the duplicate only became visible when the full population was matched on vendor, amount and date rather than on invoice number alone. The fix was a one-line recovery and a control recommendation, but finding it three days before sign-off meant redoing the conclusion on the whole purchase section under time pressure that a full-population check would have avoided.
How it was missed the first time
The purchase section had already been tested. A risk-targeted layer covered new vendors and round-sum amounts; a representative sample covered the rest. Both invoices for this vendor existed in the population, but neither fell into the sample — one was a mid-value, routine-looking payment to an established vendor, and the kind of item a monetary-unit sample has no particular reason to pick twice out of several hundred similar lines.
This is not a sampling failure. A representative sample is built to say something about the population as a whole, not to catch every individual anomaly in it — a duplicate hiding among otherwise-ordinary transactions is exactly the kind of thing sampling is structurally weak against.
How it actually surfaced
It came up during final analytics, in a vendor-ledger review run across the whole year rather than a sample: the same vendor had two postings four days apart, same net amount to the rupee, different invoice numbers. On most engagements that pattern is innocent — a part-delivery split into two invoices, a credit note and a re-bill — so the first step was not to flag it as a duplicate but to pull both source invoices and check what they actually described.
- 01Pulled both invoices and compared line items, not just totalsIdentical items, identical quantities, identical rate. Not a part-delivery or a re-bill — the same delivery, billed twice.
- 02Checked the goods receipt recordOne GRN existed for the delivery, matched to the first invoice. The second invoice had no corresponding receipt entry at all, which was the structural gap that let it through.
- 03Checked who approved the second paymentApproved by the same person who approved the first, at a value just inside their individual sign-off limit — not clearly a deliberate override, but a pattern worth a separate note in the management letter regardless of intent.
- 04Quantified and raised it, then kept testingOne exception does not justify assuming the whole vendor population is compromised, but it does justify widening the vendor-ledger duplicate check across every vendor, not just this one, before concluding.
What the widened check turned up, and what it didn't
Running the same vendor-amount-date match across the full purchase population found one more pair, for a different vendor, that turned out to be a genuine part-delivery split — two invoices, two separate GRNs, no exception. That result mattered as much as the real duplicate: it confirmed the detection method wasn't manufacturing false positives, and it meant the conclusion on the purchase section could state that the population had been checked for this specific pattern, not just sampled.
| Sample-based testing | Full-population duplicate check | |
|---|---|---|
| Duplicate found | No — neither invoice fell in sample | Yes — one real duplicate, one false lead resolved as genuine |
| When it surfaced | Would not have, absent a separate analytics step | Before the conclusion was drafted |
| What the file can state | "A sample of purchases was tested, no exceptions noted" | "The full vendor population was checked for duplicate payment patterns" |
Common practice, not a requirement
A vendor-amount-date duplicate check across the full population takes minutes to run and catches a failure mode sampling is not designed to catch. Firms that already run one routinely as part of final analytics, rather than relying on it to surface by chance, find this kind of exception earlier and with time left to deal with it properly.
What the file needed before sign-off
- The duplicate payment identified, quantified, and the recovery action from the vendor recorded.
- Confirmation that the recovery was actually initiated before the engagement closed, not assumed.
- A management letter point on the control gap: no GRN matching requirement before payment release.
- The widened duplicate check across the full vendor population, and its one false-lead result, documented so the conclusion isn't resting on a single find.
- A note on why the original sample did not and could not have caught this, so a future reviewer doesn't read it as a sampling error.
None of this changed the audit opinion — the amount was below materiality on its own. What it changed was how late the finding, the recovery, and the control point all had to be dealt with, and how much of that could have happened with time to spare if the full-population check had run earlier in the engagement rather than during final analytics.
How we think about this
This is the specific gap Lekhya's purchase testing is built to close: matching vendor, amount and date across the entire purchase population as a standing check, not a final-analytics afterthought, so a pattern like this surfaces in week two of fieldwork rather than three days before the partner signs.
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.
Related resources
- Purchase & AP auditDuplicate invoice detection during auditWhy exact matching finds almost nothing, the six match rules that do work, and how to tell a duplicate booking from a duplicate payment.
- Purchase & AP auditPurchase testing: a complete exception taxonomyEvery category of finding a three-way match can produce, what each usually means in an Indian mid-market client, and which are worth escalating versus documenting and moving on.
- Purchase & AP auditPurchase invoice vouching: a practical approachWhat to examine on a purchase invoice, in what order, the tickmarks worth using, and how to record the test so a reviewer can tell what was checked without asking.
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.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.