This is a composite, illustrative scenario built from how revenue cut-off testing typically surfaces an exception at year end, not an account of a named client. A sizeable sales invoice was dated the 31st of March, the last day of the financial year, but the dispatch record for the same goods showed them leaving the warehouse on the 3rd of April. Under the terms of sale, risk and reward transferred on dispatch, not on invoicing, which meant the revenue belonged to the following year regardless of what date was printed on the invoice. The client's own system had generated the invoice automatically from a sales order raised before year end, with no check against the actual dispatch date — a systemic gap, not a one-off, which changed the scope of the testing needed to close it out.
Why invoice date alone would have missed it
A cut-off test that only checks invoice dates either side of the year end would have seen a perfectly ordinary 31 March invoice and moved on. The exception only exists once the invoice date is checked against something external to the invoice itself — the dispatch record, the delivery challan, the transporter's gate-out log — because the invoice date is simply whatever date the system was told to print, not evidence of when the transaction actually occurred.
| Delivery term | When revenue should be recognised | What evidences it |
|---|---|---|
| Ex-works / FOB at seller's premises | On dispatch from the seller's location | Gate-out log, transporter's lorry receipt, delivery challan |
| Delivered at destination | On receipt by the buyer | Buyer's acknowledgement, proof of delivery, transporter's delivery confirmation |
| Bill-and-hold arrangement | Only once specific conditions are met — not on invoicing | Written agreement terms, evidence the goods are identified and ready, buyer's acknowledgement of the arrangement |
An invoice dated before the year end for goods that leave the warehouse after it is not automatically wrong — if the delivery term is bill-and-hold and the conditions were genuinely met, early invoicing with later physical dispatch can be correct. The exception here was that no such arrangement existed; the goods were simply dispatched late relative to a standard ex-works sale.
What was checked once the gap was found
- 01Pulled the sales order and delivery termsA standard ex-works sale with no bill-and-hold clause. Nothing in the contract justified recognising revenue ahead of dispatch.
- 02Checked the gate-out log against the invoiceConfirmed the three-day gap directly from the transporter's own record, not just the client's internal dispatch note, to rule out an internal document simply being filled in late.
- 03Asked how the invoice had been generatedAutomatically, from the sales order, at month-end batch processing — with no system check comparing the invoice date against an actual dispatch confirmation. This was a process gap, not a one-off manual entry.
- 04Widened the test to the rest of the year-end populationChecked every invoice dated in the final five days of the year against its corresponding dispatch record, not just the one that had already surfaced.
What the widened check found
Two more invoices in the final week showed the same pattern — invoiced before year end, dispatched after it — for a combined amount that, added to the first, was material to pre-tax profit for the year. That changed this from a single adjusting entry into a required reclassification across three transactions, with the client's finance team asked to review their batch-invoicing process for every order near a period end going forward, not just fix the three identified.
| Before adjustment | After | |
|---|---|---|
| Revenue recognised in the audited year | Included all three invoices | Excluded all three — moved to the following year |
| Inventory at year end | Excluded the dispatched-after-year-end goods (treated as sold) | Included them — still owned at year end |
| Materiality | N/A | Combined adjustment was material to pre-tax profit; required a formal adjusting entry, not a management letter point alone |
What went into the working paper
- The dispatch terms from the sales contract, establishing when risk and reward actually transferred.
- The gate-out log evidence for each of the three invoices, sourced from the transporter's record rather than an internal document alone.
- The adjusting entry: revenue and the related receivable reversed from the audited year, inventory reinstated.
- A note on the root cause — automated batch invoicing with no dispatch-date check — distinct from the adjustment itself, since the same gap will recur next year end if the process isn't changed.
- A management letter point recommending a system check comparing invoice date to dispatch confirmation before posting, specifically for orders raised in the final fortnight of the year.
How we think about this
Testing every invoice in a cut-off window against its dispatch record, rather than a sample of them, is what actually catches a systemic process gap like this — a sample finding one exception out of three would have looked like an isolated error rather than the three-invoice pattern that made it material. This is the specific reason Lekhya's revenue testing checks the full population in the cut-off window by default.
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
- Revenue, receivables & cut-offSales cut-off testing: dispatch, invoice and ledger datesWhy dispatch, invoice and ledger dates disagree at year end, how to sample either side of the cut-off, and the evidence that settles which date governs.
- Revenue, receivables & cut-offMatching dispatch, invoice and ledger for revenue testingThe sales-side mirror of the purchase three-way match: what breaks it in practice, and why the unmatched population should be sized by value, not count.
- Revenue, receivables & cut-offCommon exceptions in revenue and receivables testingA reference catalogue of the exceptions that recur most often across revenue and receivables testing, why each happens, and what to do about it.
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.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- 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.