What an audit trail is for
Three different readers use the same record, and designing for only one of them is how trails end up incomplete.
The auditor is testing whether the control operated as described. They do not usually care about a single expense; they care that the same rule produced the same outcome across a sample. That means the trail has to make the rule visible, not just the decision.
The tax authority is testing substantiation. Their question is about the individual item: what was it, when, where, for what business purpose, and is there a document. IRS Publication 463 puts this directly — records must prove the time, place and business purpose of travel, and an accountable plan additionally requires employees to account adequately to the employer and to return any excess reimbursement. HMRC's requirements for employers reporting expenses and benefits work on the same principle with different mechanics.
Your own finance team, twelve months later, is answering "why does this number look like that?" Their need is the reconstructable narrative: the sequence, with the reasons attached.
A trail built only for the auditor tends to have excellent approval metadata and no receipts. One built only for tax tends to have receipts and no record of who decided what. The field list below is the union.
The field-level record
| Field | Captured when | Why it is asked for |
|---|---|---|
| Submitter identity | Submission | Establishes who incurred the cost |
| Original amount and ISO 4217 currency | Submission | The claim before anyone's arithmetic |
| Transaction date | Submission | Distinct from the submission date; drives rate and period |
| Business purpose | Submission | The substantiation requirement most often left blank |
| Category, entity, cost center | Submission | Determines whose books carry it and under which policy |
| Attached evidence and its hash or version | Submission | A receipt that can be silently replaced is not evidence |
| Exchange rate, source and date taken | Submission | All three, or none of it is defensible |
| Policy rule evaluated and its outcome | Submission | Makes the control testable across a sample, not just per item |
| Approver identity and timestamp | Approval | Who accepted it, and when |
| Approval route and the rule that produced it | Approval | Answers "why this approver?" — the question routing logs usually cannot |
| Delegation record, if any | Approval | Delegate, delegator, start, end |
| Any field changed after submission: old value, new value, actor, reason | Any edit | The single highest-value entry in the trail |
| Rejection or send-back with reason | Any | A claim's history includes the times it did not pass |
| Payment date, amount, and destination account reference | Payment | Closes the loop |
| Accounting export or sync reference | Export | Ties the operational record to the ledger |
Two rows carry more weight than the rest. The policy rule evaluated and its outcome is what turns a pile of individual approvals into a testable control — without it, an auditor sampling twenty expenses can confirm twenty decisions and nothing about the rule. And the change record is the one that converts a trail from a set of final values into a history; a field that was edited without a trace is a field an auditor has to treat as unreliable, including on every other claim.
Immutable versus correctable
Not everything in a trail should be frozen, and freezing the wrong things creates its own problems.
Freeze the events. Submitted, approved, rejected, delegated, paid, exported. These are facts about what happened at a point in time. They are append-only: a mistake is corrected by a new event, not by editing the old one.
Allow correction, with a record, on the descriptive fields. Category, cost center, business purpose, entity. These are frequently wrong on first submission and correcting them is normal bookkeeping. What matters is that the correction is itself an event: old value, new value, who, when, why.
Never allow silent replacement of evidence. A receipt image swapped after approval, with no version history, undermines every claim in the system rather than just that one. Version the attachment or store a hash alongside it.
The design failure to avoid is a system where everything is editable and only the current state is stored. It looks tidy and it is worth very little: at audit, the answer to "was this always the category?" is "we don't know", and the auditor's next question is about your whole population rather than your sample.
How long to keep it
Retention is where most teams have a policy that does not match what they actually do.
The general shape: tax authorities set a minimum retention period for records supporting a return, and it varies by jurisdiction and by circumstance — with longer periods where a return was not filed or was materially understated. Corporate and employment law add their own periods, as do sector regulators. A group operating in several countries is subject to the longest applicable period for each record, not to an average.
Three practical rules save more trouble than a precise table would:
- Retain the trail and the evidence together. An approval history that outlives its receipts, or receipts whose approval context has been purged, are each half of an answer.
- Set retention by the entity that carries the cost, not by the employee's location. Entity ownership is what determines which jurisdiction's rules apply.
- Decide before you need to. Deletion is a decision either way — a team with no retention policy is keeping everything indefinitely, which is a data-protection position they have not consciously taken.
Because the specifics differ so much by jurisdiction, this is a case for confirming the applicable periods with an adviser rather than adopting a number from a guide.
The five gaps auditors find most often
Business purpose left blank or generic. "Client meeting" on eighty claims is not a business purpose; it is a default value. This is the most common substantiation gap and the easiest to fix, because it is a required-field decision.
No record of why this approver. The trail shows an approval and gives no way to tell whether it was the right person. Capturing the rule that produced the route is what turns approval metadata into control evidence.
Edits with no history. Fields that changed after submission, with only the final value stored. Once identified, this usually widens the scope of the audit rather than being a single finding.
Rate without provenance. A converted amount and a rate, but no source and no date the rate was taken. See foreign currency expenses for what the complete version looks like.
Approvals during absence with no delegation record. Approvals that appear under a name while that person was demonstrably away. Sometimes this is an undocumented delegation and sometimes it is a shared credential; the trail cannot distinguish them, which is precisely the problem. Segregation of duties in expenses covers the control.
None of these is exotic, and all five are visible in a sample of twenty expenses pulled at random. That makes a self-review cheap: pull the sample, check the five, and you know where you stand before anyone else does.
Making the trail a by-product, not a project
The reliable pattern is that the trail is produced by the workflow rather than assembled for the audit. Anything reconstructed after the fact is both expensive and weaker evidence, because it was compiled by someone with an interest in the answer.
That means capturing at the moment of the decision: the rule at evaluation time, the approver at approval time, the rate at submission time. Each of those is trivially available at the moment it happens and progressively harder to establish afterwards. A workflow that records them as it goes has an audit trail without anyone doing audit-trail work; one that stores only outcomes creates a research project every time a question is asked.
The corollary is that the trail should be readable by a person, not only queryable by an engineer. If answering an auditor’s question requires a database export and someone who knows the schema, the trail exists but is not usable, and in practice it will be reconstructed by hand anyway.
How Clara records the expense trail
Clara captures the trail as the expense moves rather than as a separate logging step. The original amount and currency are recorded as submitted; the exchange rate is locked at the moment the employee submits, so the rate on the record is the rate that governed the decision rather than one recalculated later; approvals are recorded with the approver and the routing that produced them.
At the finance end, the output is a payment-ready report — expenses grouped by currency and by the bank account each needs to be paid from, with the FX breakdown included — which means the payment record and the approval record describe the same set of expenses. Clara does not execute the transfers; the report is built for a finance team to act on through their existing banking platform.
The approval rules that decide this routing are configured per company and evaluated on the expense itself, so the same record is produced for an employee in any country submitting in any currency.
What a system cannot do is decide your retention periods, your policy, or what your auditor will accept. Those stay with your finance and legal teams. The contribution is that the facts they need are captured when they occur rather than reconstructed when they are asked for.