The distinction between control testing and substantive testing matters to how you structure evidence collection, size your samples, document your procedures, and ultimately conclude on financial statement assertions. It's also a distinction that gets treated loosely in practice, which tends to produce workpapers that don't clearly support either type of conclusion.
This is a practical explanation of what each approach tests, how they relate to each other, and how that relationship should shape your workpaper documentation. It's not an introduction to audit methodology. If you're reading this, you already know the basics. This is about the specific implications for evidence collection and documentation structure that follow from treating the approaches as distinct, and from understanding the dependency between them.
What Control Testing Actually Tests
Control testing, also called tests of controls, evaluates whether a control is operating effectively over a period of time. The objective is not to determine whether any given transaction is correct. It's to determine whether the mechanism designed to prevent or detect errors in a defined population of transactions is working as designed.
Two questions need to be answered in a control test, and they are separate questions. The first is test of design: is the control designed appropriately to prevent or detect the error type it is supposed to address? A control can be well-designed but not operating, and it can be operating but poorly designed. Design testing typically involves walkthroughs, inquiry, and inspection of the control documentation. It confirms that the control as described would work in theory.
The second is test of operating effectiveness: is the control actually operating as designed, consistently, throughout the test period? This requires evidence that the control ran, evidence that it ran correctly on instances sampled from the population, and evidence that exceptions, when they occurred, were handled through the control's defined exception process. Operating effectiveness testing is where your sample selection, population documentation, and tickmark procedures matter.
A workpaper that conflates these two questions, that documents a walkthrough as if it covers operating effectiveness, or that tests operating effectiveness without documenting the population for completeness, creates a gap that reviewers will catch but that also represents a genuine deficiency in what the workpaper actually supports.
What Substantive Testing Tests
Substantive testing addresses financial statement assertions directly. Rather than asking whether the control is working, it asks: does this account balance, transaction, or disclosure accurately represent what it purports to represent?
Substantive procedures include substantive analytical procedures, which test the reasonableness of balances or transactions by comparing them to expectations derived from other data, and tests of details, which trace specific transactions or balances to underlying evidence. An accounts payable cutoff test that compares invoice dates to period-end accruals is substantive. An analytical procedure comparing current-period expense to prior-period expense adjusted for known changes is substantive. Reperforming an account reconciliation by tracing each line to a supporting schedule is substantive.
The critical thing about substantive testing is that it directly addresses the assertion, without relying on the assumption that a control prevented misstatement. If you trace a $2.4 million accounts payable balance to individual vendor invoices and confirm that each one represents a valid obligation recognized in the correct period, you have substantive evidence about the completeness and cutoff assertions on that balance. You haven't tested whether the AP review control prevented errors from entering the population. That's a separate question.
The Dependency: How Control Effectiveness Shapes Substantive Testing Scope
This is the part of the distinction that matters most to engagement planning, and the part that is most often misunderstood in workpaper documentation.
When controls are tested and found to be operating effectively, the auditor can reduce the scope of substantive testing. If the three-way match control for purchase transactions is operating effectively, the auditor has evidence that errors in individual invoice matching would have been caught by the control. This supports reducing the sample size in a test of details over accounts payable transactions, because the control provides some detection coverage over the same assertion.
When controls are not tested, or when they are tested and found to have exceptions that suggest unreliable operation, the substantive testing scope expands. The auditor cannot rely on the control to have caught errors, so the substantive evidence needs to cover more of the assertion independently.
This dependency is not a choice between two testing approaches. It's a planning decision that affects how much substantive work is required given the control reliance strategy chosen at the start of the engagement. An audit program that tests controls and finds them effective reduces the substantive burden. An audit program that relies entirely on substantive procedures, by design or because control testing found weaknesses, requires more extensive direct evidence over account balances and transactions.
Workpapers need to make this dependency visible. If control reliance was part of the strategy and control testing results were satisfactory, the workpaper documentation should connect those two things: here is the control that was tested, here is the result, and here is how that result supports the reduced substantive scope. A workpaper that documents a narrow substantive test without showing the control results it was scoped against will raise review questions about whether the substantive evidence is sufficient on its own.
Evidence Collection Structures for Each Approach
Control testing and substantive testing require different evidence, and that difference should shape how you structure evidence requests before the cycle begins rather than during fieldwork.
For control testing, the evidence you need includes: the population the control ran against (often a system report confirming completeness), samples from that population showing the control's execution, evidence of exception handling for any instances where the control identified an issue, and documentation of who performed the control and when. For IT general controls specifically, you typically also need access logs, change management approvals, and user provisioning or deprovisioning records that demonstrate the control ran in the defined configuration.
For substantive testing, the evidence structure is assertion-specific. For existence and occurrence, you need documentation that the recorded transactions actually happened. For completeness, you need evidence that all transactions that should be recorded are recorded, which often requires working from an external source rather than the population in the system. For valuation, you need support for how the balance was measured. For cutoff, you need evidence about the period in which transactions were recognized relative to when they occurred.
The practical implication is that your PBC list should be organized around these requirements before fieldwork starts. A PBC request that asks for "access controls documentation" is ambiguous. A PBC request that asks for the Q1 user provisioning log (complete population), the access review results for Q1 with disposition of access removals, and the access authorization matrix current as of January 1 is specific enough that the evidence, when it arrives, maps directly to the control test being performed.
Where Documentation Gets Confused
The workpaper errors that arise from conflating control testing and substantive testing tend to cluster in a few predictable places.
First, using walkthrough documentation to support operating effectiveness conclusions. A walkthrough traces one transaction through a process to confirm the control design. It supports a test of design conclusion. It does not support an operating effectiveness conclusion because it doesn't sample across the period. Using walkthrough documentation in a workpaper as the basis for "no exceptions identified" over a quarterly population is a documentation deficiency, regardless of whether the control was actually operating effectively.
Second, citing control effectiveness to reduce substantive scope without documenting the control results in the workpaper chain. If your accounts receivable test of details uses a smaller sample because the revenue recognition control was tested and found effective, that logic needs to be visible somewhere in the workpaper package, typically as a reference from the AR workpaper to the revenue control workpaper.
Third, running a substantive test over a population that was selected using the same criteria as the control test population. The control test and the substantive test are asking different questions, and the populations should be selected independently for each. Using the same sample for both creates a documentation problem: the workpaper can't clearly show what each test concluded and on what basis.
A Note on Management Review Controls
Management review controls (MRCs) are a category that sits across both approaches in ways that create documentation complexity. An MRC is a control performed by management, typically a review of a financial report or variance analysis, that is designed to detect misstatements in an account balance or process.
Testing an MRC requires evidence of more than just that the review happened. For the control to be considered effective at the financial reporting level, the workpaper needs to support that the review was conducted with sufficient precision to detect a material misstatement. This means documenting the inputs to the review, the criteria management used to evaluate the results, and how exceptions were investigated. A signature on a review form is not sufficient evidence that an MRC operated effectively for SOX purposes. The precision and completeness of the review process itself has to be supported.
This is an area where the control testing and substantive testing distinction matters acutely. Testing the MRC control addresses whether management's review process would detect a misstatement. Substantive testing of the underlying account addresses whether a misstatement exists regardless of whether the review would catch it. Both may be required depending on the risk assessment for the account and the reliance strategy chosen.