Every process has two versions: the one in the procedure and the one people actually run. A walkthrough finds the second. Control testing then asks a harder question: did each control work, every time, over the period?
Where it comes from
These are internal audit's everyday methods. The Institute of Internal Auditors teaches walkthroughs, the risk and control matrix (RCM), and testing as core fieldwork. The two steps answer different questions, and mixing them up is a common error:
| Step | Question | Evidence |
|---|---|---|
| Walkthrough | Is the control designed right, and is it in place? | One transaction traced end to end |
| Control test | Did it operate every time over the period? | A sample from the whole period |
How a bot helps
Pick one real order and trace it: quote, order entry, production, shipping, invoice, payment. A bot pulls every record that order touched, in time order, and lines them up against the written procedure. Gaps show up: an approval with no record, a price changed after the quote, an invoice raised before shipping.
For testing, the bot builds the risk and control matrix (risk, control, owner, evidence), draws the sample, and checks each item for its evidence. Every item without evidence is an exception, and every exception gets followed up.
On the bots' own work
Walk one request through a bot team: who received it, what each bot did, which approval it waited for. Then test the controls: did every outside message in the last month have a person's yes on file?
When to use it
When a process problem crosses departments, before a big change, and on a schedule for controls that protect money or customers. Medium rigor.
Where bots differ
A bot only sees the records. It can't see the sticky note on the monitor or the phone call that fixed the order. Every walkthrough needs a person to sit with whoever does the work. A bot's record trace plus a person's observation is stronger than either alone.
Sources: IIA: tools for lead auditors.
Back to Engineering tools for bots.
Short outline
Walkthrough and control test: short outline
What it's for
A walkthrough traces one real transaction through the process to check the controls are designed and in place. Control testing checks a sample from the whole period to see whether each control operated every time. Every exception gets followed up.
Columns
| Column | What goes in it |
|---|---|
| Risk | What could go wrong |
| Control | What is supposed to stop or catch it |
| Owner | Who runs the control |
| Evidence expected | What record shows it operated |
| Walkthrough result | Seen in place, not seen, or works differently from the procedure |
| Sample | How many items, from what period, chosen how |
| Exceptions | Items with no evidence, each listed |
| Follow-up | Why each exception happened, and the fix |
| Observed by | The person who watched the work, not only the records |
Steps, each with its "done when"
- List risks and controls. Done when each risk has a control, an owner and the evidence expected.
- Walk one real transaction through. Done when the transaction is traced end to end from records, a person has observed the work, and each control is marked in place, not seen, or different.
- Choose the sample. Done when the sample size, period and selection method are written down before testing.
- Test each item. Done when every sampled item is marked evidence found or exception, with the record cited.
- Follow up every exception. Done when each exception has a cause and an owner, and the result says designed right, operating, both or neither.
Common mistakes
- Treating one walkthrough as proof that a control works over the period.
- A walkthrough done only from records, with no one watching the work.
- Picking the sample after seeing which items look clean.
- Listing exceptions with no follow-up.