Audit Trail
An audit trail is the chronological record of who did what, when, to which record, and with what values before and after. It is what makes a reported balance traceable to its source and what makes any process, human or automated, reviewable after the fact.
- Audit & Assurance
An audit trail is the record that lets someone reconstruct what happened after the fact. In an accounting system it is the chain that runs from a reported balance back through the postings that produced it, to the transactions behind those postings, to the source documents behind those transactions, together with the record of who touched each step and when.
A complete trail captures five things for every recorded action: the identity of the actor, a reliable timestamp, the action taken, the object acted on, and the values before and after. Anything less leaves a gap that has to be filled with testimony. A log that records that a balance changed but not who changed it, or that an approval occurred but not by whom, does not do the job.
Three properties determine whether the trail is worth anything. It has to be complete, covering every path by which data can change, including administrative overrides and direct database access, because a control that can be bypassed without a record is not a control. It has to be tamper-resistant, which in practice means append-only storage with restricted administrative rights, since a log that its subject can edit proves nothing. And it has to be retained and retrievable for as long as anyone might reasonably ask, across system migrations, which is where most trails quietly die.
In an internal control context, the audit trail is what makes controls testable rather than merely described. A reviewer can assert that entries are approved by someone other than the preparer, but the assertion is only evidence when the log shows the two identities and the sequence. For SOC 1 and SOC 2 reporting the trail is the direct evidence behind logical access, change management, and processing integrity criteria. In a forensic investigation it is usually the only evidence.
The reason this term now sits at the centre of software buying decisions is artificial intelligence. When an agent extracts a figure from a document, applies a rule, and posts an entry, the defensibility question is not whether the output looks right. It is whether the firm can show, months later and to a third party, what document the figure came from, what version of what logic was applied, what the system's confidence was, which human reviewed it, what they saw at the time, and what they approved. That is an audit trail requirement, and it is the same requirement that applies to a staff accountant. The difference is that a human preparer leaves a workpaper by habit and a system leaves one only if it was built to.
The practical standard to hold a vendor to is straightforward: every automated action should be reconstructable end to end without asking the vendor for help, exportable in a form the firm keeps, and durable beyond the life of the contract.
Related terms: Internal Control Over Financial Reporting, SOC 2 Report, Audit Workpapers, Journal Entry
Related reading: How to use AI in accounting
Go deeper: Accounting Automation
Every action an Adopt agent takes is recorded with its inputs, the logic applied, and the reviewer who approved it, exportable as a workpaper rather than locked in a vendor console. Sign up free.