Two distinct audit trails matter on a Companies Act engagement. The first is the client's: for financial years commencing on or after 1 April 2023, a company using accounting software to maintain its books must use software that records an audit trail of each transaction and an edit log of changes, and the auditor has a separate obligation to report on it. The second is the audit team's own: the record of who prepared, changed, reviewed and approved each working paper. The first is a statutory reporting matter, the second is what makes the file defensible, and they are frequently confused.
The client's audit trail
Regulatory requirement
The proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014 requires that, for financial years commencing on or after 1 April 2023, every company using accounting software for maintaining its books of account uses software having a feature of recording an audit trail of each and every transaction, creating an edit log of each change made in the books along with the date when such changes were made, and ensuring that the audit trail cannot be disabled. Rule 11(g) of the Companies (Audit and Auditors) Rules, 2014 places a separate obligation on the auditor to report on this. Read the current text of both, and the ICAI's implementation guidance, before concluding.
The structure is a maker and checker arrangement. Management is responsible for using compliant software and operating it throughout the year. The auditor is responsible for forming and reporting a view on whether that happened. Those are different questions, and the auditor's report is not a certification that the software is adequate in general.
What to test
- 01Establish what software maintains the booksNot just the accounting package. Sub-ledgers, payroll systems, billing systems and spreadsheets that feed the books all form part of the answer, and clients routinely name only the main package.
- 02Establish whether the feature exists and is enabledExistence and operation are separate. A package capable of recording an edit log, with the log switched off, does not satisfy the requirement.
- 03Test that it operated throughout the year, not at a point in timeA feature enabled in January tells you nothing about April to December. Look for evidence across the period, including any gaps arising from an upgrade, a migration or a change of package.
- 04Test that it cannot be disabledExamine who holds the privilege that would allow it, and whether the exercise of that privilege would itself be logged. Where the client's administrator or the vendor can switch it off without trace, that is a finding.
- 05Consider whether the trail was preservedThe reporting obligation extends to preservation in accordance with the applicable statutory requirements for retention. A log that exists but is purged after ninety days raises a separate question from one that was never enabled.
- 06Where books are maintained by a service provider, address that tooOutsourced accounting does not remove the requirement, and the evidence usually has to come from the service organisation rather than from the client.
The most common weakness found in practice is not an absent feature. It is a privileged account, often shared, that can alter data or the log itself, with no record of who used it. A trail that a small number of people can edit is evidence about everyone except the people most able to cause a problem.
What the reporting looks like
The report states what was found, and where the requirement was not met in some respect, says so specifically rather than generally. The ICAI has issued implementation guidance on the form of reporting in various scenarios, and it is worth reading rather than adapting last year's wording.
| Situation | Consider |
|---|---|
| Feature exists, enabled all year, cannot be disabled, preserved | The straightforward case. Document the evidence for each of the four elements rather than asserting the conclusion. |
| Feature enabled part-way through the year | The period before it was enabled, what evidence exists for that period, and how the report describes the gap. |
| Feature exists at the application layer but data is editable at the database layer | Whether the trail can in substance be disabled or circumvented, and who holds that access. |
| Books maintained by a service provider | What evidence is available about the provider's systems, and whether a report from the provider's auditor exists. |
| Some sub-ledgers compliant, others not | Which records form the books of account, and whether the non-compliant systems are among them. |
| Log retained for a shorter period than required | Preservation specifically, which is a separate element of the reporting from existence and operation. |
The audit team's own trail
Nothing in the Companies Act governs this one. It is driven by the documentation standard and by the practical need for the file to show what was approved and by whom.
SA 230 permits documentation to be changed after the audit report date, but requires the record to show what was changed, by whom, when and why, and prohibits deletion after the final file has been assembled. That is a description of an append-only record: entries can be added, nothing can be removed, and a correction is a new entry rather than an edit to an old one.
- Who prepared each paper, and when it was completed rather than when the file was created.
- Who reviewed it, when, and what they raised.
- How each review point was cleared, by whom, and what changed as a result.
- Every change to content after review, with the reason, and its effect on any approval already given.
- Who signed off, at what version, and whether that sign-off still stands.
Common practice, not a requirement
Many firms record review as a single initial on the face of the paper. That is longstanding practice and it evidences that a review occurred, but it does not evidence what was questioned or how it was resolved. Retaining the review notes and their clearance is stronger and is increasingly what peer and regulatory reviewers look for.
Why approval has to be capable of being withdrawn
The property that makes a file trail useful is not that it records changes. It is that the record has consequences. If a conclusion can be rewritten after a partner approved the paper, and the approval simply remains attached, then the approval has become meaningless: it now attaches to text nobody approved.
A file trail that is doing its job shows the reviewer that an approval was given at a particular version, that the content has since changed, and that the paper therefore requires review again. That is a small design decision with a large effect, and it is the difference between a log and a control.
How we think about this
In Lekhya the trail is the record and it is never edited. Changing a conclusion or re-running a procedure on an approved paper withdraws the approval and says so, naming who had approved it and what revoked it, before the action is taken rather than after. Nothing about that is clever; it simply refuses to let the file assert a sign-off that no longer corresponds to anything.
Two trails, one question
Both trails exist to answer the same question from different sides: can someone who was not present establish what happened, in what order, and on whose authority. For the client's books that question is now partly a matter of statutory reporting. For the audit file it has always been the substance of what documentation is for.
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 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 documentationAudit working papers: what they should containThe anatomy of a paper that stands on its own: objective, population, sample basis, procedure, results, exceptions, conclusion and sign-off, and what each must establish.
- 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.