Preparing for an audit with automated books

Audit preparation with automated books is different from the traditional version. Less document hunting, more explaining how the processing worked.

Businesses that prepare for the old audit and get the new one spend the fieldwork improvising answers about their control environment. Here is what to have ready instead.

Six weeks out: the process documentation

One page per automated process:

• What it does, and from what date
• What posts automatically and what the threshold is
• What routes to a person, and to whom
• What hard limits constrain it
• Who owns it
• What changed during the year, with dates

If this does not exist, writing it is the single highest-value preparation task, and it is genuinely a day's work rather than a project. It also frequently reveals that a threshold has not been reviewed since implementation, which is better discovered now.

Six weeks out: the sampling file

Your record of monitoring: what you sampled, when, how many, what you found, what you did about it.

If you have been sampling quarterly, assemble it. If you have not, start now and be honest that it starts now — a sampling programme beginning in month ten is a partial answer, and inventing one for the earlier months is considerably worse than admitting the gap.

Four weeks out: reconcile everything, decomposed

Every balance sheet account should break into items you can name. Not agreed to a total — decomposed.

Priority order, since these are where problems concentrate:

• Suspense and clearing accounts, which should ideally be nil
• Accruals and prepayments, where unreversed items accumulate
• Intercompany, where small differences get carried for years
• Foreign exchange, where unrelated errors get absorbed
• Statutory liability accounts, where residues build
• Any control account whose balance nobody can currently explain

A balance that will not decompose is the single most likely source of an audit adjustment, and finding it four weeks out is much better than during fieldwork.

Four weeks out: the configuration change log

Every change to a rule, threshold or tolerance during the year, with date, reason and who made it.

If this was not kept, reconstruct what you can from system logs and be explicit about what cannot be reconstructed. An auditor can work with a gap that is disclosed. They cannot work with a claim of stability that turns out to be untrue.

Two weeks out: walk one transaction end to end

Pick a routine automated transaction and trace it yourself, the way an auditor will:

Figure in the accounts → the transactions behind it → the specific entry → the source document → the basis for the treatment → the rule version → the review or the threshold that meant there wasn't one.

If any step is awkward, that is what fieldwork will feel like, multiplied. Fix it now or at least know where the friction is.

Do the same for one exception that was reviewed, so you can demonstrate what review looks like.

Two weeks out: the cut-off position

Cut-off is the most tested area in most audits and where automation is least reliable, because the decision depends on facts about events rather than patterns in transactions.

Have ready: how period allocation is determined, whether any of it is automated, what the manual review around period end consists of, and the list of items specifically considered at the boundary.

If cut-off is entirely manual, say so early. It is one of the more reassuring things you can tell an auditor about an automated function.

The week before: brief your team

Whoever the auditor speaks to should be able to answer, in their own words:

• What the system does automatically
• What they personally review and what they are attesting to
• What they do when they are unsure
• Who they escalate to

The damaging answer is "I just approve what comes through". It may be an unfair characterisation of a careful person having a bad moment, and it will shape the auditor's view of the control regardless. A short conversation beforehand about what they actually do and why prevents it.

What not to do

Do not clean up the audit trail. Amending records to look tidier is worse than any untidiness, and in most systems the amendments are themselves logged.

Do not create documentation dated earlier than it was written. A process description written last week describing the whole year is fine and normal; one presented as contemporaneous is not.

Do not present vendor material as your control documentation. Auditors want to know what you do, not what the software can do.

The reframe

Automated books are usually easier to audit than manual ones — the evidence is attached to every transaction, the population is complete, and nothing depends on whether someone filed a document.

The preparation is different rather than heavier. It shifts from finding documents to explaining process, and the explanation is a day's writing if the process was set up thoughtfully.

Common questions

How do you prepare for an audit when the books are automated?

The preparation shifts from locating documents to explaining process. Have one page per automated process covering what it does, what posts automatically, the thresholds, what routes to review, who owns it and what changed during the year; assemble your monitoring and sampling records; reconcile every balance sheet account into nameable components; and walk one transaction end to end yourself before the auditor does.

What if we have not been sampling our automated transactions?

Start now and be explicit that it starts now. A monitoring programme beginning late in the year is a partial answer that an auditor can work with, whereas constructing records for earlier months is considerably worse than disclosing the gap and considerably more damaging if noticed.

What gets tested hardest in an automated finance function?

Period cut-off, because it is the most tested area in most audits generally and the place automation is least reliable, since the decision depends on facts about events rather than patterns in transactions. Changes made to rules and thresholds during the year come next, followed by whether exception review was genuine rather than bulk approval.

What should staff be able to tell an auditor?

What the system does automatically, what they personally review and what they are attesting to when they approve, what they do when they are unsure, and who they escalate to. The damaging answer is that they simply approve whatever comes through, which will shape the auditor's view of the control environment even when it misrepresents a careful person.

Related: evidence an auditor will accept · year-end adjustments and the audit file · ai accounting and your external auditor