Audit trail: what an accounting firm must be able to demonstrate
What is an audit trail, what do you record and how does automation stay traceable? Practical guidance with a recording checklist for firms.
The short answer
An audit trail is the path along which you can walk back from a figure in a tax return to its source, and forward again. For every step in that path you record four things: who or what performed the step, when, based on which source, and what the value was before anything changed.
As long as people did the posting, the trail was more or less self-evident: there was an employee behind every action. Now that software makes suggestions and handles part of the postings independently, you have to record explicitly why an entry is what it is. That is not merely an internal wish. The joint guidance from the Dutch professional bodies NBA and NOREA on the use of AI states that AI must never be a black box for members, and that validation and human judgement remain the basis of public trust.
An audit trail and logging are not the same thing
Logging is technical: which user signed in, which request arrived when, which error occurred. Useful for administration, but it answers no substantive question.
An audit trail is administrative: why is this € 240 on this ledger account, at this VAT rate, in this period. An audit trail contains references to documents, to decisions and to changes, and is intended to let you form a judgement after the fact.
A system can therefore have excellent logging and still offer no usable control trail.
Why the trail matters more once you automate
In manual work, part of the reasoning sits in the employee's head and in the folder of documents. In automated work that intermediate step disappears. Three consequences:
The volume of entries without human intervention rises, so sampling becomes more important than full review.
The cause of an error is different. One misconfigured rule produces hundreds of identical errors instead of a single slip. You therefore want to see which rule or which model was behind an entry.
The accountability shifts. The firm remains responsible for the result, even when software performed the action. You can only carry that if you are able to reconstruct what happened.
What you record as a minimum
Source
| To record | Why |
|---|---|
| The original document, stored unaltered | Without the source, the rest cannot be checked |
| Submission channel and time | Explains duplicate submissions and late processing |
| Who submitted it | Client, supplier or employee |
| Document characteristics | Invoice number, date, supplier, total amount |
Processing
| To record | Why |
|---|---|
| Recognised values | To see whether recognition was correct |
| The rule or model used, with its version | To trace an error back to its cause |
| Confidence or score, if the software provides one | To aim samples at borderline cases |
Decision
| To record | Why |
|---|---|
| The suggestion as it was | To see what a person did or did not accept |
| Who reviewed it, or that it was posted automatically | Accountability |
| The reason when deviating from the suggestion | This is the learning source for better rules |
Change
| To record | Why |
|---|---|
| Old and new value | Otherwise a correction is an erasure |
| Time and user | Reconstruction of the sequence |
| Reason or reference to the correction | For reconciliation with returns and corrections |
From source to return in four links
- Document to entry. The entry refers to the document, and the document is findable from the entry.
- Entry to the general ledger and subledger. Every movement is traceable to the item it originates from.
- Ledger to return. The return is a total of marked items, and from every box in the return you can go back to the underlying entries.
- Return to correction. A VAT correction or correction message refers to the original return and to the entries causing the correction. See VAT correction (suppletie) and Correcting a payroll tax return.
If one of those links breaks, every review question costs an investigation instead of a click.
Mistakes that break the trail
- Storing documents outside the system. A receipt in a mailbox or on a network drive is not a source the entry refers to.
- Overwriting instead of correcting. If a correction erases the old value, you can no longer see that there was an error.
- Reprocessing without version control. A re-imported document that silently overwrites the previous processing hides exactly the information you want to see.
- Changing rules without a date. Without a version you cannot explain a March entry using the July rule.
- Shared accounts. Entries made under a shared login do not show who reviewed them.
- Keeping only the end result. The suggestion that was rejected is information in itself.
Recording checklist
- Every document is stored unaltered and can be opened from the entry.
- Every entry shows whether it came about manually, from a rule or from a suggestion.
- For a suggestion, what it was based on is visible.
- Changes preserve the old value.
- Rules and models have a version and an effective date.
- Employees work under their own account, including temporary staff.
- Returns are stored exactly as they were submitted, with the time and the submitter.
- Corrections refer to what they correct.
- Samples of automatically processed items are recorded, even when they turn up nothing.
- When an employee leaves, the history remains readable, even if the account is deactivated.
Retention and keeping records available
Your records fall under the Dutch statutory retention obligation, seven years in principle and longer for certain data. For the control trail that means two things: the audit trail is part of the records and must therefore be kept just as long, and they must remain readable and accessible throughout that period. An export nobody can open any more does not count as retained records. The terms and exceptions are covered in Retention obligation for your records.
Note: exactly which term applies depends on the type of data and the client's situation. When in doubt, this is a question for the responsible accountant or tax specialist, not for the system administrator.
What a review may ask of you
Whether it is a tax audit at a client or an internal review, the questions are similar. Four of them can only be answered properly if the trail is in order.
Show where this amount comes from. From a box in the return to the entries, and from an entry to the document. This should take a few clicks, not a search through a mailbox.
Who reviewed this? For manual entries that is a name; for automatic processing it is the combination of rule or model, version, and the person who maintains the setup.
Why was this item treated this way? A deviating VAT treatment or a tax position calls for a recorded reason. Reconstructing afterwards is almost always weaker than a half-line note at the time itself.
What has changed since? Corrections, reprocessing and amended rules should be visible with dates, so the sequence of events is established.
During a software change or migration
A migration is the moment when audit trails most often disappear. A migration usually brings across balances and open items, but not the underlying documents, the history of changes and the record of who assessed what.
So arrange three things beforehand. Decide which history moves across and which does not, and record that choice. Keep the old system, or a readable export of it, until the end of the retention period and test once that the export can genuinely be opened. And mark the migration moment in the administration, so it is later clear why the trail before that date is built up differently than after it.
Next step
See how Giroo Administration records per entry where it came from, which suggestion preceded it and who reviewed it.
Content reviewed: July 2026. Retention periods and the application of professional rules can differ per situation; record the assessment with the responsible professional.