What an audit trail actually has to contain

Every accounting system has something it calls an audit trail. Open it and you usually find rows like alexander changed Account from 6200 to 6410 at 14:32.

That is a change log. It tells you a hand moved, not why it moved, and the gap between those two things is where a close goes wrong at two in the morning.

The test

An audit trail works if a reader who was not there can answer one question about any number in the financial statements: why is it this and not something else? Without asking anyone. Without institutional memory. Six months later, when the person who made the entry has left.

Almost every trail fails that test, and it fails in a consistent way. The record captures the mutation and drops the justification.

Four things the record has to hold

The prior state. Not just what it became — what it was. A row that says an account changed to 6410 is unusable without the 6200 beside it, because the interesting question is always what was rejected.

The actor, with their kind. A person, a rule, or an agent. These are not the same and collapsing them is how automated entries acquire the credibility of considered ones. When something proposes a hundred entries an hour, “who” has to distinguish the hundred from the one a controller typed deliberately.

The evidence. The document, attached to the posting itself rather than sitting near the transaction. A receipt in a folder that happens to share a date with a journal entry is not evidence; it is a coincidence a reader has to take on faith. The link has to be a real reference, and it has to survive the entry being corrected.

The reason, in the actor’s words. One line. Not a category from a dropdown — the actual reason. This is the field everyone omits because it cannot be generated, and it is the one that makes the other three legible.

Why immutability matters more than it sounds

A trail that can be edited is a document, not a record. If a correction rewrites history rather than appending to it, then the trail tells you what someone currently believes happened, which is exactly the thing you were trying to verify independently.

The practical form is append-only. A wrong entry is not fixed by editing it. It is reversed by a new entry that references the original, and both stay visible. The chain gets longer and slightly uglier and stays true, and the ugliness is the point — a clean history of a messy month is evidence of a system that forgets.

The part that actually breaks

Trails usually survive the entries. They break on the corrections.

An entry gets posted, someone spots an error, the entry gets unposted and edited and posted again. Three systems out of four will record that as one entry with a modification timestamp. What actually happened — a posting, a judgment that it was wrong, a specific change, and a re-approval — collapses into a single row with a recent date on it.

That collapse is not a logging bug. It is a design decision about what counts as an event, made once, early, by someone who was thinking about storage rather than about the person who would later have to explain the number.