Language models are genuinely useful in audit for three things: reading documents and extracting fields, classifying documents and transactions into categories, and drafting narrative that a person then edits and owns. They should not be used for arithmetic, for forming conclusions, or for deciding what is material. The distinction is not about difficulty. It is that the first three produce output a person can verify against a source in seconds, and the last three produce output that looks equally plausible whether it is right or wrong.
The three things they do well
- 01ExtractionReading a supplier invoice and returning the vendor, GSTIN, invoice number, date, taxable value and tax. This is a reading task with a checkable answer: the extracted figure can be shown next to the page it came from, and a reviewer confirms it in a moment. Errors are visible, which is what makes the task safe.
- 02ClassificationDeciding that a document is a bank statement rather than a ledger, or that an expense description corresponds to a category. Useful because it routes work, and safe because the consequence of an error is that something goes to the wrong queue and is corrected, not that a figure is wrong.
- 03DraftingProducing a first version of a narrative description from structured facts, which a person then rewrites. The value is in avoiding a blank page. The danger is in the draft being accepted rather than rewritten, which is a process problem rather than a model one.
All three share the property that a person can check the output against a source quickly. That is the actual criterion, and it is more useful than any general statement about what models can or cannot do.
The three things they must not do
| Task | Why not | What to use instead |
|---|---|---|
| Arithmetic: totals, variances, reconciliations, ageing | A model may produce the right answer most of the time, and there is no way to tell which time this is. An error is silent and looks exactly like a correct answer. | Rule-based code. Deterministic, reproducible, and testable against known data. |
| Forming conclusions | A conclusion is what the signature attaches to. A generated conclusion records nobody's judgement, and it is fluent enough to pass casual review. | A named auditor writing it. Draft the surrounding narrative if useful; never the conclusion. |
| Deciding materiality or what to escalate | These depend on the entity's circumstances and on professional judgement that has to be attributable to a person. | The engagement team, with the basis recorded. |
Arithmetic is the clearest line and the one most often crossed, because asking a model to total a column is easy and the answer usually looks right. A calculation that is correct 97% of the time is not 97% useful in an audit file. It is unusable, because the 3% is indistinguishable from the rest and the file offers no way to find it.
Why confidence scores make things worse
A natural response to model error is to display a confidence figure. In practice this does more harm than good. The numbers are poorly calibrated, so an item marked 87% is not right 87 times in a hundred in any verifiable sense. Worse, a displayed percentage invites people to stop examining anything above an arbitrary threshold, which converts a presentational choice into an undocumented audit decision.
Coarse bands with stated reasons route work just as effectively. “Low confidence: the invoice number field was illegible” tells a person what to check. “62%” does not.
Confidentiality, and the questions to ask
Client data leaving the firm is a professional matter before it is a technical one. A chartered accountant is bound by confidentiality obligations under the ICAI Code of Ethics, and those obligations do not change because the recipient is a software service.
Regulatory requirement
Confidentiality obligations under the ICAI Code of Ethics apply to client information regardless of the medium. Separately, the handling of personal data is governed by Indian data protection law, which has been undergoing change. Establish the current position and take advice before client data is sent to any external service, including a general-purpose AI tool.
- Is client data used to train the provider's models, or the models of any sub-processor? A negative answer needs to be contractual, not a statement on a marketing page.
- Where is the data processed and stored, and does it leave India? If residency is claimed, is it architecturally true or a policy that could change?
- How long is data retained after an engagement ends, and can it be deleted on request?
- Which sub-processors have access, and are they named? A model provider behind a product is a sub-processor whether or not the contract calls it one.
- Is access scoped to the engagement, so that staff cannot see clients they are not working on?
- What happens to prompts and outputs? These can contain as much client information as the source documents.
- Is there a record of what the system did, attributable to a person, and can it be exported?
Pasting a client's trial balance into a general-purpose consumer chat tool is a disclosure of confidential client information to a third party. It is the single most common way this goes wrong in small and mid-sized practices, and it usually happens without anyone considering it a decision at all. A firm position on this is worth writing down before it is needed.
What has to be in the file
Where a model contributed to audit work, the documentation requirements do not relax. Four things need to be evident.
- What the model was used for, specifically. Extraction from a stated document type is a description; “AI-assisted review” is not.
- What a person did with the output. Extracted figures reviewed against the source, drafted text rewritten, classifications confirmed.
- Who that person was, and when.
- That every figure remains traceable to the document and page it came from, so the extraction can be checked rather than trusted.
A position a firm can defend
The version that holds up is narrow and specific. Models read documents and draft prose. Rules compute numbers. People decide what things mean and sign their names to it. A firm that can state that in a sentence, and point to how its tools enforce it, is in a considerably better position than one relying on staff discretion.
How we think about this
Lekhya uses a model to read documents and draft narrative, and nothing else. Matching, footing, variance and reconciliation are computed by rule-based code, because those must give the same answer every time. No confidence percentage is displayed anywhere. Every piece of content is marked as computed, drafted or auditor-written, so a reader always knows what produced what. The governing sentence is that software performs the repetitive audit work and auditors remain in control of professional judgment, and the product is built so it cannot quietly become something else.
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 workflow & automationAutomating repetitive audit procedures without automating judgmentWhere the boundary between mechanical work and judgment falls, a test for deciding which side a task is on, and how to keep the boundary from eroding.
- Audit workflow & automationAudit automation for CA firms: what to automate firstHow to decide what to automate, ranked by return rather than by how impressive it sounds, with a scored ranking of common audit tasks and what to leave alone.
- 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.
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.