← Blog

    Audit Working Papers: What They Must Show

    Warp team · November 4, 2026

    Audit working papers (also called workpapers or audit documentation) are the record of what the auditor did, what evidence they got, and what they concluded. If it is not in the working papers, for inspection purposes it did not happen.

    The standard to meet

    • AICPA: AU-C 230, Audit Documentation.
    • PCAOB: AS 1215, Audit Documentation.
    • International and Canada: ISA 230 and CAS 230.

    All of them use the same test: the documentation must let an experienced auditor with no previous connection to the audit understand:

    1. the nature, timing and extent of the procedures performed,
    2. the results of those procedures and the evidence obtained, and
    3. the significant findings, the conclusions reached, and the significant professional judgments made to reach them.

    "Experienced auditor" means someone who knows auditing and the industry, not someone who was on the engagement. Your working papers have to make sense to a reviewer or inspector who has never spoken to your team.

    What each working paper should show

    • The objective. What the procedure is for, and which assertion or risk it addresses.
    • The population and the sample. Where the items came from, how many, and how they were selected.
    • Identifying characteristics of the items tested. Enough to find them again: invoice numbers, dates, amounts, GL references. "Tested 25 invoices" is not enough.
    • What was done to each item. Which document was inspected, what was compared, and what was found.
    • Exceptions and how they were resolved. Including the ones that turned out not to be errors, with the reason.
    • The conclusion, tied back to the objective.
    • Who did the work and when, and who reviewed it and when.

    AU-C 230 also asks you to document significant matters discussed with management and those charged with governance, and any inconsistency between your conclusion and other information you found.

    A structure that holds up

    Most firms use a similar layout:

    • Lead schedules for each area, showing the balance, the prior year, adjustments, and references to the supporting work.
    • Supporting schedules for each test, cross-referenced to the lead.
    • Tickmarks with a legend, used consistently. A tickmark that is not defined on the page means nothing to a reviewer.
    • Cross-references both ways: from the lead to the test, and from the test back to the lead and to the source documents.
    • Client documents (PBC) filed and referenced, not just mentioned.

    Assembly and retention deadlines

    Final file assemblyRetention
    AU-C 230 (AICPA)Within 60 days after the report release dateAt least 5 years from the report release date
    AS 1215 (PCAOB)Within 45 days after the report release date7 years from the report release date
    ISA 230 / CAS 230Within 60 days after the date of the auditor's reportSet by firm policy and local rules; commonly at least 5 years

    After the assembly date you may add documentation but not delete or discard anything. Any addition must record what was added, who added it, when, and why.

    Review notes that come up again and again

    1. "What did you look at?" Tickmarks without the document, page or field checked.
    2. "How was the sample selected?" Missing population, method or size rationale.
    3. "Where does this number come from?" Figures that do not tie to the lead or the trial balance.
    4. "Is this an exception?" Differences noted but not concluded on.
    5. "Why is this OK?" Judgments made in the team's heads and never written down.

    Each of these is a documentation gap. The work was usually done, but the paper does not show it.

    AI-generated working papers

    Working papers produced with AI tools are held to the same standard. An inspector checks whether the documentation shows what was compared, against which evidence, and why the conclusion follows, whoever did the matching. For AI output that means:

    • every conclusion links to the source document and page it relied on,
    • the reasoning is visible, not just the answer,
    • exceptions are flagged with the specific fields that disagree, and
    • a human reviewer signs off, with the sign-off recorded.

    That is how Warp builds its output. Warp runs the testing, such as vouching and test of details, journal entry testing and controls testing, and every line in the workpaper links back to the evidence with the reasoning shown. We wrote more about why in Design Principle: Reviewability.

    For the tests behind the papers, see substantive testing, test of controls and vouching vs tracing.

    Want to talk about this?

    More posts