The Audit Trail: What Reconstructing One Transaction Actually Takes
An auditor does not ask whether your records are good. They pick one transaction and ask you to reconstruct it — who raised it, who approved it, what arrived, what was paid, and what changed along the way. That single request is the whole test.
There is a moment in every audit — statutory, donor, internal, or the informal one a bank runs before extending a facility — where the general questions stop and a specific one begins. The auditor points at a line and says: tell me about this one. Show me how it started, who agreed to it, what actually arrived, what you paid, and everything that changed between those events.
Businesses that pass do not pass because their records are tidier. They pass because that reconstruction takes eleven minutes and produces documents that agree with each other. Businesses that struggle spend two days assembling the same answer from four sources, and produce a version that is probably right and provably nothing.
This article is about the audit, not the log
If your question is what a good audit entry records, how to read one, and which queries to run monthly, that is the audit trail: who changed what, and when. This one is narrower and more specific: what it takes to satisfy somebody who has picked one of your transactions and asked you to rebuild it.
Reconstructability is the actual requirement
It is worth naming what an audit trail is for, because the word suggests a log file and the requirement is something else. The requirement is that any past transaction can be reassembled from records that were created at the time, by different people, without anyone reconstructing it from memory.
Which means an audit trail is not one thing. It is the combination of the documents themselves, the approvals attached to them, and the change history that explains any discrepancy between what was agreed and what happened. Miss any of the three and the reconstruction has a gap that has to be explained verbally — and a verbal explanation is exactly what an auditor is not able to accept.
| The auditor asks | What answers it | What happens when it is missing |
|---|---|---|
| Who wanted this and why? | A requisition, raised by a named person, with a stated need | The purchase appears to originate with whoever bought it |
| Who agreed to spend the money? | An approval recorded against the document, with time and identity | An email is produced, or a recollection — neither is evidence |
| What did you order? | A purchase order with quantities, prices and terms | The invoice becomes the only statement of what was agreed |
| What actually arrived? | A receipt recorded by someone other than the buyer | You paid for what the supplier says they sent |
| What did you pay? | A payment linked to the invoice and the receipt | Reconciliation becomes a matching exercise across systems |
| What changed, and who changed it? | A change history on the document | Any discrepancy is unexplainable, which reads as concealment |
| Who could have changed it? | The permission and role record at that time | Everyone could have, so nobody is accountable |
Notice that only the last two are what people normally mean by "audit trail". The first five are the ordinary documents of procurement, and the reason they matter here is that a change log over incomplete documents reconstructs nothing. The document chain is described in what a goods received note is and the control it anchors in segregation of duties.
A change log over incomplete documents reconstructs nothing. The audit trail is the documents, the approvals and the change history together — any two of the three leaves a gap you have to explain out loud.
The four failures that cost audits
In practice, reconstructions fail in a small number of recognisable ways, and none of them look like fraud. They look like ordinary operational shortcuts that were reasonable at the time.
- The retrospective document. The purchase order was raised after the goods arrived, so it matches the invoice exactly — which is precisely why it proves nothing. A perfect three-way match with identical timestamps is a red flag, not a clean result.
- The silent edit. A quantity or price was corrected without a record of the correction. The document is now right and the history is now wrong, and the auditor cannot tell which version anyone acted on.
- The verbal approval. Approved by the director on a phone call, entered by an assistant under their own login. The record says the assistant approved it, which is either false or means the assistant had approval authority.
- The deleted mistake. Somebody raised a document in error and deleted it. The sequence now has a hole, and explaining a hole is harder than explaining a cancellation.
Three of those four are solved by the same design decision: corrections are new records rather than edits to old ones. A cancelled purchase order that stays visible as cancelled costs nothing and explains itself. A deleted one requires a person to remember why, eighteen months later, in a meeting.
How long you have to be able to do this
This is where retention policy and audit readiness collide, and where a well-intentioned data protection decision can destroy the evidence you are required to hold. Kenyan tax record-keeping obligations run for years; donor agreements frequently specify their own period; and the Data Protection Act pushes in the opposite direction by requiring you not to keep personal data longer than the purpose needs.
Both are real, and they are not actually in conflict — but resolving them requires a deliberate decision rather than a default. If you set your audit log retention to a year because it felt tidy, you have made a business record shorter-lived than the period you are required to explain. If you keep everything forever, you have made a different promise you may not be able to justify.
The retention trap worth checking today
Look at your audit log retention setting and compare it to the longest period anyone can ask you to reconstruct — tax, donor agreement, statutory. If retention is shorter, you have configured evidence to expire before the obligation does. The default here is 730 days, which is a reasonable starting point and is not a legal opinion about your business.
What the audit trail records, and what it does not
What AWRA OpsHub does today
- An audit log capturing actor, action, module, route, HTTP method, URL, IP address, user agent, session and the affected record, with a free-text description and structured metadata.
- Authentication events logged, including failed attempts with the reason, so a pattern of attempts against one account is visible rather than invisible.
- Document vault access logged separately, because the sensitive files usually matter more than general activity and general logging is too coarse to answer questions about them.
- Support impersonation logged as its own event type, so any access by us on your behalf is distinguishable from your own staff's activity rather than blending into it.
- Identity in the log surviving erasure — an erased person's name is replaced but their recorded actions remain, so a data subject erasure does not create an audit gap.
- Configurable retention with scheduled enforcement, defaulting to 730 days for the audit log and 730 for document vault access.
- Deletions routed through a recoverable trash with lifecycle events and its own retention, so a deletion is a state with a history rather than an absence.
- Workflow and approval activity recorded against the documents they act on, so approvals are part of the record rather than a separate story.
What it does not do
- The audit log is not append-only at the storage layer. It is an ordinary table with no write path in the application for editing an entry, and the erasure routine deliberately rewrites actor names — so it is protected by design and access control, not by cryptographic immutability. If your assurance requirement is tamper-evidence rather than tamper-resistance, say so early, because that is a different guarantee.
- No field-level before-and-after history on every record. Structured metadata is captured where it is written, and modules differ in how much detail they record. Do not assume every changed field on every entity is diffable.
- No evidence pack export built for a specific auditor's format. You can export and report; producing a bundle shaped to a particular donor template is work you or we do rather than a button.
- No automatic anomaly detection over the audit log. Security signals are surfaced by category and severity, but nothing scores ordinary business activity for unusual patterns.
The first item is the one to raise with your auditor rather than with us. Plenty of assurance frameworks are satisfied by access-controlled logging with segregation of administration; some are not. Establishing which you are subject to is cheap now and expensive during fieldwork.
Questions worth asking any vendor about this
Four questions, and how to read the answers
Can somebody with administrator access edit or delete an audit log entry?
What you will hear
Either a straight no with an explanation of how, or a description of who can and what that leaves behind.
How to read it
A vendor who says "nobody can, ever" without describing the mechanism has not thought about their own database access. The honest answer usually involves access control rather than physics.
Show me the full history of one transaction that was corrected after approval.
What you will hear
A real record with a correction visible in it, not a clean example.
How to read it
Clean examples prove nothing. If they cannot produce a corrected one, corrections are probably silent edits, which is exactly the failure that costs audits.
What is the default retention on the audit log, and can I change it?
What you will hear
A specific number of days and where the setting lives.
How to read it
Vagueness here means either no retention enforcement — data accumulates forever — or a default nobody has examined. Both are decisions being made for you.
If we erase an employee under a data protection request, what happens to what they approved?
What you will hear
The approvals remain, the identity is anonymised.
How to read it
If erasure deletes the actions, they have traded one compliance problem for another. If erasure leaves the name intact, they have not erased anything. Both answers are common.
The habits that make an audit boring
-
Make the document sequence non-negotiable
Requisition before order, order before receipt, receipt before payment. Not because the sequence is sacred, but because a document created out of order carries no evidential weight and everyone can tell.
-
Separate the buyer from the receiver
The single highest-value control in the chain, and the one small teams abandon first. If the person who ordered also confirms what arrived, the receipt is an opinion.
-
Correct by adding, never by editing
Cancellations, credit notes and adjustments that stay visible. A visible cancellation explains itself; a deleted document requires a person and a memory.
-
Keep approvals inside the system
Every approval given on WhatsApp and typed in by someone else is a false record. If approvers will not log in, the fix is making approval take ten seconds on a phone, not accepting the proxy.
-
Set retention against your longest obligation
Deliberately, written down, with the reasoning and a date. Then confirm the scheduled enforcement is actually running, because a policy nothing executes is a document.
-
Rehearse the reconstruction once a quarter
Pick a transaction at random, reconstruct it end to end, and time yourself. Whatever you find is what an auditor would have found, discovered on your schedule instead of theirs.
The last habit is the one that changes outcomes, and it costs an hour. Everything an auditor will discover about your records is discoverable by you first, using the same method, with the enormous advantage that you can fix what you find. The related disciplines are in access control — since a log is only as specific as its identities — and data protection duties, where the same access record answers a different regulator's question.
Our take
Judge your records by one test: pick a transaction from eight months ago and reconstruct it without asking anyone what happened. If that takes minutes and the documents agree, you are audit-ready regardless of how your filing looks. If it takes days, no amount of tidying will help, because the problem is that the evidence was never created at the time. Make corrections additive, keep approvals in the system, separate the buyer from the receiver, and set retention against your longest obligation rather than your tidiest instinct.
See what the audit log actually captures
Actor, action, module, route, IP, session and affected record — with document vault access and support impersonation logged separately, and configurable retention that is actually enforced.
Explore audit & evidenceFrequently asked questions
What is the difference between an audit log and an audit trail?
The log is the record of who did what, when and from where. The trail is the whole reconstruction: the documents themselves, the approvals attached to them, and the change history that explains any difference between what was agreed and what happened. The distinction matters because a change log over incomplete documents reconstructs nothing — if there was never a requisition or a goods received note, no amount of logging will tell an auditor who wanted the purchase or what actually arrived.
Can an administrator tamper with the audit log?
The application provides no path to edit an audit entry, and the erasure routine is the only thing that deliberately rewrites one — replacing an erased person's name and email while leaving their actions intact. But it is an ordinary database table, so the protection is design and access control rather than cryptographic immutability. If your assurance requirement is tamper-evidence rather than tamper-resistance, raise it early, because that is a genuinely different guarantee and you should not discover the difference during fieldwork.
How long should we keep audit logs in Kenya?
Long enough to reconstruct anything you can be asked to explain, which means checking your longest obligation — tax record-keeping, donor agreement terms, sector rules — and setting retention against that rather than against a tidy-sounding number. The default is 730 days, which is a starting point and not a legal opinion. The trap worth avoiding is setting a short retention for data-minimisation reasons and thereby making your evidence expire before the obligation does.
Does erasing an employee under a data protection request break our audit trail?
It should not, and this is the specific thing to test rather than assume. Erasure replaces the person's name and email — including in the audit log — while the actions they took remain recorded, so approvals and stock movements survive as business records. An erasure that deleted those actions would trade a privacy problem for an audit problem, and one that left the name in place would not be an erasure at all. Ask any vendor to demonstrate exactly this on a test user.
Our approvals happen on WhatsApp. Is that a problem?
Yes, and it is the most common evidential gap in Kenyan SMEs. When a director approves verbally and an assistant enters it under their own login, the record says the assistant approved it — which is either false, or means the assistant holds approval authority they were never given. The fix is not to accept the proxy but to make approval genuinely fast on a phone, because approvers use what is quick and the whole control depends on their identity being the one recorded.
