Audit readiness

Audit readiness is a system, not a season

Why the teams with the calmest audits treat readiness as standing infrastructure — and what that looks like in practice.

Most finance teams experience the audit as a season. Fieldwork approaches, the request list arrives, and for six weeks the close calendar bends around evidence-gathering. Then it ends, everyone exhales, and the whole apparatus is dismantled until next year.

The teams with the calmest audits do something different. They treat readiness as standing infrastructure — a system that runs all year, quietly, as part of how the work is already done. This article describes that system: what it replaces, what it is made of, and how to start building it without adding headcount.

The seasonal trap

Seasonal readiness fails for a simple reason: the evidence an audit needs is produced all year, but it is only assembled at the end. By the time the request list arrives, the people who did the work have moved on, the context has faded, and reconstruction begins.

The symptoms are familiar:

  • The same population is pulled three times because nobody recorded which version was sent.
  • Queries route through one controller, who becomes the bottleneck for the whole engagement.
  • Answers are drafted from memory, then revised when the underlying document says something slightly different.
  • Follow-up questions multiply, because the first answers arrived without their support.

None of this reflects a control weakness. It reflects a storage and retrieval problem — the work was done, but it cannot answer for itself.

What standing readiness looks like

Standing readiness has one design principle: evidence is captured where the work happens, at the time it happens. Everything else follows from that.

Evidence lives at the source

A reconciliation is evidence the moment it is prepared — if it is stored with its inputs, its preparer, and its date. The same document rebuilt eight months later is a reconstruction, and auditors can tell the difference. Standing readiness means the file that supports an answer is the file that produced it.

Ownership is explicit

Every recurring request has a named owner and a known source before the audit begins. When the query arrives, it routes to the owner; it does not queue behind a single inbox.

The calmest audits belong to teams that never stopped being ready.

In practice, standing readiness is a loop, not a project. It has four movements, repeated every cycle:

  1. Capture — evidence is filed at the point of work, with provenance attached.
  2. Structure — documents are linked to the balances and assertions they support.
  3. Respond — queries are answered from the structured record, not from memory.
  4. Review — every response is checked and approved by a person before it leaves.
Fig. 1 — The readiness loop. Evidence is captured once, structured once, and reused for every query that touches it.

The first requests, and where they should come from

Every audit opens with a predictable set of requests. If each one has a standing source, the first week of fieldwork becomes an export, not an excavation.

RequestTypical ownerStanding source
Trial balance and mappingFinancial controllerClose package, exported at period end
Bank reconciliationsAccounts teamFiled with statements at each close
Revenue recognition memoCFO / controllerPolicy library, versioned
Access and change logsSystems ownerQuarterly export, retained
Board minutesCompany secretaryGovernance folder, indexed by date

The table is deliberately boring. That is the point: readiness is mostly the discipline of deciding, once, where each answer lives — then keeping that decision true.

Where Audit Intelligence™ fits

A structured record changes what software can do with an audit query. Audit Intelligence™, the reasoning layer inside Oditable, reads each query, locates the relevant evidence in your record, and drafts a response with its support attached — citations first, prose second.

In practice

An auditor asks why deferred revenue moved 40% year on year. Audit Intelligence™ drafts the response from the recognition memo, the contract schedule, and the close notes — and links each claim to its source. A controller reviews the draft, adjusts one sentence, and approves. Elapsed time: minutes, not days.

Nothing leaves without review. The system prepares; a person approves. That order never reverses, because an audit response is a representation of the business — it should carry a human signature, with the machine doing the assembly.

Getting started

Standing readiness is built incrementally. A reasonable first quarter looks like this:

  1. List last year’s requests. The prior-year PBC list is a complete specification of what the next audit will ask.
  2. Assign each request an owner and a standing source. Accept that some sources will be “we don’t have one yet”.
  3. Close the gaps in close order — start with the requests that caused the longest delays last year.
  4. Answer this year’s queries from the record, and file every response as evidence for the next cycle.

The first cycle is work. The second is noticeably lighter. By the third, the audit has stopped being a season — it is simply a period in which the system gets read.

Oditable Editorial Notes on audit readiness from the team building Audit Intelligence™.

Keep reading.

All articles →
Evidence Coming soon

Evidence that answers for itself

What separates a document from support: structure, provenance, and context.

Controls Coming soon

What a control is actually for

Controls exist to make assurance cheap. Most teams design them backwards.

Audit Intelligence™ Coming soon

Inside Audit Intelligence™

The reasoning layer behind every draft — and why it cites before it writes.