Walkthrough vs Test of Controls: Different Evidence

A walkthrough and a test of controls look similar from the outside. Both involve an auditor, a control owner, a transaction and some documents, and both end in a workpaper that says the control was examined. They answer different questions, and treating one as the other is one of the most common and least noticed defects in an internal audit file. The walkthrough asks whether the auditor understands the process and whether the control, as designed and implemented, would achieve its objective. The test of controls asks whether the control actually operated, as designed, throughout the period, on the population it covers. The first is answered by following one transaction end to end with the people who handle it. The second is answered by evidence from many instances across time, selected in a way that supports a conclusion about the instances not examined. Walking through five transactions is a longer walkthrough; it is not a test, and this guide explains why, when each is enough, what evidence each produces, and how to plan the boundary between them, with a decision table, a walkthrough-to-test bridge template and a worked example at a distributor whose walkthroughs had looked fine.

In this guide

Two questions, two kinds of evidence
What a walkthrough proves, and what it cannot
What a test of controls proves, and what it costs
The evidence each procedure leaves behind
Making the walkthrough count
What the standards say
Why five transactions is still a walkthrough
When a walkthrough is enough
When it is not
Planning the boundary: the decision table
The walkthrough-to-test bridge
The bridge record template
Worked example: MidState Beverage’s depot reconciliations
Common mistakes
Related guides

Two questions, two kinds of evidence

Every control has three properties an auditor might want to conclude on. Its design: if performed as described, would it prevent or detect the misstatement or failure it exists for? Its implementation: has it been put in place, so that it exists in practice and not only in the procedure manual? And its operating effectiveness: did it operate, as designed, consistently, by someone competent, across the period and the population? The first two are properties of the control at a point in time, and they can be established by examining one instance thoroughly with the people who perform it. The third is a property of the control over time, and it cannot be established by any single instance, however carefully examined, because a control that operated once may not have operated the other 249 times, and the auditor’s conclusion has to extend to those other times.

That is the whole distinction, and the two evidence types follow from it. A walkthrough produces evidence about design and implementation: the auditor follows one transaction from origination to its final record, using the same documents and systems the staff use, asking the people at each step what they do and what would happen if the step were skipped, and observing the control being performed or its recent output. The evidence is rich about that instance and about the process, and thin about frequency. A test of controls produces evidence about operation: the auditor selects instances from the period, ideally in a way that gives every instance a chance of selection, examines each for the attributes that define the control, and draws a conclusion about the population from the sample. The evidence is thin about any one instance and strong about the pattern. The design versus operating effectiveness guide covers the two conclusions in detail; this guide is about the procedures that reach them and the line between the two.

What a walkthrough proves, and what it cannot

A well-performed walkthrough proves five things. That the auditor’s understanding of the process is right, which is the precondition for every other conclusion. That the control described in the matrix exists where and how it is described, or that the description is wrong, which walkthroughs discover constantly. That the control’s design addresses the risk: the auditor, standing at the step, can ask what would happen if a wrong amount, a wrong vendor or a missing approval came through, and can see whether the step would catch it. That the control was performed on the instance walked through, by the person who is supposed to perform it, who could explain it. And that the information the control uses comes from where the description says, which is where the IPE questions begin. Those five outcomes are why the walkthrough is the heart of planning and of the design test, and why the process walkthrough guide and the walkthrough documentation template exist.

What the walkthrough cannot prove is anything about the instances the auditor did not see. It cannot show that the control operated in months when the performer was on leave, on transactions that came through a different path, in the depot the auditor did not visit, or at the quarter-end when the volume tripled. It cannot show consistency, because consistency is a property of a series. And it cannot show that the control operated when nobody was watching, because the walkthrough is, by construction, observed. A walkthrough conclusion that reads “the control is operating effectively” has claimed something the procedure did not test, and a reviewer should strike it and replace it with what the procedure supports: designed appropriately and implemented as of the walkthrough date.

What a test of controls proves, and what it costs

A test of controls proves operation across the period, to a stated level of assurance, provided three conditions hold. The population is complete: the instances were selected from all the occasions the control should have operated, established by reconciling the population to an independent source as the IPE testing guide requires. The selection supports extrapolation: for a frequent control, a random or systematic sample of the size the sample sizes guide sets out; for an infrequent control, all or most of the instances. And the attributes tested are the control’s defining elements, not the existence of a signature, with each instance examined against each attribute and the exceptions evaluated rather than explained away. The cost is real: a daily control needs 20 to 40 instances examined, an annual control needs its one instance examined end to end, and the evidence for each has to be retained. The cost is why auditors are tempted to let the walkthrough stand in for the test, and the temptation is strongest when the walkthrough went well, which is exactly when the file most needs the discipline.

