A fixed-count cut-off sample — the last twenty invoices before the period end and the first ten after — is built on an assumption that invoicing happens at a roughly steady pace through the month. The transaction pattern that actually drives cut-off risk is the opposite of steady: a client who invoices unevenly, often with a sharp spike in the final two or three days of the period, to pull revenue into the current year or simply because that is when deliveries happen to clear. A fixed count applied to a burst either samples only part of the burst and calls it done, or samples transactions from a quiet earlier week that were never at risk in the first place.
What a burst actually looks like
Take a distribution business that raises roughly four invoices a day through most of the month and forty on the last two days of March. "Pull the last twenty before year end" captures roughly half of that burst and stops — the other twenty invoices in the exact window where cut-off risk concentrates are never looked at. The sample looks complete on paper: twenty invoices traced, no exceptions found in the sample. The population it was drawn from was never representative of where the risk actually sat.
- A count-based rule treats every invoice as equally likely to be selected, but invoicing volume near year end is rarely even — a count anchored to the calendar, not the invoice date distribution, samples whatever volume happens to exist in that slice
- On a high-volume day the fixed count runs out before the day's invoices do; on a low-volume day it reaches back further than the risk period actually extends
- A reviewer looking only at 'was the sample size reasonable' has no way to tell, from the count alone, whether the burst was fully covered or barely touched
Why this is the exact pattern cut-off testing targets
Burst invoicing right before a period end is not incidental noise — it is frequently the signature of the thing cut-off testing is designed to detect: revenue pulled forward to meet a target, or genuinely delivered revenue that happens to cluster for operational reasons (month-end dispatch pushes, sales teams closing deals to hit quota, logistics batching). Either way, the transactions in that burst are precisely the ones where the gap between invoice date and actual delivery or completion is most likely to straddle the period end. A selection method that structurally under-samples the burst is under-sampling the highest-risk part of the population, in exactly the client where that matters most.
A clean result from a fixed-count sample on a burst-invoicing client is not reassuring. It is more likely evidence that the sample never reached the risk, not evidence that the risk isn't there.
The alternative: select by window, not by count
A window-based rule — flag every transaction dated within a configured number of days of the period end, across the whole population, regardless of how many that turns out to be — does not care whether the client invoices four a day evenly or forty in a two-day burst. The burst and the quiet period each get the same treatment: every transaction inside the window is flagged, none outside it is. The quiet client produces a short list. The burst client produces a long one, and that length difference is itself useful information before a single invoice has been traced.
| Fixed count (last 20) | Window (7 days, full population) | |
|---|---|---|
| Transactions in the final 2 days before year end | ~20 of ~40 captured | All ~40 captured |
| Transactions 3–7 days before year end | 0 — count exhausted | All captured |
| Effort if invoicing is actually even that month | Same as always | Short list, low effort |
| What's traced for each flagged item | Manual, by a person | Manual, by a person |
That last row matters. Moving from a fixed count to a window changes which transactions get selected for tracing, not what happens once they're selected. Nothing about window-based selection concludes on cut-off by itself — a person still has to pull the delivery challan, e-way bill, or completion record for every flagged invoice and decide whether revenue was recognised in the right period. The window fixes a selection problem; it is not a substitute for the trace.
How we think about this
Lekhya's revenue and cut-off testing flags every transaction inside the configured window across the full population specifically because a fixed-count rule can't adapt to how unevenly a client actually invoices — but it stops at the flag. The tracing against dispatch evidence is, deliberately, left to the person doing the audit.
Common practice, not a requirement
If a client's invoicing is genuinely even month to month, a window-based selection and a fixed-count sample will often flag a similar number of transactions. The difference only shows up — and matters — on exactly the clients where invoicing isn't even, which is worth checking for before assuming a fixed count is good enough.
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-offRevenue cut-off testing across the full population, not a sample around the year endThe hard part of cut-off testing was never the tracing. It was deciding which invoices to pull in the first place.
- 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.
- Audit data & extractsSample-based to full-population testing: what changes in engagement economicsTesting every transaction instead of a sample doesn't just change audit quality — it changes where the firm's hours go and what the engagement fee conversation looks like.
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.