Revenue recognition testing checks that each recorded sale satisfies the applicable recognition criteria at the date it was recorded — principally that control or significant risks and rewards have transferred to the customer — rather than simply checking that an invoice exists. In practice this means tracing a sample of recorded sales back to dispatch or delivery evidence, checking the terms that govern when transfer happens (FOB, ex-works, acceptance clauses, consignment), and looking specifically for the recurring patterns where a sale is booked before the criteria are met: channel stuffing, bill-and-hold, and consignment stock misclassified as a sale.
Which recognition framework applies
Companies applying Ind AS recognise revenue under Ind AS 115, which replaced the separate risk-and-rewards test with a five-step model built around the transfer of control of goods or services to the customer. Companies outside the Ind AS roadmap, including most private limited companies audited under the Companies Act using Indian GAAP, continue to apply AS 9, which centres on the transfer of significant risks and rewards of ownership. The two frameworks ask a related but not identical question, and the audit approach below works under either, but the note you write in the file should name which framework the client actually applies and why.
Regulatory requirement
Ind AS 115 governs revenue from contracts with customers for entities to which Ind AS applies. AS 9 continues to apply to entities following Indian GAAP. Confirm which framework is applicable to the specific client before designing tests, since the criteria and disclosure requirements differ.
Designing the substantive test
The starting population is the sales register for the year, reconciled to the ledger and the trial balance exactly as you would reconcile a purchase register. From that reconciled population, the recognition test itself has four components that should be visible in the working paper as separate steps, not folded into one generic "vouching" step.
- 01Identify the transfer trigger in the contract or purchase orderRead the terms of sale for the sampled item: FOB destination, ex-works, delivery at customer site, or an acceptance clause. This single fact determines which document should carry the recognition date, and it is routinely skipped in favour of just checking the invoice exists.
- 02Trace the recorded date to the transfer event, not to the invoice dateFor goods, this is the dispatch or delivery evidence — gate pass, lorry receipt, e-way bill, or a signed delivery challan. For services, it is completion or milestone acceptance. An invoice can be raised on a date that has no relationship to when control actually transferred.
- 03Check for conditions that defer recognitionRight of return clauses, installation or acceptance obligations not yet performed, and retention of a significant performance obligation after dispatch. Any of these can mean a dispatched item is not yet a completed sale.
- 04Recompute the amount against the agreed price, not just the invoiceRebates, volume discounts and scheme credits agreed outside the invoice are a common source of overstated net revenue when they are not deducted at the point of recognition.
The three misstatement patterns that recur
| Pattern | What it looks like | How it is found |
|---|---|---|
| Channel stuffing | Distributors or dealers are pushed inventory near year end, often with an informal understanding that unsold stock can be returned, to inflate the current period's sales | A spike in sales to specific dealers in the last fortnight of the year, followed by unusually high sales returns from the same parties in the following quarter |
| Bill-and-hold | An invoice is raised and revenue booked, but the goods remain in the seller's premises or a third-party warehouse, with no genuine business reason for the customer to have requested the hold | Dispatch or gate records show no corresponding outward movement for the invoice date; stock on hand at year end includes goods already invoiced to a customer |
| Consignment misclassified as sale | Goods sent to an agent or distributor on consignment, where title has not transferred, are recorded as a sale on dispatch rather than on sale by the consignee | Consignment or stockist agreements exist alongside sales to the same party; the agent's own stock records would show the item as unsold inventory |
Bill-and-hold arrangements are not automatically improper, but they require that the customer has requested the arrangement for a substantive business reason, the goods are identified separately as belonging to the customer, and the goods are ready for immediate delivery. Treat any bill-and-hold sale you find as needing all three to be evidenced, not assumed.
What evidence actually ties a sale to a transaction
An invoice alone proves that a document was generated. It does not prove a sale happened on the terms the entity claims. The chain of evidence that does is: purchase order or contract, showing the agreed terms; dispatch or delivery evidence, showing physical movement and its date; and, where relevant, an acceptance or completion record. A recognition test that stops at the invoice has tested that the accounting system produced a document, which is not the assertion at risk.
- Purchase order or signed contract — establishes the agreed terms of transfer and price
- Gate outward register, lorry receipt, or e-way bill — establishes physical dispatch and its date
- Proof of delivery or customer acknowledgement — establishes receipt where terms require it
- Acceptance certificate or completion milestone sign-off — required where the contract makes recognition conditional on acceptance
- Correspondence or scheme circulars evidencing any rebate or return right attached to the sale
Sizing the sample and the risk
Revenue is almost always a significant risk area, and recognition near the year end is where the risk concentrates. A reasonable approach samples transactions through the year for the basic chain-of-evidence test, and separately samples a higher proportion of transactions in the final fortnight before year end and the first fortnight after, specifically for the recognition-timing question. The two samples answer different questions and should not be merged into one population.
How we think about this
Matching an invoice to a dispatch record and a purchase order is a reconciliation task with a checkable right answer, and software should do it across the whole population rather than a person across a sample. Deciding whether a bill-and-hold arrangement has a genuine business reason, or whether a dealer's year-end purchases look like stuffing, is a judgement about intent and substance that a person has to make and sign.
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.
- Revenue, receivables & cut-offAuditing sales returns and credit notesWhy post-year-end credit notes are a classic overstatement signal, how to match them to the original invoice, and the GST reporting implications auditors should check.
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.