Reviewing a completed cut-off testing working paper means checking, for every transaction that was flagged within the window of the period end, that there is an actual document behind the tick mark, that the document is dated and legible enough to support a conclusion, and that the conclusion reached is stated rather than implied. A list of flagged transactions with a column of ticks and no narrative is not evidence that cut-off was tested — it's evidence that a population was selected, which is a different and much smaller claim.
Start with the population, before looking at any single row
- Confirm the window width used (number of days either side of the period end) is stated in the working paper and matches what was agreed for this client, not a generic default carried over from a template
- Confirm the population the window was applied to is the full sales register for the period, not a pre-filtered or branch-limited extract
- Spot-check that the count of flagged transactions is consistent with the window width and the client's known invoicing volume — a suspiciously short list on a high-volume client is worth asking about before accepting it
Then check each flagged transaction individually
- 01Is there a document, not just a reference to oneA row that says 'traced to dispatch note, no exception' with no dispatch note attached or filed is a statement, not evidence. The actual document — delivery challan, e-way bill, completion certificate — should be in the file or clearly referenced to where it sits.
- 02Does the document's date actually answer the cut-off questionA dispatch note dated the same day as the invoice doesn't, by itself, confirm the goods left before the period end if the invoice itself is dated after the period end — check which side of the boundary the relevant date actually falls, not just that a date exists.
- 03Is the conclusion stated, not inferred from the absence of a commentEvery traced item needs an explicit conclusion — 'invoice dated 29 March, dispatch note dated 28 March, no exception' — rather than a blank column that a reviewer has to interpret as 'presumably fine'.
- 04Are exceptions carried through to a summary, not left stranded on the detail scheduleA flagged transaction that does turn out to be a genuine cut-off error needs to show up in the exceptions summary and, where material, in the adjustment or disclosure discussion — not just sit noted on the detail working paper with no further trail.
- 05Check the boundary cases specificallyTransactions dated on the period end date itself, or within a day of it, deserve the closest look — ask specifically whether these were traced with the same rigour as the rest of the list, since they're the ones most likely to be genuinely ambiguous.
Watch for a working paper where every single flagged transaction concludes 'no exception' with identical wording. That pattern often means the trace was done superficially or the conclusions were copy-pasted down the column, not that the client genuinely had a clean cut-off across the board.
What the selection step can and can't tell a reviewer
If the population was selected by a window-based rule across the full dataset — the approach Lekhya's revenue and cut-off testing applies — a reviewer can be confident the list of flagged transactions is complete for the window chosen: nothing inside the window was dropped, and nothing was selected by a count that could have run out early. What a reviewer cannot infer from that selection step is anything about the individual transactions themselves. The tool does not hold a dispatch-date field and does not compare invoice date to delivery date; it has not looked at a single dispatch note. Every row still needs the document-level checks above, done by a person, regardless of how reliably the population was assembled.
| Claim | True of window-based selection | Requires separate manual evidence |
|---|---|---|
| The population includes every transaction within X days of period end | Yes | No |
| Each flagged transaction was traced to a dispatch or completion document | No | Yes |
| Each traced transaction's date was correctly interpreted relative to the period end | No | Yes |
| Exceptions found were carried to the summary and considered for adjustment | No | Yes |
Common practice, not a requirement
A reviewer short on time often defaults to re-counting the flagged list and checking the total looks reasonable. That confirms the selection step worked. It says nothing about whether the trace underneath each row actually happened — those need to be sampled and checked separately, even on a tight review budget.
How we think about this
A tool that reliably produces the full, correctly-windowed population removes one entire category of review risk — an incomplete or mis-bounded selection — and leaves the rest exactly where professional judgement belongs: with the person who read the dispatch note.
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-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.
- 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.
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.