Audit Trails for AI Drafts: Who, What, When — and Why

Sooner or later, someone official asks a question about your books. An HMRC enquiry wants to know why £640 sits in repairs and maintenance. An external accountant reviewing the year wants to understand how a supplier credit was treated. A lender's due diligence asks whether the management figures can be relied on. In every case the real question underneath is the same: can you show how this entry came to exist?

When software drafts your entries, that question gains a sharper edge. "The AI put it there" is not an answer anyone — HMRC, an auditor, or you — should accept. This article describes what our platform records for every entry, and why the record is designed the way it is.

What gets recorded

For each entry in your ledger, the trail holds the full chain from evidence to posting:

• The source document, as it arrived. The original PDF, photo, or bank line is retained and linked to the entry. Not a re-rendering — the artefact itself, from whichever channel carried it: upload, email connection, browser extension, or messaging.
• The draft as the AI proposed it. The extraction output and the double-entry transaction the model suggested, exactly as suggested, before anyone touched it.
• The confidence score. The model's own estimate at drafting time, preserved permanently rather than overwritten by later events.
• The validation result. That the draft passed AgentLedger's invariant checks — balanced postings, known accounts, sane dates — and, for drafts that failed first, the rejection reasons along the way.
• Every edit, with its editor. If a reviewer corrected the draft — changed the account, split the amount, fixed a date — each change is recorded with who made it and when. The proposed version and the approved version are both kept, so the difference between them is visible.
• The decision. Who approved the entry and when; or, where an account runs in an agreed automatic mode, exactly which policy version, confidence threshold, and materiality limit permitted the posting.
• Queries and their answers. If the entry was questioned — "is this the Harrogate job or general kit?" — the question, the answer, and who gave it stay attached to the entry.
• Duplicate decisions. If the entry was ever flagged as a possible duplicate, the trail shows what it was matched against and the human decision that resolved it.

Why keep the draft when it was wrong?

It might seem tidier to store only the final, corrected entry. We deliberately do the opposite, and the reason goes to the heart of supervising AI honestly.

The difference between what the model proposed and what a person approved is the evidence that review actually happened. A system that discards drafts after correction can claim anything about its human oversight; a system that preserves them can prove it, entry by entry. The same record keeps everyone honest in the other direction too: it shows where the AI is systematically weak — which accounts attract corrections, which document types produce shaky extractions — and that evidence is what keeps review policies grounded in fact rather than optimism.

There is also a quieter benefit. When you ask "why was this categorised as materials?", your accountant does not reconstruct from memory. The entry itself answers: here is the receipt, here is what the AI read, here is the score, here is who confirmed it, here is the note from when you were asked.

Defending automation decisions

The hardest audit question for any automated system is not about the entries a person approved — it is about the ones no person looked at before posting. If some of your accounts run in automatic mode, what happens when an auditor picks one of those entries?

Our answer is that automation is never anonymous. An auto-posted entry's trail shows the policy in force at that moment: the account's agreed mode, the confidence threshold, the materiality limit, and the score that cleared them. Policies themselves are versioned, and changes to them are logged human decisions. So the honest narrative for any auto-posted entry is specific: "This account runs in automatic mode under a policy the client agreed, for entries below £X with confidence above Y; this entry scored Z; here is the source document; and here is the human who set that policy." That is an explainable decision with named accountability — categorically different from "the software handles the small stuff".

It is worth saying plainly: UK record-keeping obligations rest on the business. HMRC's guidance on records for the self-employed and for limited companies sets out what must be kept and for how long, and no software design changes who is responsible. What a good trail changes is how answerable you are when asked.

The design principle underneath

Every element above follows one rule: decisions must be reconstructable without trusting anyone's memory — including ours. The ledger is plain text, so its history is a sequence of legible states. Drafts, scores, edits, approvals, and policies are recorded at the moment they happen, not summarised afterwards. AI drafts. AgentLedger validates. People approve — and the trail is what makes each of those three claims checkable years later, entry by entry, by someone with no goodwill towards us at all.

That is the standard an audit trail should meet in the AI era: not a log that says the system ran, but a record that lets a sceptic re-derive why every number is there.

Check eligibility / Ask for Details