MCA audit trail, 3 years on: when an agent posts the entry

What the rule says

The Companies (Accounts) Amendment Rules, 2021  (opens mca.gov.in, external site) added a proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014. A company that keeps its books of account in accounting software must use software that records an audit trail of every transaction, creates an edit log of each change with the date it was made, and does not allow the audit trail to be disabled. After two deferrals, the requirement applied from 1 April 2023, the first day of financial year 2023–24.

Auditors report on it. Rule 11(g) of the Companies (Audit and Auditors) Rules, 2014 asks whether the software had the feature, whether it operated throughout the year for all relevant transactions, whether it was tampered with, and whether the trail has been preserved as the law on record retention requires. Section 128(5) of the Companies Act, 2013  (opens indiacode.nic.in, external site) sets that period at not less than 8 financial years.

Three audit cycles later

Financial year 2025–26 is the third year audited under the rule. Most companies have upgraded their software and switched the feature on. The harder questions auditors now ask are about coverage: did the trail run for every ledger and every change, including changes made outside the screens a person uses?

That is where agents come in. An agent that posts a journal, books a purchase bill or amends an invoice usually does it through an integration account or an API. The software logs the change against that account. The edit log is complete, but the name in it is a machine's.

What changes when an agent posts the entry

1. 01Shared integration users blur the trail. If five agents and a nightly import all post as api-user, the log cannot say which of them made a change.
2. 02Direct database writes can bypass it. An agent given database access instead of an application interface may change the books without the software's audit trail ever seeing the edit.
3. 03The log records the change, not the authority. It shows that an entry was altered on a date. It does not show which rule allowed the agent to do it, or which person approved it.

None of this is a breach of the rule by itself. All of it makes the auditor's Rule 11(g) work harder, and all of it weakens the answer to the question a board will eventually ask: who was responsible for this entry?

Designing for the auditor

A few choices keep an agent's edits as clear as a person's:

• Give each agent its own identity in the accounting software, never a shared integration user, so the edit log names the agent that made each change.
• Let agents change the books only through the software's own interfaces, so every edit passes through the audit trail. Refuse direct database access.
• Link each edit to a record of its authority: the rule that allowed it, or the named person who approved it, and when.
• Keep that record for as long as the books themselves, at least 8 financial years, and test that it can be read back.

Where elan1 fits

elan1 Govern is designed to sit between an agent and the accounting system. The agent proposes a change; Govern allows it, asks a person you name, or refuses it; only then does the change reach your software, through its own interface, so the software's audit trail records it. Govern's own record adds what the edit log cannot: the agent's identity, the rule, the approver and the outcome, in a form your auditor can check offline.

For ERP changes rather than entries, elan1 Work is designed to check that a change keeps the audit trail intact before anyone approves it. The two records sit side by side. They do not replace the software's audit trail, and nothing in this brief suggests the rule can be met any other way.