What is a walkthrough test?
On about half the files we've reviewed, the walkthrough is the weakest section. The team copies the process narrative from the prior year and signs off. No one actually sat with the accounts payable clerk. No one traced a real transaction. The walkthrough becomes a tick box exercise, and the risk assessment built on top of it inherits the gap.
A walkthrough test is a risk assessment procedure, not a test of controls. ISA 315 (Revised 2019).25 requires the auditor to understand the entity's information system, including how transactions are initiated, recorded, processed, and reported. Paragraph A32 specifically identifies tracing transactions through the information system as a procedure to obtain that understanding.
You pick one transaction. Not a sample. One. You follow it from the moment it enters the system to the point it appears in the general ledger and the financial statements (FS). Along the way, you identify each control point, ask the person who performs the control to describe what they do, observe the evidence the control produces, and compare it all to the process flow in your working papers (WPs). If the WPs do not match what you see during the walkthrough, the documented understanding is wrong and the risk assessment built on it is unreliable.
This is where the distinction matters. A walkthrough does not tell you whether the control worked 500 times during the year. It tells you whether the control exists, who performs it, what evidence it leaves, and whether your documentation reflects reality. This doesn't mean walkthroughs are optional fieldwork. It means they are the foundation that every other test of controls sits on. If you plan to rely on a control, you still need tests of controls under ISA 330.8 .
Key Points
- A walkthrough confirms your understanding of a process and its controls; it does not test whether those controls operated effectively.
- ISA 315 (Revised 2019) expects walkthroughs as part of understanding information processing and control activities.
- One transaction, end to end, through the actual system, with the actual people who process it.
- Confusing a walkthrough with a test of controls is the error most likely to weaken your risk assessment.
Why it matters in practice
Worked example: Hoffmann Pharma Handels GmbH
Client: Austrian pharmaceutical distributor, FY2024, revenue €34M, Austrian UGB reporter. Hoffmann distributes pharmaceuticals to hospitals and pharmacies across Austria. The engagement team performed a walkthrough of the sales-to-cash process during planning.
Select the transaction
The team selected a single delivery to Landeskrankenhaus Graz, invoice HF-2024-07221 for €14,800 (48 line items of pharmaceutical products), dated 15 September 2024.
Trace through initiation
The hospital placed the order via Hoffmann's online portal. The order entry clerk confirmed that the system automatically checks product availability, flags controlled substances for additional verification, generates a picking list for the warehouse, and routes narcotics orders to the supervisor queue.
Trace through processing and controls
The warehouse team picked the order. A second warehouse employee verified the pick against the picking list (control point 1: independent verification of pick accuracy). For the three controlled substances, the warehouse supervisor performed an additional check against the narcotics register (control point 2: narcotics reconciliation). The dispatch team scanned each item at loading; the system matched scans to the picking list and generated the delivery note.
Trace through recording
The system generated the sales invoice upon dispatch confirmation. The invoice posted automatically to trade receivables and revenue. The team confirmed the posting in the general ledger and verified that revenue recognition occurred on the dispatch date, consistent with Hoffmann's policy (transfer of risk on delivery to the carrier).
The walkthrough confirmed that the documented process flow matches the actual process. It identified two manual control points and one automated control, which gave the team a basis for designing tests of controls on the pick verification and narcotics register procedures. Without this step, the team would have been doing SALY (same as last year) on a process that had actually changed since FY2023 when Hoffmann migrated its portal to a new vendor.
Key standard references
This is the section of the file that generates the most review notes. Get the citations wrong here and the entire risk assessment chain unravels.
- ISA 315 (Revised 2019).25 requires the auditor to understand the entity's information system, including how transactions are initiated, recorded, processed, and reported.
- ISA 315 (Revised 2019).A32 identifies tracing transactions through the information system (a walkthrough) as a procedure to obtain that understanding.
- ISA 315 (Revised 2019).26 requires the auditor to identify controls relevant to the audit, including the individuals who perform them.
- ISA 330.8 requires tests of controls (not walkthroughs) when the auditor plans to rely on control effectiveness.
Related terms
Related reading
Frequently asked questions
Is a walkthrough the same as a test of controls?
No. A walkthrough confirms your understanding of a process and its controls (risk assessment under ISA 315). A test of controls evaluates whether those controls operated effectively over a sample (fieldwork under ISA 330). A sample of one provides no basis for concluding on operating effectiveness.
How many transactions should a walkthrough cover?
One. You pick one transaction and trace it end to end through the actual system with the actual people who process it. The purpose is to verify the process flow, not to test a population.