How to Perform a Walkthrough Test Under ISA 315

What ISA 315 requires and why walkthroughs exist

ISA 315 (Revised 2019) restructured how auditors obtain an understanding of the entity’s system of internal control. The standard doesn’t use the word “walkthrough” in its requirements paragraphs. But ISA 315 .A178 explicitly describes the procedure: tracing a transaction through the information system, including the IT applications involved, from initiation to its reflection in the financial records. The application material is clear that this is one of the procedures available to confirm your understanding of a process and the controls within it.

The purpose of a walkthrough is narrow and specific. It doesn’t test whether a control operates effectively over a period (that’s ISA 330.8 territory). It confirms that the process you’ve documented in your risk assessment actually matches what happens on the ground. If your process narrative says the financial controller reviews and approves journal entries above €10K, the walkthrough confirms that this step exists, that the financial controller is the person who does it, that there’s evidence of their review, and that the IT system enforces the approval threshold.

This sounds straightforward. In practice, walkthroughs fail for two reasons. First, teams treat them as a formality rather than an investigation. They select a clean transaction, trace it through, confirm it matches the narrative, and move on. The walkthrough adds no information the team didn’t already have. Second, teams confuse walkthroughs with control testing. They walk through five or ten transactions and call them “walkthroughs” when the file actually needs a test of operating effectiveness under ISA 330.8 . The result is a procedure that satisfies neither objective.

Walkthroughs versus tests of controls: the distinction that matters

This confusion shows up in inspection findings more than almost any other control documentation issue. The AFM’s 2022 inspection report specifically noted instances where firms documented a walkthrough of a single transaction as evidence of operating effectiveness, without performing separate tests of controls.

A walkthrough confirms your understanding of the process. Trace one transaction. Confirm that each step in your documented process exists and operates as described. Then identify whether the controls are designed effectively to prevent or detect misstatement. ISA 315 .A178 governs this. The output is confirmation (or correction) of your process understanding and your assessment of control design.

A test of controls under ISA 330.8 tests whether the control operated effectively throughout the period. Select a sample ( ISA 530.7 governs sample size) and examine evidence of the control’s operation for each item. The output is a conclusion on operating effectiveness that supports your planned reliance. If you plan to rely on a control to reduce the extent of substantive procedures, ISA 330.8 requires you to test that control’s operating effectiveness. A walkthrough alone can’t satisfy this requirement.

Document the two procedures separately in your file. The walkthrough belongs in your risk assessment working papers (WPs) alongside your process understanding. The test of controls belongs in your response WPs. Mixing them into a single WP is how the confusion starts, and it is the first thing an inspector checks.

How to select the right transaction

The transaction you pick for a walkthrough determines whether the procedure produces useful information or just confirms what you already assumed.

Don’t pick the cleanest, most typical transaction you can find. A standard sales order that went through every approval step exactly as designed tells you the process works when everything goes right. That’s not what you need to know. You need to know what happens when something is slightly off. Pick a transaction that interacted with the controls you care about.

For a purchase-to-pay walkthrough, select an invoice where the amount was close to an approval threshold (within 10% above or below the limit). These transactions show you whether the threshold control actually triggers. Select an invoice that arrived during a busy period (month-end, year-end) rather than a quiet Tuesday in March. Busy periods are when controls get bypassed.

For a revenue process walkthrough, select a transaction with a non-standard element: a discount, a partial delivery, a credit note issued in the same period, or a manual price override. ISA 315 .A178 refers to tracing a transaction through the information system. A transaction with no complications doesn’t test whether the system handles complications correctly.

One transaction per walkthrough. That’s the point. But choose it deliberately.

Executing the walkthrough: what to do at each step

Start at the point of origination and follow the transaction forward. Don’t work backwards from the general ledger. Working backwards tells you how it was recorded. Working forwards tells you how it was processed, and those two things are not always the same.

At each step in the process, you’re confirming four things. Does this step exist as documented in your process narrative? Who performs it (is it the person your narrative says)? What evidence does the step produce? Does the evidence match what actually happened for this transaction?

Talk to the person who performs the step. Don’t just look at the document. ISA 315 .A178 describes “inquiry of appropriate entity personnel combined with... tracing of a transaction.” The inquiry component is not optional. Ask the AP clerk: “What do you do when the goods receipt doesn’t match the invoice?” Ask the financial controller: “When was the last time you rejected a journal entry?” The answers to these questions reveal more about control design than any document review.

When you encounter an IT application step (automatic three-way matching, system-enforced approval routing), note the application name and what the system does. ISA 315.26 requires your understanding to extend to IT applications relevant to the information system.

If the system generates the goods receipt automatically when a purchase order hits a certain status, that’s a different control design than a manual goods receipt entered by the warehouse team. Your walkthrough needs to capture this distinction.

At every step where a control operates, assess design effectiveness immediately. Ask yourself: if this control operates exactly as designed, would it prevent or detect the misstatement it’s supposed to address? If the control is a review of a reconciliation but the reviewer has no independent data source to check against, the control is designed poorly even if it operates every day. Document this assessment during the walkthrough, not two weeks later when you’re writing up your risk assessment.

Pay attention to compensating controls. If the primary control has a design weakness, the entity may rely on a compensating control elsewhere in the process. Your walkthrough should capture both. A weak purchase approval control compensated by a strong three-way matching control changes your overall design assessment. Miss the compensating control and you’ll overstate the design deficiency in your risk assessment.

