There are two fundamentally different things a working paper template can fix, and only one of them is safe. Fixing structure means every working paper for a procedure has the same named sections in the same order — Scope, Population Tested, Exceptions, Conclusion — with every section left genuinely blank until the engagement team fills it in. Fixing conclusions means the template arrives with default text already sitting in those sections — most dangerously, a 'Conclusion' section pre-populated with something like 'No exceptions noted' that the preparer has to actively delete rather than actively write. The first kind standardises the shape of the file. The second kind manufactures the appearance of a decision nobody made.
Why the second kind is worse than having no template at all
A blank section is an honest gap — anyone reviewing the file sees it's empty and knows nothing was recorded there yet. A pre-filled default that happens to be correct on this particular file looks exactly the same as a default that's wrong and was simply never overwritten, because the text in both cases is identical. There's no way, just by reading the finished working paper, to tell which one you're looking at. A preparer under time pressure at season-end, moving fast through a batch of similar files, is exactly the person most likely to leave a wrong default standing rather than the person most likely to have carefully verified it was right.
A 'Conclusion' section that defaults to 'no exceptions noted' is the single most common version of this trap, because it's also the most common correct answer — most testing in most periods does find no exceptions. That's exactly what makes a wrong instance invisible. The file reads as if a judgement was reached, when what actually happened is that nobody touched the field.
A test for telling the two apart
| Structure-fixing template | Conclusion-fixing template |
|---|---|
| Every section exists, named, in a fixed order | Every section exists, named, in a fixed order |
| Every section starts empty | Some sections start with text already in them |
| A blank section is visibly blank | A blank-equivalent section looks identical to a completed one |
| Review has to ask 'did they fill this in', which is answerable by looking | Review has to ask 'did they actually mean this', which isn't answerable by looking |
Where this distinction gets blurred in practice
It rarely arrives as an obvious shortcut. It usually shows up as a well-intentioned efficiency feature: a template that pre-fills the standard wording for a routine procedure to 'save the preparer typing it out every time'. The wording might even be accurate boilerplate for the scope or methodology sections, where it genuinely doesn't vary engagement to engagement. The danger is specifically in sections that are supposed to record a judgement reached about this client, this period, this population — Exceptions and Conclusion above all. Boilerplate in a scope section is a convenience. The same habit in a conclusion section is a liability.
- Safe to standardise: section names, section order, cross-reference format, which sections are mandatory for a procedure
- Safe to pre-fill, cautiously: a methodology description that genuinely doesn't change engagement to engagement
- Never safe to pre-fill: any field recording what was found, what was concluded, or whether exceptions exist
Regulatory requirement
SA 230 requires documentation of the conclusions reached and the significant judgements made in reaching them. A conclusion that exists in a file only because a default was never deleted was never actually reached by anyone — it fails the standard's intent even though the field, viewed on screen, looks filled in.
The test to apply to any template, including a firm's own
Open a fresh, unused instance of each working paper template the firm uses. Every field that is supposed to record this engagement's specific findings should be completely empty — not 'TBD', not a placeholder, not a plausible-sounding default. If any field a preparer is meant to actively reason through already has text sitting in it before they've done any work, that template fixes a conclusion, not a structure, and it should be corrected regardless of how convenient the pre-filled text happens to be.
How we think about this
Lekhya's templates only ever fix the named sections and their order. No section is pre-populated with sample wording, a default conclusion, or placeholder text of any kind — every section is genuinely blank until the engagement team writes into it based on the work they actually performed on that 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
- Audit documentationCustom working paper templates: standardising a firm's own format, not inventing a new oneA reviewer should be able to open any engagement's working papers and know where to look. That only happens if the format was decided once, not reinvented per file.
- Technology, data & AI in auditAI hallucination risk in audit working papersA hallucinated figure in a working paper reads exactly like a correct one. The only defence is knowing where a model could have touched the file and checking that spot deliberately.
- 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 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.
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.