A test also proves less than auditors sometimes claim. A clean sample of 25 daily instances at 90 percent confidence and a 10 percent tolerable deviation rate supports the conclusion that the control’s deviation rate is probably below 10 percent; it does not prove that no deviation occurred, and a control with one deviation in 25 has not necessarily failed. The judgmental sampling guide and the sampling memo template cover how the design and the conclusion are documented so that the claim matches the evidence.

The evidence each procedure leaves behind

The difference is easiest to see in the workpapers. The table compares what each procedure examines, the evidence it retains, how far the conclusion reaches and what it costs, for a typical daily manual control such as a reconciliation or an approval.

Dimension	Walkthrough	Test of controls
Question answered	Is the process understood, and would the control work as designed and implemented?	Did the control operate as designed across the period and population?
Instances examined	One per branch, chosen for coverage of paths, usually recent	A sample selected from the period’s population by a stated method, or the whole population for infrequent controls
Procedures	Inquiry-led, with observation, inspection and re-performance on the instance	Inspection and re-performance on each instance against defined attributes; inquiry only to resolve exceptions
Who is present	The performer, explaining each step	Nobody; the auditor works from retained evidence and re-performs independently
Retained evidence	Narrative or flowchart, the instance’s documents, screenshots, the auditor’s design evaluation and “what if” questions	Population record and completeness check, selection method, attribute matrix with results per instance, exception evaluation
Reach of the conclusion	The control as of the walkthrough date	The period sampled, at the stated confidence and tolerable deviation rate, for the strata sampled
What it finds most	Descriptions that do not match practice; controls that exist on paper only; design gaps; IPE dependencies	Inconsistent performance; absent performers; period-end shortcuts; variants by site or person
Typical effort (daily control)	Two to four hours per branch including documentation	Eight to twenty hours for a 25-instance sample with re-performance, more where evidence must be reconstructed
Conclusion the file may state	Designed appropriately and implemented (or not)	Operating effectively (or not) for the period

Making the walkthrough count

Because the walkthrough cannot reach operation, the temptation is to treat it as a formality before the real work. The opposite is true: a walkthrough that is done with intent shapes the test and often finds the deficiency before any sample is drawn. Six practices raise its value. Select the transaction yourself, from the population, before the meeting, and ask for that one rather than accepting the example on the performer’s desk. Walk each branch the process has, and ask at every step what happens when the branch is different, which is how the non-PO invoice, the manual payment and the acquired unit’s variant come to light. Ask the “what if” questions at each control point: what if the amount were wrong, the vendor unknown, the approver absent, the report late; the answers are the design evaluation. Re-perform the control on the instance rather than watching it described: recompute the reconciliation, re-check the match, re-run the report, because re-performance on one instance is stronger evidence of design than any explanation. Look at the evidence the performer keeps for last month’s instances while you are there, which previews whether an operating test can inspect or must re-perform, and whether retained instances exist. And write down what surprised you, in the observation field, because the surprise is usually the attribute the test should concentrate on, as the worked example below shows.

Timing also matters more than most plans allow. A walkthrough performed during planning, months before the operating test, needs a short refresh before testing if the process may have changed, and a walkthrough performed after a control was remediated is the design test of the new control, not a formality; it should be performed on an instance after the remediation date, with the changed elements evaluated afresh, before any re-test sample is drawn.

What the standards say

The clearest statement of the boundary is in PCAOB AS 2201, which governs audits of internal control over financial reporting and which SOX programs adopt by reference. Its walkthrough paragraphs describe following a transaction from origination through the company’s processes, including information systems, until it is reflected in the financial records, using the same documents and information technology that company personnel use, with a combination of inquiry, observation, inspection and re-performance, and questioning personnel about what the procedures require and what happens when they are not followed. Its design-effectiveness paragraph says that walkthroughs including those procedures are ordinarily sufficient to evaluate design effectiveness. Its operating-effectiveness paragraphs say something different: the auditor tests operating effectiveness by determining whether the control is operating as designed and whether the person performing it has the necessary authority and competence, and the auditor must test controls over a period of time sufficient to support the conclusion as of the assessment date. The word “period” is the boundary. Design is a point; operation is a span.

