How to Perform a Walkthrough Test Under ISA 315

Key Takeaways

ISA 315.A178 describes the walkthrough procedure: tracing a transaction from origination through the information system to its reflection in the financial records. The purpose is to confirm your process understanding, not to test operating effectiveness.
A walkthrough is not a test of controls. ISA 330.8 governs operating effectiveness testing and requires a sample-based test over the period of reliance. Confusing the two is one of the most common inspection findings.
Select a transaction that interacted with the controls you plan to rely on, ideally with a non-routine element. A clean, typical transaction tells you only that the process works when everything goes right.
Document the walkthrough during the procedure, not from memory afterwards. A working paper reconstructed three days later reads like a process narrative, not a record of a procedure performed.

You’re sitting in the client’s office with a process narrative that was copied from the prior year file. The narrative says three-way matching happens before every payment. You ask the AP clerk to show you the last invoice she processed. She pulls it up, and there’s no goods receipt attached. “Oh, we stopped doing that in June,” she says. That prior year narrative just became your biggest risk. A walkthrough would have caught this in the first week of interim, before you built your control reliance strategy on a control that no longer operates.

A walkthrough test under ISA 315.A178 traces a single transaction from origination through to recording in the financial statements (including IT processing steps) to confirm that the auditor’s understanding of the process and the controls within it is accurate, identifying design deficiencies and points where controls may not operate as described.

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 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.

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. 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.

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.

Document the two procedures separately in your file. The walkthrough belongs in your risk assessment working papers alongside your process understanding. The test of controls belongs in your response working papers. Mixing them into a single working paper is how the confusion starts, and it’s 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.

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. 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, chosen deliberately

One transaction per walkthrough. That’s the point. But choose it deliberately. The quality of your walkthrough depends entirely on the transaction you select. Select it before arriving at the client site. Don’t ask the client to select it for you.

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, automated posting), 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.

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? 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. 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 working paper should be completed during the walkthrough, not reconstructed from memory afterwards. This is the most common documentation failure. A working paper prepared three days after the walkthrough reads like a process narrative, not like a record of a procedure performed. Reviewers can tell the difference.

Your working paper 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 working paper doesn’t reflect the procedure ISA 315 describes.

For the IT processing steps, document the application name, the function it performs, and whether you observed the system performing the function during the walkthrough or relied on the entity’s description. 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 working paper 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 prior year 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, changed the AP team structure, or shifted from manual to automated matching, the prior year narrative is outdated and so is any control reliance built on it.

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.

Step 1: Purchase requisition

The warehouse manager (Jan de Vries) raised the requisition in SAP on 8 August 2024. The requisition referenced stock levels and the reorder point report from SAP MM module. De Vries confirmed that requisitions above €25K require department head approval before conversion to a purchase order.

Documentation note: Record the requisition number (REQ-2024-6221), the approver (department head K. Bakker), and the SAP approval timestamp. Confirm this matches the approval matrix in your process narrative.

Step 2: Purchase order creation and approval

The procurement officer (Lisa Mulder) converted the requisition to PO-2024-3847. Because the amount (€47,200) is below the €50K enhanced approval threshold, the system routed it through the standard one-level approval. Mulder confirmed that POs above €50K require CFO sign-off in addition to department head approval.

Documentation note: Record whether the system correctly classified this PO against the approval threshold. Note that this transaction does not test the enhanced approval control. Flag that a separate walkthrough or inquiry is needed to confirm the €50K threshold control exists and is configured correctly in SAP.

Step 3: Goods receipt (two partial deliveries)

First delivery received 19 August 2024 (€31,400 of the €47,200 order). Warehouse staff (T. Hendriks) entered goods receipt GR-2024-8103 in SAP. Second delivery received 26 August 2024 (€15,800). Goods receipt GR-2024-8247 entered by the same staff member. Both receipts were matched to the purchase order automatically by SAP’s MM module.

Documentation note: Record both GR numbers and the automatic matching confirmation. Note that the partial delivery scenario tests whether SAP correctly matches partial receipts to the full PO amount. This is a design question: can the system release payment on a partial receipt? Mulder confirmed SAP blocks payment until cumulative receipts match the PO line value within a 2% tolerance.

