CPA
Workpapers a Reviewer Can Follow
The test of a workpaper isn't whether the preparer understood it. It's whether someone who has never seen the file can reach the same conclusion without asking a question.
Review time is the scarcest resource in an audit or assurance engagement, and most of it is consumed by reconstruction — the reviewer working out what the preparer did, where the numbers came from, and whether the conclusion follows. Well-structured workpapers do not just satisfy quality standards; they buy back senior hours.
The stranger test
The working standard is this: could a competent person unfamiliar with the engagement pick up this paper, follow the work, and arrive at the same conclusion without asking anyone a question? If not, the gap is documentation, not knowledge — and the person who fills that gap will be the reviewer, at a much higher hourly cost.
Any question the reviewer has to ask is work the preparer left undone.
What every paper needs
• Objective — what assertion this work is designed to support.
• Source of the data, specific enough to re-obtain it: system, report name, parameters, date run.
• Population and how it was defined, before any sampling.
• Selection method and sample size, with the rationale.
• The work performed, step by step, with tickmarks explained on the same page.
• Exceptions found, and their resolution or why they are immaterial.
• Conclusion, stated against the objective.
• Preparer, reviewer, and dates.
Put the conclusion first
Papers are conventionally written in the order the work happened, with the conclusion at the end. Reviewers read faster when the conclusion is at the top, because they then read the work knowing what it is meant to demonstrate. It is a formatting change that costs nothing and measurably shortens review.
Explain tickmarks locally
A tickmark legend in a separate index paper means the reviewer holds two documents open and switches between them. Put the legend on the paper that uses it. Redundancy across a file is cheaper than navigation.
Document the exception properly
An exception with no visible resolution is the single most common review point. Record what was found, what was done about it, what the client said, whether it changed the conclusion, and — where it was not pursued — the explicit materiality reasoning. 'Discussed with client' is not a resolution; it is the beginning of one.
Make the standard a template, not a memo
Quality guidance in a manual gets read once during onboarding. The same guidance as the headed sections of a working template gets followed every time, because the blank headings are visible while the work is being done. That is the cheapest quality control a practice can implement.
Documentation requirements are set by the standards applicable to your engagement and jurisdiction. This describes practices that make review efficient; the mandatory content is a matter for those standards and your firm's methodology.
The 'stranger test' is how we train it now. If a reviewer has to ask what a tickmark means or where a number came from, the paper goes back regardless of whether the conclusion was right.
Stating the conclusion at the top instead of the bottom sounds trivial and halved my review time. I know what I'm looking to verify before I read the work.
Recording the population and how it was selected is the one that comes back to bite juniors. A sample with no documented population is untestable a year later, even if the sample itself was fine.