The Global Internal Audit Standards frame the same distinction less mechanically. Standard 13.6 requires a work program that specifies the procedures for gathering evidence to achieve the engagement objectives, and Standard 14.1 requires information that is relevant, reliable and sufficient for the analyses and evaluation, with sufficiency meaning enough that a prudent, informed person would reach the same conclusion. A walkthrough is sufficient for a conclusion about design; it is not sufficient for a conclusion about operation over a year, because a prudent person would not conclude from one instance that the other instances behaved the same. The audit evidence guide works through the reliability hierarchy that puts re-performance and inspection of a series above the observation of one, and the GIAS Domain V guide covers the engagement standards the boundary sits inside.

Why five transactions is still a walkthrough

The instinct to walk through several transactions comes from a real concern: one transaction might be unrepresentative, so follow a few. That is good walkthrough practice, especially where a process has branches (a PO invoice and a non-PO invoice; a domestic and a foreign payment; a standard order and a rush order), and the auditor should walk each branch. What it does not do is turn the walkthrough into a test, for four reasons. The transactions are chosen by the auditor or, worse, by the process owner, on the day, for convenience or coverage of branches, not selected from the period’s population by a method that gives each instance a chance; they cannot be extrapolated. They are examined in the presence of the performer, who explains each step, which is inquiry-heavy evidence about design rather than inspection of unobserved operation. They are usually recent, because recent transactions are easiest to find, so they say nothing about the first three quarters. And they are five, which at any confidence level supports a conclusion only about a very small population or a very high tolerable deviation rate. Five branches walked through is a thorough design test. Five instances inspected is a test of operation only for a control that operates about five times a year.

There is one situation in which the two converge honestly: the annual or quarterly control. A control that operates four times a year has a population of four, and examining two of them end to end, from the period’s own population, with attributes and evidence, is both a walkthrough and a test, because the sample sizes for infrequent controls are coverage-based and the instances are the population. The workpaper should still say which conclusion it is drawing and on what basis, and should still select the instances from the period rather than taking the one on the performer’s desk.

When a walkthrough is enough

A walkthrough is the right and sufficient procedure in five situations. When the engagement objective is design: a pre-implementation review, a process design assessment, a consulting engagement on a new control, or the design half of a SOX test, where the question is whether the control would work rather than whether it did. When the engagement is scoping: the risk assessment and planning phases need understanding, and understanding comes from walkthroughs, not tests. When the control is automated and the walkthrough includes the configuration inspection and a test of one, with the general controls tested separately; the automated controls testing guide and the control classification guide explain why one instance is enough for a control the system performs identically every time. When the control is infrequent enough that the walkthrough instance is a meaningful share of the population, as above. And when the auditor is relying on someone else’s operating test, under the reliance provisions of the Standards, and performs a walkthrough to confirm that the control being relied on is the one that was tested.

When it is not

A walkthrough is not enough whenever the conclusion is about operation over a period for a manual or IT-dependent manual control, which describes most key controls in a SOX program and most controls an operational audit rates. It is not enough when the control is performed by many people or at many locations, because design that varies by performer or site is the commonest finding and a single walkthrough sees one variant. It is not enough where the process has known seasonality or period-end pressure, because the instance walked through in a quiet week says nothing about the last week of the quarter. It is not enough where the engagement will rate the control or the process, because a rating is a claim about operation. And it is not enough where the walkthrough itself raised doubt: a performer who could not explain the step, an instance where the control was performed late, or a description that did not match practice, each of which is a reason to test rather than a reason to walk through a second transaction.

Planning the boundary: the decision table

