Audit Walkthroughs and Tests of Controls Explained

The walkthrough: follow one transaction, start to finish

A walkthrough means understanding how a process really works — not by reading a policy, but by following one transaction from start to finish. A customer places an order, the system checks the credit limit, goods are dispatched with a delivery note, an invoice is raised from the delivery, and cash arrives and is matched to the invoice. At each step, two questions: what could go wrong here, and what stops it? The answer to the second question is a control.

Two different questions: design and operation

• —Design — would it work? If the control operated as described, would it prevent or catch the error?
• —Operation — did it work? Did the control actually operate, every time, throughout the year? A well-designed control that people can switch off isn’t operating.

A worked test that changes everything

Asking what happens when an order exceeds the credit limit: the system warns, and the user clicks override with a reason. Asking who can override: anyone with accounts access, and nobody checks the reason. The control was described as a block. In practice it’s a warning anyone can dismiss — the design sounded good; it doesn’t operate as designed.

A second look at the system access list finds a different problem: one accounts user can create vendors, approve payments, and override credit limits. One person able to create a new supplier and then approve a payment to it is a segregation-of-duties failure — no second pair of eyes stands between a fictitious supplier and a payment.

What a control failure changes

A control that doesn’t operate can’t be relied on — the response is more substantive work in the areas it was meant to protect (here: receivables valuation and payments to suppliers), plus reporting the deficiency. What doesn’t happen: stopping the audit, or pretending the control works because it’s described well on paper.

Three kinds of control

• —Preventive — stops something happening, like a credit limit that blocks an order.
• —Detective — finds it afterwards, like a monthly bank reconciliation.
• —Automated — built into the system, like a rule that won’t post an unbalanced entry. These tend to work the same way every time, provided the setting hasn’t been changed — which is exactly why access rights matter so much.

Segregation of duties: a matrix to check

For each pair below, the same person shouldn’t do both: creating suppliers and approving payments (so no fictitious supplier gets paid); raising purchase orders and receiving goods (so goods aren’t diverted and the receipt falsified); posting journals and approving them (so entries aren’t unreviewed at year end); handling cash and recording receipts (so cash can’t be taken and hidden). In a small team, perfect segregation isn’t always achievable — compensating controls, like independent review, become essential instead.

Testing a control, step by step

Define the control — for example, payments above a threshold must be approved by two people. Get the full population of items subject to the control and check it’s complete. Select items spread across all twelve months, not clustered in one period. Look for evidence the control actually operated — two names, dated before the payment, not after. Conclude: either the control operated, or there were exceptions, and state what they mean.

Testing 25 items spread across the year and finding the control operated every time supports a conclusion about that period — provided the sample actually covers the full year and the control didn’t change mid-year. Twenty-five items all drawn from January says nothing about October.

Mistakes that undermine controls testing

• —Relying on management’s description of a control without observing it operate.
• —Testing whether a control was designed well, but not whether it actually operated all year.
• —Ignoring a segregation-of-duties conflict because “everyone trusts the person.”
• —Reporting a deficiency only verbally, or only to management, leaving no trace on the file.