An audit working paper records one piece of audit work in a form another auditor can follow without explanation. It needs nine things: identification of the entity and period, the objective of the procedure, the population and evidence that it is complete, the basis on which items were selected, what was actually done, what was found including the items that passed, how each exception was resolved, a conclusion in the preparer's own words, and evidence of who prepared and reviewed it and when.
The test a working paper has to pass
SA 230 requires documentation sufficient for an experienced auditor with no previous connection to the engagement to understand the nature, timing and extent of the procedures performed, the results obtained and the evidence obtained, and the significant matters arising and the conclusions reached on them. Everything about the structure of a working paper follows from that one requirement.
The practical version is shorter. Hand the paper to a competent auditor who has never met the client and cannot call you. If they have to guess at what you did, why you picked what you picked, or how you got from the exceptions to the conclusion, the paper is insufficient.
Regulatory requirement
SA 230, Audit Documentation, as issued by the ICAI, sets the requirement summarised above. Paragraph numbers and the precise wording are not quoted here because they change and misquoting them is worse than omitting them. Read the current text before relying on any summary, including this one.
The nine parts
| Section | Must establish | Fails when it says |
|---|---|---|
| Header | Entity, period, file reference, area, and the financial statement line item the work supports | Nothing. A paper with no period on it is a common and surprisingly serious defect. |
| Objective | Which assertion the procedure addresses and why that assertion is a risk here | “To verify purchases.” This restates the account name, not the objective. |
| Population | What the population is, where it came from, and evidence that it is complete | “Purchase register provided by client.” Provided is not agreed. An unagreed extract is not a population. |
| Sample basis | How items were selected and why the method suits the risk identified | “Judgemental.” That is the absence of a basis, not a basis. |
| Procedure | What was actually done, specifically enough to be repeated | “Test checked.” Nobody can reperform that. |
| Results | What was found across the whole selection, including the items with no exception | Only the exceptions, which leaves the extent of the work undocumented |
| Exceptions | Each one, its investigation, its resolution and its effect | An open list with no outcomes against a conclusion that everything is satisfactory |
| Conclusion | What the work showed about the assertion, in the preparer's own words | “Purchases were tested and found to be in order.” This records that work happened, not what it showed. |
| Sign-off | Who prepared, who reviewed, and when each occurred | A single initial with no date, which makes the timing of the review unverifiable |
Writing a conclusion that is actually a conclusion
This is the section most often rewritten on review, and the pattern of failure is consistent: the preparer describes the procedure again instead of stating what it established. A usable conclusion answers three questions.
- What does the evidence show about the assertion the procedure was designed to address?
- What did the exceptions change, in amount and in nature, and what remains uncorrected?
- Is the evidence sufficient and appropriate to support the conclusion, or is there a gap that has to be reported upwards?
A conclusion may legitimately be negative. “The population could not be agreed to the ledger and the testing therefore does not support a conclusion on completeness; referred to the manager” is a better working paper than one that reaches a clean conclusion the evidence does not carry.
A conclusion generated from a template, with the client's name substituted, is not the preparer's conclusion. It also reads unmistakably as a template to anyone reviewing a batch of papers, which invites scrutiny of everything else in the file.
Cross-referencing and the audit trail within the file
A working paper is rarely self-sufficient. It relies on a population established elsewhere, produces exceptions that appear on a summary, and contributes to a conclusion at the section level. Those relationships have to be navigable in both directions.
- 01Reference downwards to the evidenceEach figure in the paper should be traceable to the document it came from, named specifically: not “invoice” but the vendor, invoice number and where the document is held. A reviewer needs to know which document before deciding whether to open it.
- 02Reference upwards to the summaryEach exception should carry the reference of the line it occupies on the summary of misstatements or the schedule of control observations.
- 03Reference sideways to related proceduresWhere the same transaction is tested in two sections, for example a purchase invoice examined in both purchase testing and input credit work, cross-reference rather than duplicating the evidence and risk reaching two different conclusions on it.
- 04Make the references resolveA reference to a schedule that does not exist, or that was renumbered after the paper was written, is worse than no reference. Check them at the point the file is assembled.
How files are indexed
Indexing is a firm convention rather than a requirement, and consistency matters more than the particular scheme. A lettered section per area, with numbered papers within it, is the most common arrangement in Indian practice.
| Section | Contains |
|---|---|
| Permanent | Constitution documents, shareholding, prior-year signed accounts, significant contracts, related-party list |
| Planning | Engagement letter, independence, risk assessment, materiality, the audit programme, team discussion |
| Completion | Summary of misstatements, going concern, subsequent events, representation letter, review notes and their clearance, the signed report |
| Balance sheet sections | One lettered section per area, each with a lead schedule agreeing to the trial balance and the papers behind it |
| Profit and loss sections | The same arrangement for income and expense areas |
Common practice, not a requirement
Lettered sections, tickmark legends and lead schedules are longstanding practice, not statutory requirements. What is required is that the documentation meets the experienced-auditor test. A firm with an idiosyncratic but consistent and navigable scheme complies; a firm with a conventional scheme applied inconsistently may not.
Electronic working papers
Most of the above is medium-independent, but three things change when papers are held electronically and are worth deciding deliberately rather than by default.
- Sign-off has to be attributable to a person, not to a shared login. A paper approved from an account three people use cannot evidence who reviewed it.
- Changes after review must be visible. A system that allows a conclusion to be edited silently after approval cannot support documentation requirements, because the file no longer shows what was approved.
- The evidence has to stay attached. A paper linking to a document in a folder that is later reorganised loses its evidence, and the loss is invisible until someone tries to follow the link.
How we think about this
Lekhya assembles working papers as the testing runs, so the population, the sample basis, the procedures and the exception schedule are already in the paper by the time an auditor opens it. What it does not do is write the conclusion. A paper cannot be approved without a written conclusion from a named person, and changing the content after review withdraws the approval rather than quietly keeping it. The paperwork is repetitive; the conclusion is the audit.
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
- Audit documentationSA 230: what actually has to be in the fileThe experienced-auditor test explained in plain terms, what documentation has to demonstrate, when the file has to be assembled, and the gaps that most often draw comment on review.
- Audit documentationAudit evidence: what makes it sufficient, appropriate and traceableSufficiency and appropriateness without the textbook circularity, a reliability hierarchy for Indian practice, and what has to be recorded for evidence to be traceable.
- Audit documentationReviewing and signing off audit working papersWhat a reviewer is responsible for, a defensible review order, writing points that get cleared properly, and why approval must lapse when the paper changes.
- Audit documentationAn audit documentation checklist for statutory auditsA checklist organised by when the work happens: planning, fieldwork, each paper, completion and assembly, with the deadlines that govern the last two.
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.