Documenting as you go

The walkthrough WP should be completed during the walkthrough, not reconstructed from memory afterwards. This is the most common documentation failure. A WP prepared three days after the walkthrough reads like a process narrative, not like a record of a procedure performed. Reviewers can tell the difference. When a walkthrough becomes a tick box exercise, this is usually where it shows up first: a neat narrative written after the fact that cannot be distinguished from last year’s copy.

Your WP needs four elements per step. The step description (what you observed), the person you spoke to (name and title), the document or system evidence you examined (with a reference), and your assessment of whether the step and any associated control match your documented understanding.

If something doesn’t match your process narrative, document the discrepancy immediately. Don’t resolve it first and then document the resolution. Document what you found, then document how you resolved it. ISA 315 .A178 is a procedure for confirming or correcting your understanding. If you only document confirmations, your WP doesn’t reflect the procedure ISA 315 describes.

For the IT processing steps, document the application name, the function it performs, whether you observed the system performing the function during the walkthrough, and whether you relied on the entity’s description for any part of the step. If you didn’t observe it (because the IT step runs overnight, for instance), note that your understanding of this step requires corroboration from IT general controls testing or an IT walkthrough.

Cross-reference your walkthrough WP to your process narrative. If the walkthrough confirmed the narrative, state that. If the walkthrough identified differences, update the narrative and cross-reference the update to the walkthrough finding. The reviewer should be able to trace from the narrative to the walkthrough evidence in under 60 seconds.

When to perform the walkthrough

Timing matters more than most teams realise. Perform walkthroughs during interim fieldwork, before you finalise your audit strategy. The walkthrough confirms (or corrects) your understanding of controls, which drives your decision on whether to rely on those controls and reduce substantive testing. If you perform the walkthrough at year-end alongside your substantive procedures, any design deficiency you discover forces you to redesign your audit approach under time pressure.

For recurring engagements, don’t assume the PY walkthrough still holds. ISA 315.14 requires you to update your understanding of the entity’s system of internal control each period. A walkthrough is the most efficient way to confirm that nothing has changed. If the entity implemented a new ERP module or shifted from manual to automated matching, the PY narrative is outdated and so is any control reliance built on it. SALY (same as last year) is how walkthroughs quietly drift out of sync with reality: the file copies forward year after year while the process on the ground changes underneath it. Nobody loves re-performing a walkthrough the team did a month ago, but this is the procedure the PCAOB cites most often when files fail.

Worked example: Brouwer Techniek B.V.

Scenario: Brouwer Techniek B.V. is a Dutch industrial equipment distributor with €42M revenue and €28M in annual purchases. The engagement team is performing a walkthrough of the purchase-to-pay process during interim fieldwork in September 2024. The entity uses SAP for procurement and accounts payable. The audit team plans to rely on the three-way matching control to reduce substantive testing on trade payables.

Selected transaction: Purchase order PO-2024-3847 for €47,200 of industrial valves from supplier Schmidt Armaturen GmbH, dated 14 August 2024. Selected because the amount is close to the €50K enhanced approval threshold and the goods were received in two partial deliveries.

Walkthrough conclusion: The purchase-to-pay process at Brouwer Techniek B.V. operates as documented in the process narrative with one exception. The process narrative stated that AP supervisor M. de Groot reviews all invoices above €25K before payment. During the walkthrough, Visser confirmed that this review applies only to mismatched invoices, not to all invoices above the threshold. The process narrative requires updating, and the planned control reliance must be reassessed against the actual control design. The three-way matching control (automated in SAP) is designed effectively for matched invoices. The team should assess whether the absence of manual review for matched invoices above €25K represents a significant deficiency given the planned reliance.

Practical checklist for your next walkthrough

Common mistakes regulators flag

• The AFM’s 2022 inspection cycle identified files where the walkthrough WP contained no evidence of inquiry with entity personnel. The WP read as a document review, not a walkthrough. ISA 315 .A178 explicitly pairs inquiry with tracing. A walkthrough without inquiry evidence is incomplete.
• The FRC’s 2022-23 Audit Quality Inspection found that some firms used walkthroughs as the sole evidence of control operating effectiveness without performing separate tests of controls under ISA 330.8 . A walkthrough tests design and confirms understanding. Operating effectiveness requires a sample-based test over the period of reliance.

Related content

• Glossary: Test of controls clarifies the ISA 330.8 distinction between control design evaluation (performed during a walkthrough) and operating effectiveness testing (performed on a sample over the period of reliance).
• ISA 530 Sampling Calculator sizes your control testing sample once the walkthrough confirms the control is designed effectively and you’ve decided to rely on it.

Research decision: Base knowledge sufficient. ISA 315 (Revised 2019) is effective and stable. The walkthrough procedure is evergreen methodology content. AFM and FRC references are from known inspection cycles.

Post type: Application post

Related ciferi content

Related guides:

Put audit concepts into practice with these free tools:

Frequently asked questions

Further reading and source references

• IAASB Handbook 2024: the authoritative source for the complete ISA 315 (Revised 2019) text, including the walkthrough application material at A178.
• ISA 330 , The Auditor’s Responses to Assessed Risks: tests of controls that follow a successful walkthrough.
• ISA 530 , Audit Sampling: sample size requirements for control testing once the walkthrough confirms design effectiveness.
• ISA 265 , Communicating Deficiencies in Internal Control: reporting the control deficiencies your walkthrough identifies.