Step 4: Invoice receipt and three-way matching

Invoice received from Schmidt Armaturen GmbH on 2 September 2024 for €47,200. AP clerk (R. Visser) entered the invoice in SAP. The system performed automatic three-way matching: PO amount (€47,200) matched invoice amount (€47,200) and cumulative goods receipts (€31,400 + €15,800 = €47,200). Match confirmed. SAP flagged the invoice as “ready for payment.”

Documentation note: Record the SAP matching output screen. Note whether the match is fully automated or requires manual confirmation. Visser confirmed that matched invoices below €50K proceed to the payment run without manual approval. Ask: what happens when the match fails? Visser stated that mismatches go to a pending queue reviewed weekly by AP supervisor M. de Groot.

Step 5: Payment

Payment batch processed on 10 September 2024. The payment was included in the weekly payment run approved by the financial controller (S. van Dijk). Van Dijk confirmed she reviews the payment run report (list of payees and amounts) before releasing the batch in the bank portal.

Documentation note: Record the payment run reference and van Dijk’s approval evidence. Assess: is this control designed effectively? Van Dijk reviews a summary list, not individual invoices. The control addresses completeness of the payment run (no unauthorised additions) but does not address accuracy of individual payments (that’s the three-way matching control). Document both controls and their respective design assessments.

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

Select the transaction before arriving at the client site. Choose one that interacted with the controls you plan to rely on, ideally with a non-routine element (close to an approval threshold, partial delivery, period-end timing). Don’t ask the client to select it for you.
Bring your current process narrative and mark each step as you confirm it. Any step you can’t confirm during the walkthrough either doesn’t exist or doesn’t operate as documented.
Talk to the person who performs each step. Don’t rely on documentation alone. Ask what happens when the normal process doesn’t work (exception handling). ISA 315.A178 specifies inquiry combined with observation.
Document the IT application at every system-dependent step: name, function, and whether the control is automated (system-enforced) or IT-dependent manual (the system generates a report, but a person reviews it). This feeds directly into your IT general controls assessment under ISA 315.26.
Assess control design at each control point during the walkthrough, not afterwards. If the control wouldn’t prevent or detect the relevant misstatement even when operating perfectly, that’s a design deficiency you need to document before moving to control testing.
Update your process narrative the same day the walkthrough is completed. If you wait, the corrections you identified will be lost in your notes and the prior year narrative will persist unchanged into the current year file.

Common mistakes regulators flag

The AFM’s 2022 inspection cycle identified files where the walkthrough working paper contained no evidence of inquiry with entity personnel. The working paper 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.

Frequently asked questions

What is a walkthrough test under ISA 315?

A walkthrough test under ISA 315.A178 traces a single transaction from origination through to recording in the financial statements, including IT processing steps, to confirm that the auditor’s understanding of the process and the controls within it is accurate. The purpose is to identify design deficiencies and points where controls may not operate as described in the process narrative.

What is the difference between a walkthrough and a test of controls?

A walkthrough under ISA 315.A178 confirms your understanding of the process and assesses control design by tracing one transaction. A test of controls under ISA 330.8 tests whether the control operated effectively throughout the period by examining a sample. The walkthrough belongs in your risk assessment working papers; the test of controls belongs in your response working papers. A walkthrough alone cannot provide evidence of operating effectiveness.

How do you select the right transaction for a walkthrough?

Don’t pick the cleanest, most typical transaction. Select one that interacted with the controls you care about. For purchase-to-pay, choose an invoice near an approval threshold or from a busy period. For revenue, choose a transaction with a non-standard element such as a discount, partial delivery, or credit note. One transaction per walkthrough, but choose it deliberately.

When should walkthroughs be performed during the audit?

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. Performing the walkthrough at year-end forces you to redesign your audit approach under time pressure if you discover a design deficiency.

What common mistakes do regulators flag in walkthrough documentation?

The AFM’s 2022 inspection cycle identified files where the walkthrough working paper contained no evidence of inquiry with entity personnel, reading as a document review rather than a walkthrough. The FRC 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.