What an auditor asks for that your ERP cannot answer

The bulk of an audit request list is exactly what an ERP is good at: trial balances, transaction listings, aged receivables, stock reports. Any reasonable system produces these quickly and accurately, and this part of an audit rarely causes delay on its own. The delay concentrates in a small, predictable set of requests that no ERP, however good, was ever built to answer.

The requests that consistently stall

"What was the basis for this estimate?" A provision, an allowance, a valuation judgement — the system holds the resulting number perfectly. It holds nothing about how that number was derived, because the derivation was a judgement process, not a transaction.

"Why was this approved given [some unusual circumstance]?" The audit trail confirms who approved it and when. It has no field for the approver's reasoning, particularly when the approval was an exception to normal policy — see the audit trail tells you who, not why.

"What's the commercial rationale for this related-party transaction?" This is almost never in the system at all, because related-party transactions are recorded like any other transaction, with none of the surrounding commercial context an auditor specifically needs to assess whether the terms were reasonable.

"Has anything changed since this policy or estimate methodology was set?" The system shows the current policy. It doesn't show whether circumstances have shifted enough to warrant revisiting it, because that's an ongoing judgement nobody's system was asked to track.

Why these specific requests are predictable in advance

They cluster around exactly the places where judgement, rather than mechanical recording, drove the outcome. This is useful, because it means a business doesn't need to prepare for every conceivable audit question — it needs to identify, in advance, the handful of areas each year where real judgement was exercised, and make sure those specific areas have a written rationale ready before anyone asks.

Why "the auditor should just ask the person involved" fails as a plan

It works exactly as long as the person involved is still at the business, still remembers the specific details, and is available when the audit happens to fall. All three of these conditions degrade over time — staff turn over, memories fade, and audits sometimes cover periods well after the fact, particularly for smaller businesses whose audits aren't always immediate. Relying on availability and memory as your documentation strategy is a bet that gets worse every year it isn't addressed.

What genuinely helps here, honestly assessed

An audit trail that records who approved what and when gives an auditor a reliable starting point — confirming a process was followed is real, useful evidence, and it's not nothing. But it stops exactly where judgement begins, and no audit trail feature closes that specific gap, because capturing reasoning was never what an audit trail was built to do. The honest fix sits with the business, not the software: a habit of writing the rationale down, for the categories of decision most likely to be asked about, at the time the decision is made.

Building an audit-ready habit without overbuilding

Identify your predictable categories now, before the audit. Significant estimates, related-party transactions, and policy exceptions are common across most businesses — review what typically shows up on your own request list from prior audits and treat those categories as the priority.

Write the rationale as part of making the decision, not as audit preparation. If capturing the reason is treated as a separate, audit-specific task, it competes with audit deadlines and loses. If it's built into how the decision gets made in the first place, it's simply there when needed.

Keep a standing file of the year's significant judgement calls, updated continuously, so that when the audit does arrive, the answer to "what was the basis for this" is a lookup rather than an investigation.

Common questions

What kinds of audit requests does an ERP typically struggle to answer?

Requests that depend on judgement rather than recorded transactions: the basis for a significant estimate, the reasoning behind an exception to normal approval policy, the commercial rationale for a related-party transaction, and whether an existing policy still reflects current circumstances. These require context an ERP was never designed to hold.

Why can't relying on staff memory work as a long-term documentation strategy?

Because it depends on the person involved still being at the business, still remembering the specific details accurately, and being available when the audit happens to occur — and all three of those conditions get less reliable the more time passes between the original decision and the audit that asks about it.

Can better audit-trail software solve this problem?

Only partially. A good audit trail reliably confirms who approved something and when, which is genuinely useful. It stops exactly where judgement begins, because capturing the reasoning behind a decision was never something an audit trail was built to do — that gap has to be closed by a documentation habit, not a software feature.

How can a business prepare for predictable audit questions in advance?

Identify the categories of decision most likely to be questioned — significant estimates, related-party transactions, policy exceptions — based on what typically appears in prior audit requests, and build the habit of writing the rationale down as part of making those decisions, rather than treating it as a separate task done only when an audit is imminent.

Related: the audit trail tells you who, not why · reconstructing a write-off decision two years later · why audit season keeps taking longer than the numbers justify