Revenue cut-off testing is reliable only to the extent the population selected around the period end is complete. Picking a fixed number of invoices either side of the balance sheet date — the last twenty, say — misses whatever falls just outside that count on a client with uneven invoicing volume. Running the selection across the full population, flagging every transaction within a window of the period end for someone to trace, removes that selection risk even though the actual tracing — checking the invoice date against the dispatch note, the delivery challan, or the service completion record — still has to be done by a person.
Why a fixed count is the wrong selection rule
"Pull the last twenty invoices before year end and the first ten after" is a selection rule that works for a client who invoices evenly through the month and fails for one who invoices in bursts — a client who raises forty invoices in the last three days of the month, which is exactly the pattern cut-off testing exists to catch. A fixed count applied to an uneven population either misses the burst entirely or pulls in a sample that isn't actually the highest-risk set of transactions.
Common practice, not a requirement
A window measured in days around the period end, applied to every transaction rather than a count, adapts to however the client's invoicing actually falls. The window's length is still a judgement call for the engagement team — a business with long dispatch lead times needs a wider window than one that ships same-day.
What a window-based selection actually gives you
- Every invoice dated within the configured window of the period end, across the entire population, not a fixed count chosen in advance
- Nothing in the window is dropped for being 'clearly fine' — the selection is mechanical, and the judgement about each one happens after selection, not during it
- A client with no unusual year-end concentration produces a short, quiet list; a client with one produces a visibly longer one, which is itself a signal worth noting before a single invoice has been traced
What still has to be done by hand
Selecting the population is not the same as concluding on it. For each transaction the window surfaces, the actual cut-off question — did the goods leave, or the service complete, before or after the period end, relative to when revenue was recognised — depends on tracing to a document a selection tool does not generate: a dispatch note, a delivery challan, an e-way bill, a signed completion certificate. No automated matching replaces that trace, because the relationship between an invoice date and the moment control actually transferred is not something the invoice itself records.
Treat a flagged transaction as 'needs tracing', never as 'is a cut-off error'. A tool that narrows the population to the right set of invoices has done real, valuable work. A tool that implies it has already concluded on cut-off without seeing the dispatch document has overstated what it did.
Sizing the window
| Factor | Effect on window size |
|---|---|
| Long dispatch lead time (manufactured-to-order goods) | Wider — more days between invoicing and actual delivery |
| Same-day or next-day delivery (retail, e-commerce) | Narrower — invoice date and dispatch date are close by nature |
| History of a prior-year cut-off adjustment at this client | Wider, for at least one cycle, regardless of lead time |
| Service revenue with no physical dispatch at all | Different test entirely — completion date substitutes for dispatch date |
There is no standard answer, and a firm that applies the same seven-day window to every client regardless of how that client actually operates is making the same mistake as the fixed-count approach, one level up.
How we think about this
Lekhya's revenue and cut-off testing runs the window-based selection across the full population, and is explicit about where it stops: it surfaces exactly the transactions a reviewer needs to trace, and it does not claim to compare dispatch date against invoice date on its own, because no system should claim a conclusion it hasn't actually reached the evidence for.
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.
- Purchase & AP auditCut-off testing for purchases: procedures and worked examplesWhich dates to compare, how terms of delivery decide the answer, how to size the window, and four worked examples including the two that are usually misjudged.
- 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.