Engagement question	Control nature and frequency	Procedure	Conclusion the file may state
Do we understand the process? Where could it fail?	Any	Walkthrough of each branch with the performers	Understanding documented; risks and controls identified
Would the control work if performed as described?	Any	Walkthrough with inquiry, observation, inspection of one instance, re-performance where feasible	Designed appropriately (or not) and implemented as of the date
Did the control operate through the period?	Manual or IT-dependent manual, daily or more frequent	Walkthrough for design, then a sample of 20 to 60 instances across the period, attributes tested, IPE tested	Operating effectively (or not) for the period, at the stated confidence and tolerable rate
Did the control operate through the period?	Manual, weekly or monthly	Walkthrough, then 5 to 15 (weekly) or 2 to 5 (monthly) instances from the period	Operating effectively for the period on a coverage basis
Did the control operate through the period?	Manual, quarterly or annual	Walkthrough and test converge: all or most instances from the period examined end to end	Operating effectively for the period; the instances are the population
Did the control operate through the period?	Automated	Walkthrough including configuration inspection and a test of one per code path; ITGCs tested for the period	Operating effectively, contingent on the ITGC conclusion
Did the control operate at every location or for every performer?	Manual, multi-site or multi-performer	Walkthrough at a sample of sites to establish design variants; test sample stratified by site or performer	Operating effectively by site; design variants reported
Can we rely on someone else’s testing?	Any	Walkthrough to confirm the control tested is the control relied on; evaluate the other party’s work under the reliance standard	Reliance placed, with the basis documented

One more consequence follows for how findings are written. A design deficiency found in a walkthrough is reported as a design deficiency, with the design point named, and its remediation is a change to the control. An operating deficiency found in a test is reported with the count, the rate and the pattern, and its remediation is a change to how the control is performed or supervised. Reports that blur the two produce action plans that fix the wrong thing: a control redesigned because three instances were performed late, or a performer retrained because the control could never have caught the error. The deficiency evaluation guide starts from the same design-or-operation question, and the boundary between walkthrough and test is where the answer is first decided.

The walkthrough-to-test bridge

The two procedures are done well when the walkthrough is designed to feed the test, and the bridge is a short set of decisions made at the end of each walkthrough and recorded before the test is designed. The first decision is the conclusion the walkthrough supports, stated in its own terms: design appropriate or deficient, implemented or not, with the specific design points (the threshold, the reviewer’s independence, the information source, the timing) recorded as attributes. The second is the population definition: the walkthrough is where the auditor learns what the control operates on, how often, from which system, at which locations, and the population record is drafted from that knowledge rather than from the matrix. The third is the branch list: every path the walkthrough found (PO and non-PO, domestic and foreign, each depot’s variant) becomes a stratum or a separate control in the test design. The fourth is the attribute list: the elements the walkthrough established as the control’s design become the attributes the test examines, so that the test tests the control as it exists rather than as the matrix describes it. And the fifth is the evidence expectation: the walkthrough shows what evidence the performer keeps, which decides whether the test can inspect or must re-perform, and whether the retained instances the IPE testing guide needs actually exist.

Three signals in a walkthrough change the test design rather than merely feeding it. A control whose performance depended on the performer’s judgment in a way the description did not capture becomes a review control tested as the management review controls guide describes, with re-performance in the sample. A control that the walkthrough found performed differently from the description is re-described first, and the test is against the re-description, with the discrepancy reported as a documentation finding. And a control that the walkthrough found not performed at all on the instance walked through is a design or implementation deficiency now, not a test result later; the auditor does not proceed to sample a control that failed the walkthrough without recording that it did.

The bridge record template

One record per control, completed at the end of the walkthrough and referenced from the test workpaper. It sits between the walkthrough documentation template and the sampling memo template and is the document that shows a reviewer why the test was designed the way it was.

Walkthrough-to-test bridge record

1. Control. Reference and description as documented; description as observed (differences noted); nature (manual, automated, IT-dependent manual); frequency; performers and locations.

2. Walkthrough conclusion. Instance(s) walked through with dates and branches covered; design conclusion (appropriate / deficient, with the design point at issue); implementation conclusion; walkthrough procedures used (inquiry, observation, inspection, re-performance); evidence retained.

3. Population. What the control operates on; source system or record; expected count for the period; independent source for the completeness check; branches and strata.

4. Attributes for the operating test. The design elements to be tested on each instance (performer role, timing, threshold, information source and its IPE reference, review evidence, exception handling); the attribute the walkthrough found weakest.

5. Test design decision. Walkthrough sufficient (reason: objective is design / automated with test of one / infrequent control / reliance) OR operating test required; sample size and selection method by frequency and stratum; inspection versus re-performance; timing (interim, roll-forward).

6. Signals. Judgment-dependent (treat as review control); description mismatch (re-described); not performed on the walkthrough instance (deficiency raised now); multi-site variants (stratify).

7. Sign-off. Preparer, reviewer, dates; cross-references to the walkthrough workpaper and the test workpaper.

