Audit trail in an accounting system: how to build a record that cannot be changed

An audit trail answers three questions: what happened, who did it and why the ledger looks the way it does. If any answer can be changed afterwards, the trail stops being evidence. Below are the rules we use in Zaksio that work in any accounting system.

Rule 1: an append-only ledger

• A ledger entry is neither edited nor deleted. A mistake is corrected with a reversing entry (storno) and a new entry, so both operations stay visible.
• The rule is enforced in the database, not only in the application: an attempt to change or delete ends in an error even for the database owner.
• The balance (total debits equal total credits) is checked on every entry, so the ledger cannot enter an unbalanced state.

Rule 2: periods with closing

After a month is closed, posting to that period requires a deliberate unlock that itself leaves a trail. This way a return filed on the basis of a closed period does not change silently.

Rule 3: an event log next to the ledger

• Every data change has an entry: who, what, when and the values before and after.
• The log is also append-only.
• Actions of the AI team are in the same log, with a note that an agent proposed them and a person approved them.

Rule 4: visibility depends on the role

The log contains sensitive data, so not everyone should see everything. In Zaksio an accountant sees finance and payroll, an HR specialist sees HR and payroll, and sales and warehouse staff see only their own area. Values before and after a change in HR data are visible only to the owner and the HR specialist; other roles see that a change happened and which fields it concerned.

Rule 5: the vendor staff's actions leave a trail too

A good trail also covers the software vendor's staff. Every administrative action requires a reason, and support entering on behalf of a user is time-limited, marked with a visible banner and recorded in both the platform log and the company's log.