From Fragmented Evidence to Review-Ready Working Papers

Under ISA 230, audit documentation exists to provide a sufficient and appropriate record of the basis for the auditor's report, and to demonstrate that the audit was performed in accordance with applicable standards. Paragraph 8 sets out what's often called the "experienced auditor" test: documentation should be complete enough that an experienced auditor with no prior connection to the engagement can understand the nature, timing and extent of the procedures performed, the results and evidence obtained, and the significant matters, conclusions and professional judgments reached. That requirement is broader than preserving receipt records alone — this article focuses on one part of it, the receipt and transaction evidence trail.

That test is where fragmented evidence causes real damage. A conclusion is easy to write. Reconstructing exactly what evidence supported it — especially months later, for a quality review or an external inspection — is where scattered source material turns a straightforward check into significant extra reconstruction work.

A worked example: evidence to conclusion

The example below follows one transaction from capture to documented review, keeping unresolved questions visible.

For the records to gather when preparing a director's claim, see our director reimbursement supporting-record checklist. The review and working-paper decision remains specific to the engagement.

Nothing about this example is automatic. The system's role was organizing the pieces and surfacing the exception; the reviewer then assesses whether the information obtained is sufficient and appropriate for the specific question it was gathered to answer. That division of labor is the point — see the Evidence Decision Chain for the general version of this same capture-to-preservation path.

What receipt evidence should accompany a working-paper handoff?

The worked example above follows one transaction. Assembling a working paper from it means keeping these elements present and distinguishable, not merged into a single corrected record:

• Original source and transaction reference. The source receipt or invoice, unaltered, with a stable reference ID that every later note, correction, or decision can point back to.
• Extraction uncertainties and separately recorded corrections. What the system read from the document, including low-confidence or illegible fields, kept distinct from any human correction made afterward.
• Claimant, business purpose and relevant supporting records. The stated purpose and who supplied it, plus relevant supporting information for the reviewer to assess — a calendar invite, an itinerary, an approval, a client name.
• Exceptions, clarification requests and responses. What was flagged, what was specifically asked, and what came back — not just the final answer, but the question that produced it.
• Reviewer identity, action, reasoning and unresolved matters. Who made the call, what they decided, on what basis, and what was left open rather than silently closed.

This is GetZenta's recommended handoff checklist, adapted to the engagement — not an ISA-prescribed document list. It follows the same handoff described in GetZenta's Auditor Workflow and built on the evidence model set out in Audit Evidence. For a shorter worked example of the same handoff from a different angle, see From Receipt to Reviewer.

What this replaces

Without structure at capture, the same reconstruction work above typically happens in reverse and under time pressure: a reviewer opens a working paper near year-end, finds a conclusion with no visible trail behind it, and has to chase down a WhatsApp thread, an email, and a verbal approval — none of which were preserved together, and some of which may no longer be findable. Structuring evidence earlier is meant to move that work forward, not eliminate the review step that makes the conclusion defensible in the first place.

Continue reading

• Audit Evidence for Malaysian Receipt Workflows: Why OCR Alone Is Not Enough — the pillar this example draws its framework from.
• Human Override vs AI Autonomy: Recording an Accountable Review Decision — a closer look at step 05 above, the review decision itself.
• The Hidden Risk in "Fully Automated" Compliance Systems — why fully automated processing needs points where review can stop it, as in step 03's exception routing.
• Why Every AI Compliance System Needs a Human Accountability Layer — why machine signals and recorded human decisions are kept separate, as in step 05.
• Security Statement — how preserved records in step 06 are protected and isolated.