Worked example: MidState Beverage’s depot reconciliations

MidState Beverage, the illustrative three-state drinks distributor used across this site, runs 300 routes from 12 depots and collects about $31 million a year in cash and checks from roughly 4,200 customers, which is why the daily depot reconciliation of driver settlements to deposits is the key control in its route cash process. The FY27 route cash audit, reported as FY27-01, is the site’s standing example of the walkthrough-to-test boundary because of what happened between the two procedures. The team began with walkthroughs at three depots, chosen for size and proximity: the depot administrator walked the senior auditor through the previous day’s settlement, the reconciliation to the deposit slip, the supervisor’s review and the entry into the route-accounting module, on one day’s transactions at each depot. All three walkthroughs concluded that the control was designed appropriately and implemented, and one of the three noted, in the observation field, that the reviewing supervisor had also prepared part of the reconciliation because the administrator had been out.

Had the engagement stopped there, or walked through two more depots, the report would have said the reconciliation control operated. The bridge record said otherwise. The population was 12 depots times roughly 250 business days, about 3,000 reconciliations; the branches were the depots themselves, because the walkthroughs had already shown the procedure varied by site; the attribute the walkthrough found weakest was the independence of the reviewer; and the test design was a stratified sample of 60 reconciliations, five per depot, drawn from the year, inspected for preparer, reviewer, evidence of review, timing and agreement to the bank deposit, with re-performance of the reconciliation itself on each. The test found 14 of the 60 failed at least one attribute, and the pattern was the finding: at nine of the twelve depots the reconciliation was not independently reviewed, either because the supervisor prepared it, because the administrator reviewed their own work, or because the review was a signature applied in a batch at week-end. The three walkthrough depots included two of the three where the control worked. The finding became F1, rated High, in a report whose overall opinion was Unsatisfactory, and the 60-item sample, with its 14 exceptions and the by-depot breakdown, is what made the rating defensible when the operations director pointed out that the auditors had seen the control work with their own eyes.

Procedure	What it examined	What it supported	What it would have missed
Walkthroughs at three depots	One day’s reconciliation at each, with the performers, on the day	Understanding of the process; design appropriate; implemented at three sites; a noted independence concern at one	The nine depots with variant practice; the batch signatures at week-end; the periods when administrators were absent
Stratified test of 60 reconciliations	Five per depot across the year, inspected and re-performed	Operation by depot; the 14 exceptions; the independence pattern at nine depots; the High rating	Nothing the engagement needed; the design understanding came from the walkthroughs

Two features of the example are worth copying. The walkthrough observation about the supervisor preparing the reconciliation was recorded as a signal, not dismissed as a one-off, and it chose the attribute the test concentrated on. And the test was stratified by the branch the walkthrough revealed, which is what turned 14 exceptions into a finding about nine depots rather than a deviation rate about a population; a simple random sample of 60 across all depots would have found roughly the same exceptions and said much less. The internal audit report examples guide shows the FY27-01 report the test produced, and the root cause analysis guide the step from the pattern to the reason: the depot administrator role had been designed for one person, and no depot had a second.

Common mistakes

Concluding “operating effectively” from a walkthrough. Walking through the transaction the performer has ready instead of one the auditor selected. Walking through one branch of a multi-path process and describing the process as if it had one. Treating five walked-through transactions as a sample, or a sample of five recent transactions as a test of the year. Skipping the walkthrough because the control was tested last year, then testing a control that changed. Testing attributes from the matrix description when the walkthrough showed the control is performed differently. Sampling a control that failed its own walkthrough instead of raising the deficiency. Ignoring multi-site variation, then reporting a rate about a population that contains twelve different controls. Letting the walkthrough’s good impression set the sample size, when the standards set it by frequency and risk. And filing the walkthrough and the test as unrelated workpapers with no record of how the first shaped the second, which is the gap the bridge record fills. The substantive testing guide covers the third procedure that neither of these is, testing balances and transactions directly, and the audit work program guide shows where all three sit in the program.

Comments

Leave a Reply Cancel reply

Dark Towers by David Enrich: Summary and Lessons for Auditors

Blind Spots by Bazerman and Tenbrunsel: Summary and Lessons for Auditors

Black Box Thinking by Matthew Syed: Summary and Lessons for Auditors

The Field Desk Series

Walkthrough vs Test of Controls: Different Questions, Different Evidence