The first audit most finance teams fail is not a failure of controls. It is a failure of retrieval. The control existed, it ran, and nobody can produce the forty transactions proving it ran without three days of searching.
Design versus operation
Auditors test two separate things and teams routinely prepare for only the first.
Design is whether the control would catch the thing if it happened — a policy document answers this. Operation is whether it did catch it, every time, across the period — only records answer this, and they have to be records that were created as the control ran, not assembled afterwards for the audit.
Evidence assembled afterwards is not worthless, but it is a different and weaker claim, and experienced auditors can tell the difference on sight.
The four requests that come every time
- A sample of transactions, with the approval trail attached to each.
- Proof that the approver was authorised to approve at the date of approval, not today.
- The exception log, including the exceptions that were approved.
- A list of who could have changed the policy during the period.
The third is where teams are surprised. An empty exception log is not a good result. It reads as either a control nobody is testing or a log nobody is keeping.
Authorisation is a point-in-time fact
This is the one that costs weeks. “Who can approve payments over €10,000” is a question about today. “Who could approve them on 14 March” is a question about a state that has to have been recorded when it changed. A permissions screen answers the first and cannot answer the second.
Make retrieval the design constraint
If evidence lives with the transaction, a sample request is a filter. If it lives in mailboxes and folders that mirror the transactions, it is a research project — and the research project is what turns a two-week audit into a two-month one, with no difference in the underlying controls.
