Skills / Audit and assurance

Audit workpaper

What it does

Builds an audit workpaper in proper form — header block, objective, population and source, procedures performed, evidence examined, exceptions, conclusion, sign-off — and then validates that the conclusion is actually supported by what was documented.

A workpaper has one job: demonstrate that the work was done, and that the conclusion follows from it. An experienced auditor with no prior involvement should be able to read it and understand what was tested, on what population, against what evidence, what was found, and why the conclusion is what it is — without asking anyone.

The most frequently cited documentation deficiency in inspection is not a missing signature or a formatting problem. It is a conclusion the documentation does not support — most often "no exceptions noted" on a workpaper that never records what was examined, or a conclusion reached while exceptions sit unaddressed elsewhere in the file.

What it proves

The validation is not a completeness checklist. It is a consistency check between the conclusion and everything above it. Seven tests, and the workpaper is not accepted unless:

  • Objective, population, procedure, evidence, and conclusion are all present. Missing any one of them is incomplete by definition.
  • The population is stated with its source and its total, and how it was obtained. A procedure performed on an unstated population supports nothing.
  • Every procedure step records the evidence examined. A step with a result and no evidence is an assertion.
  • The conclusion is consistent with the exceptions. It may not state or imply "no exceptions" when exceptions are recorded; may not assert agreement where a recorded difference is non-zero; may not be reached at all where a step has no evidence; and an exception with no disposition blocks it.
  • Preparer and reviewer are named and different people. A workpaper reviewed by its preparer has not been reviewed.
  • Every tickmark used is defined, and every tickmark defined is used.

It is deliberately hard to satisfy by rewording — a conclusion that acknowledges its exceptions and explains why they do not change the outcome is what a defensible conclusion looks like anyway.

What you get

Six tabs:

  1. Workpaper — the document itself, in proper form. The thing that goes in the file.
  2. Validation — the seven tests with what failed and why. Not part of the workpaper; part of preparing it.
  3. Procedures and Evidence — step by step, with the evidence reference and result against each.
  4. Exceptions — each with amount, disposition, and whether it affects the conclusion.
  5. Tickmark Legend — every mark defined, with usage count.
  6. Cross-References — other workpapers referenced, so the file hangs together.

Where it rejects a workpaper it says exactly which element is missing or which claim the documentation does not support. "The conclusion states no exceptions while three are recorded" is actionable; "documentation deficiency" is not.

Where it stops

It does not write your conclusion. It validates that the conclusion you wrote is supported. Reaching it is the professional judgement and the one thing that cannot be delegated.

It does not decide whether an exception is material or isolated — it requires that you state a disposition. And it does not assess whether the procedure was appropriate for the assertion: a well-documented wrong procedure is still a wrong procedure, and that is a planning and review question.

Evidence described generically — "per client", "per discussion", "reviewed" — with no document reference is escalated, as are a workpaper reviewed by its preparer, a population that does not agree to the general ledger, a contradiction between evidence and conclusion left unaddressed, and documentation added after the assembly deadline without being marked as such.