An LLM is safe to use for drafting audit narrative when its output is restricted to organising, phrasing, and summarising facts and conclusions the auditor has already established — and unsafe the moment its output is the thing establishing a fact, a risk assessment, or a conclusion that the file then treats as settled.
The test: did the model decide something, or phrase something
The useful question for any specific drafting task is not 'is this AI-generated' but 'did the auditor already know the content of this sentence before the model wrote it.' If the auditor supplies the facts and the conclusion, and the model turns bullet points into prose, nothing in the audit's substance has moved. If the model is asked to assess a risk, suggest a sample size, or characterise a control as effective, the model has made a judgement call that the file will now carry as if a person made it.
Safe to delegate
- Turning a reviewer's shorthand notes into full working-paper prose, where every fact in the output was already in the notes.
- Summarising a long client-provided document into a shorter internal note, provided the summary is checked against the source for the specific figures mentioned.
- Standardising language and structure across similar working papers so they read consistently across an engagement team.
- Drafting the first pass of a management letter point once the finding and its basis are already fully specified by the auditor.
Not safe to delegate
- Risk assessment language that states a conclusion the engagement team has not actually reached and documented separately.
- Characterising a control as operating effectively based on a model's reading of a process description rather than actual testing.
- Drafting a going concern or key audit matter narrative from scratch, since the judgement embedded in the framing is the substance of the matter.
- Any narrative that will be read later as evidence the auditor performed a specific procedure, when the model's phrasing implies more was done than actually was.
The most common failure isn't a factual error — it's a model's confident, well-organised prose making a thin procedure look thorough on the page. A reviewer reading fluent narrative is less likely to ask what was actually done behind it.
A workable rule for engagement teams
- 01Specify facts and conclusions before drafting, not duringThe auditor writes down what was found and what it means in plain notes first. The model's job is to turn those notes into file-ready prose, not to fill in what the notes left out.
- 02Keep a visible marker on AI-assisted sections during reviewA reviewer who knows which paragraphs were drafted with AI assistance can give those a closer read against the underlying notes, rather than treating all narrative equally.
- 03Never let drafted language upgrade the apparent strength of a procedureIf the actual testing was limited, the narrative describing it should read as limited too, regardless of how comprehensive the model's phrasing makes it sound.
How we think about this
Lekhya treats drafting assistance as a tool for turning an auditor's own established facts into clean prose — never as a source of the facts or conclusions themselves. Anything the model didn't receive as input, it doesn't get to decide.
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
- Technology, data & AI in auditAI in audit: the risks and limitations auditors should knowHallucination on numeric tasks, where client data actually goes when it reaches a model, and why junior staff over-relying on fluent output is the risk firms underrate most.
- Audit workflow & automationAI in audit: what it is good at, and what it must not touchThe three tasks language models genuinely do well in audit, the three they must never be given, and the questions to ask a vendor before any client data moves.
- 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.
- 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.
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.