Approval Audit Trail & Document Retention Sri Lanka | What to Keep

An approval is only a control if you can prove it happened. Designing audit trails and retention rules that survive staff turnover, system migrations, and an auditor picking one transaction at random.

By Manikya SearathnaAugust 29, 2026

Reviewing an immutable approval audit trail for a single transaction in Capricon Flow

Organisations invest in approval workflows to establish control, then discover during their first serious audit that the control cannot be demonstrated. The workflow worked; the record of it working was incomplete, editable, or partly deleted. From an auditor's position those outcomes are indistinguishable from no control at all.

The single-transaction test

A practical way to assess your own trail: let someone pick one transaction from two years ago and reconstruct it end to end—request, every approval and rejection, the document version at each step, and the final payment or issuance—without asking anyone what they remember. Most organisations fail this on the version question.

Log every state transition, not only final approval.
Bind each transition to a document version hash or identifier.
Store append-only, with no edit path for participants.
Retain per document type on a defined schedule.
Include the trail in any migration or decommissioning plan.

Delegation and the authority question

Trails frequently record who clicked approve but not whether that person held the authority at that moment. Since limits and delegations change, authority has to be captured as it was at the time of the action rather than looked up later from current settings—otherwise a perfectly valid historical approval can appear non-compliant, or vice versa.

This is a design decision made early or fixed expensively later. See multi-level approval workflow for how limits and delegation should be modelled.

Retention as configuration, not discipline

Any retention scheme depending on someone remembering not to delete things will fail. Attach periods to document types, enforce them in the system, and make disposal an automated, logged event rather than a manual cleanup. The log of what was disposed of and when is itself part of the evidence that retention policy was followed.

Frequently asked questions

What belongs in an approval audit trail?

Who acted, what action, on which document version, at what time, under what authority, and what the state was before and after. Rejections and returns matter as much as approvals—a trail showing only successes hides how a decision was actually reached.

Why must audit logs be immutable?

Because a log that can be edited proves nothing. If a record can be altered after the fact by anyone in the process, an auditor is entitled to treat the whole trail as unreliable. Append-only storage is what gives the log evidential value.

How long should approval records be retained?

Long enough to cover statutory, tax, and contractual obligations for the underlying transaction, which usually means years rather than months and varies by document type. The important part is that the period is defined per type and enforced automatically.

What happens to the trail during a system migration?

This is where most organisations lose it. History is treated as non-essential and left in the decommissioned system, which is then switched off. Retention obligations do not transfer with the data unless someone plans for it—migration scope should include the trail, not only current balances.