A cut-off testing window has to be sized to how long it actually takes the client to get goods out the gate after invoicing, not to a default number of days. A retailer who ships same-day can use a narrow window, five to seven days either side of the period end, because an invoice dated close to year end is also dispatched close to year end. A manufacturer who invoices against a production schedule and dispatches two or three weeks later needs a window wide enough to catch invoices raised well before the period end that haven't actually gone out yet — and the reverse, dispatches just after year end against invoices raised weeks earlier. Get the width wrong and the window-based selection, however complete it is within its own boundaries, simply doesn't reach the transactions that matter.
Why manufacturing breaks a one-size window
In a make-to-order or make-to-stock-then-allocate business, invoicing is often tied to a production or allocation milestone, not to the goods physically leaving the factory. A unit can be invoiced the day it comes off the line and sit in the finished goods yard for ten, fifteen, twenty days waiting for a truck, an export document, or a customer's own readiness to receive. That gap between invoice date and dispatch date is exactly the gap cut-off testing is meant to probe — and a narrow window simply never sees the invoices sitting furthest out in that gap.
- Heavy engineering, machinery, and capital goods: dispatch frequently trails invoicing by two to four weeks, sometimes longer for export consignments awaiting documentation
- Textile and garment manufacturing on long production runs: batches invoiced together but dispatched in tranches over the following fortnight
- Pharma and chemicals with batch release testing: invoice can precede the quality-release date that actually gates dispatch
- Contract manufacturing with named-carrier pickup schedules: dispatch date is set by the carrier's route, not the client's warehouse
A practical way to size the window
- 01Pull the average invoice-to-dispatch gap from last year's dataFor a sample of transactions from the prior period, compare the invoice date on the sales register to the dispatch date on the corresponding delivery challan or e-way bill. The spread, not just the average, tells you how wide the tail is.
- 02Set the window to cover the tail, not the medianIf most invoices dispatch within five days but a meaningful minority take eighteen, a five-day window misses exactly the transactions most likely to straddle a period end. Size to the tail.
- 03Widen further for the specific monthProduction schedules often bunch around month end regardless of normal lead time — a year-end push to ship everything invoiced in March before April 1 is common and argues for widening the window for that one period even if the rest of the year runs narrower.
- 04Document the basis for the width chosenA reviewer should be able to see why fourteen days was chosen over seven, tied to the actual dispatch data, not a round number picked because it sounds reasonable.
Common practice, not a requirement
Many firms run two different window widths within the same engagement when the client has both a fast-moving spares business and a slow-moving capital equipment line. One window for the whole revenue population understates risk on the slower line and overstates the tracing burden on the faster one.
What the wider window does and does not do
Widening the window increases the number of transactions flagged for tracing — that is the point, not a cost to minimise away. A fourteen-day window on a manufacturing client with genuine long lead times will surface more invoices than a seven-day window would, and that is the window doing its job of reaching the part of the population where a genuine cut-off error is most likely to sit. What the window does not do, at any width, is look at a dispatch note itself. Lekhya's revenue and cut-off testing flags every transaction within the configured window across the full population; it does not hold a dispatch-date field and does not compare invoice date to dispatch date on its own. Someone still pulls the delivery challan or e-way bill for each flagged transaction and makes the actual cut-off call.
Do not assume a wide window plus a long list of flagged invoices means the selection has done the conclusive work. A hundred flagged transactions that nobody traces back to a dispatch document is a hundred open questions, not a hundred cleared exceptions.
| Client profile | Starting window width |
|---|---|
| Retail / e-commerce, same-day or next-day delivery | 3–5 days either side of period end |
| FMCG distribution, short lead time | 5–7 days |
| General manufacturing, standard lead time | 10–14 days |
| Capital goods / export consignments / batch release | 14–21 days, or longer on documented history |
How we think about this
Lekhya leaves the window width as a per-engagement setting the team controls, rather than a fixed default, because a dispatch cycle is a fact about the client's business that no tool can infer on its own — it has to come from the team that knows the client.
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-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.
- Inventory & stockInventory cut-off testing around the year endGoods-in-transit at year end, last GRN and dispatch numbers before and after cut-off, and matching to the stock count and purchase/sales cut-off testing.
- 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.