The audit trail requirement is a control, not a software setting

Few provisions in Indian company law have changed audit reporting as much, in as few words, as this one. The requirement is a single proviso in the rules on keeping books of account. It took effect for financial years beginning on or after 1 April 2023, and most companies responded in the obvious way. They asked their software vendor whether the audit trail feature was on, received a reassuring answer, and moved on.

Three reporting cycles later, the conversation with auditors has become more demanding. The question is no longer whether a feature exists. It is whether the trail covers every change to the books, for the whole year, and whether it will still be readable when the law requires it to be produced.

What the rule asks, precisely

The proviso to rule 3(1) of the Companies (Accounts) Rules, 2014 requires every company that uses accounting software for its books to use software that can record an audit trail of each and every transaction, creating an edit log of each change made in the books together with the date of the change, and ensuring that the audit trail cannot be disabled.¹

The auditor’s side of the obligation is in rule 11(g) of the Companies (Audit and Auditors) Rules, 2014. The auditor reports whether the company used such software, whether the feature operated throughout the year for all relevant transactions, whether it was tampered with, and whether the audit trail has been preserved as the record-keeping requirements demand.² Books of account must be kept for at least eight years,³ and electronic books must be backed up daily on servers physically located in India.⁴

Read together, three phrases do most of the work: each and every transaction, throughout the year, and preserved. Each of them reaches further than a configuration setting.

Why the software setting is not enough

An edit log inside an application records what users do through that application. It does not necessarily record what happens to the data underneath, or to records kept somewhere else. A typical mid-market company keeps its accounting records across several layers, and coverage varies a great deal between them.

Illustrative assessment. Coverage depends on the specific systems, configuration, and access controls.

Source: Companies (Accounts) Rules, 2014, proviso to rule 3(1); Companies (Audit and Auditors) Rules, 2014, rule 11(g); SA&A analysis

Soni Aditya & Associates

The application layer is usually well covered once the feature is on. The difficulties lie elsewhere, and in almost every company we review they are the same ones.

The four gaps auditors now find

1. Database access. Administrators, and often the vendor’s support staff, can write directly to the production database. Changes made there bypass the application and its edit log entirely. Banning database access is rarely practical, because it is sometimes needed. The workable answer is to restrict it to named people, log it at database level, and review privileged activity on a fixed cycle.
2. A feature switched on late, or off for a while. The trail was activated after an upgrade in the second quarter, or disabled during a data migration and turned back on afterwards. Either way it did not operate throughout the year. The evidence that it did, meaning configuration history and system logs showing the feature active from day one, is often not collected until the auditor asks for it.
3. Spreadsheets doing the work of sub-ledgers. Fixed asset registers, provisions, credit loss calculations, and consolidation adjustments are kept in spreadsheets, and only summary entries reach the ledger. Views differ on how far such records fall within the requirement. The safer course is to move material calculations into systems with an audit trail, or to surround them with controls that produce equivalent evidence: locked versions, recorded reviews, and a reconciliation to what was posted.
4. Hosted systems. Where accounting or payroll runs on a provider’s platform, evidence of an unbroken trail depends on the provider. Independent service organisation reports covering the full period, together with the controls the company must operate itself, become part of the audit trail position.

An audit trail that covers the application but not the database records the front door and leaves the back door open.

Showing the trail worked for the whole year

The phrase “throughout the year” is where well-intentioned companies most often come unstuck. The evidence has to be gathered as the year goes on, because it cannot be reconstructed afterwards. One weekend of maintenance with the feature disabled creates a gap the auditor has to report, however carefully everything else was done.

Illustrative. The auditor reports whether the audit trail feature operated throughout the year for all relevant transactions and whether it was tampered with.

Source: Companies (Audit and Auditors) Rules, 2014, rule 11(g); SA&A analysis

Soni Aditya & Associates

The practical routine is simple. Capture the configuration at the start of the year and at every quarter end. Make any change to audit trail settings subject to formal change control, so that a migration plan has to state how the trail will be kept intact. Review privileged access every quarter, and keep the review signed and dated.

Preservation is the part nobody budgets for

Edit logs grow quickly, and some systems purge them after a retention period chosen for performance. A company that keeps its books for eight years and its edit logs for eighteen months has not preserved its audit trail.

Migration is harder still. A company that moves to a new ERP must still be able to produce the audit trail for the years it spent in the old one. Archiving the legacy database does not help if nobody can read the logs without the software that created them. The retention plan belongs in the migration contract, agreed before it is signed, not after the old licence has lapsed.

Building a defensible position

A position that meets the requirement, and that an auditor can report on without qualification, is put together from a small number of parts:

• A system inventory listing every system that creates or changes accounting records, with its audit trail capability, configuration status, and owner.
• A configuration evidence pack showing the feature was enabled and unchanged all year, captured at the start of the year and at each quarter end rather than rebuilt at year end.
• Privileged access controls over the database and administrator accounts, with logging and a documented periodic review.
• Interface controls for bulk uploads and integrations, including file-level logs, control totals, and a reconciliation of what was sent to what was posted.
• Service organisation reports for hosted systems, mapped to the controls the company has to run itself.
• A retention and backup record showing daily backup in India and logs kept for the full statutory period.

The trail as a forensic record

The audit trail is also the company’s own forensic record. When a payment is disputed, when a fraud is suspected, or when a regulator asks who changed a figure and when, the edit log is the one witness that neither forgets nor can be persuaded. Companies that build it properly usually find they have acquired a control they did not set out to build.

1. Companies (Accounts) Rules, 2014, proviso to rule 3(1), inserted by the Companies (Accounts) Amendment Rules, 2021, and applicable for financial years beginning on or after 1 April 2023.
2. Companies (Audit and Auditors) Rules, 2014, rule 11(g).
3. Companies Act, 2013, section 128(5).
4. Companies (Accounts) Rules, 2014, rule 3(5), as amended in August 2022.