A walkthrough is the cheapest high-value procedure in auditing and the most inconsistently documented. Done well, it produces the one artifact everything downstream depends on: a faithful picture of how the process actually runs — not the procedure manual’s version — with every control point marked, every system handoff traced, and the gap between documentation and reality recorded in writing. Done badly, it is three pages of narrative nobody can test from, a flowchart copied from the process owner’s slide, and a conclusion that says “design appears adequate” without saying what was designed or why it’s adequate. The difference is structure, and structure is what a template provides.
Here is the walkthrough document in full: eight parts with model language, drafting guidance under each, and — continuing the Templates Suite thread — a completed walkthrough of MidState Beverage’s depot settlement-to-deposit process, procedure 1 from the route-cash planning memo, plus a second completed example on a purchase-to-pay slice so you can see the template flex across process types. What the walkthrough concludes here becomes the testing that the report and issue log templates carry forward.
In this guide
- What a walkthrough proves — and what it can’t
- The template, annotated: eight parts
- Completed example: MidState’s depot settlement to deposit
- Second example: a purchase-to-pay slice
- The four walkthrough failures
- Tools, flowcharts, and reuse
What a walkthrough proves — and what it can’t
A walkthrough follows one transaction from initiation to its final resting place in the records, watching it pass through every hand and system, asking at each step “what could go wrong here, and what stops it?” It proves three things: that you understand the process as it operates (not as it is described), that you have identified where the controls sit and can name them, and that those controls are designed to address the risks — the design half of the design-versus-operation distinction. It cannot prove operating effectiveness: one transaction is one instance, and effectiveness is a claim about a period. Its highest-value output is usually the humblest one — the list of places where what people actually do differs from what the procedure says they do, because that gap is where undocumented controls, invisible workarounds, and unmitigated risks all live. The template below is built to force that gap into the open (Part 7) and to end with decisions (Part 8): which controls are key, how each will be tested, and which risks have no control at all.
The template, annotated: eight parts
Part 1 — Header block
Walkthrough: [process / sub-process]. Engagement: [name, plan item]. Boundaries: starts at [trigger event]; ends at [final record]. Transaction walked: [identifier — e.g., settlement #, invoice #, dated]. Performed: [date], at [location / system], by [auditor], with [process participants and roles]. Sources: [procedure document and version; system; prior walkthrough date]. Related risks: [planning memo Section 4 references].
Drafting guidance. The header is what makes the walkthrough re-performable: a named transaction, a date, the people present, and the procedure version you compared against. “Walked the AP process with the team” is a diary entry; “walked invoice 44817 from receipt on 3 Feb through payment run 12 Feb, with the AP supervisor and the receiving clerk, against Procedure AP-02 v3” is evidence. Boundaries matter twice — they define the scope of this walkthrough and they should match the planning memo’s process scope, so name the start trigger and the end record explicitly.
Part 2 — Process narrative
Step [n] — [step name]. [Who, by role] [does what] in [system / on what document], using [input] and producing [output]. Timing: [when / how often / SLA]. [Observed: what the auditor actually saw on the walked transaction, including anything different from the procedure.] Control point: [CP# if a control operates here, else “none”]. Handoff: [to whom / which system, if the step ends in a transfer].
Drafting guidance. Numbered steps, one paragraph each, in a fixed grammar: role, action, system, input, output, timing. The fixed grammar is what makes narratives comparable across engagements and readable by someone who was not there. The “observed” sentence is the walkthrough’s soul — it is where you record that the clerk skipped the second signature, that the spreadsheet has a hidden tab, that the “daily” reconciliation is done Fridays. Write what happened, tag control points and handoffs inline so Parts 4 and 5 can be built from the narrative, and keep it to the steps that carry risk or controls: a walkthrough is not a procedure manual, and forty steps of “the clerk clicks next” bury the eight that matter.
Part 3 — Flowchart (swimlane conventions)
Flowchart conventions. Swimlanes: one per role or system, left to right in the order the transaction moves. Symbols: rectangle = manual step; rectangle with a bar = system step; diamond = decision; document icon = artifact produced; database icon = record written. Control points marked CP# in a circle at the step where the control operates; system handoffs marked H# on the arrow crossing the swimlane. Every CP and H number cross-references Parts 4 and 5. The flowchart depicts the process as observed; where it differs from the procedure document, the difference is footnoted to Part 7.
Drafting guidance. The narrative and the flowchart are the same information in two forms — the narrative for precision, the chart for the reviewer who needs the shape of the process in thirty seconds. Swimlanes by role make segregation visible at a glance: when one lane holds authorization, custody, and recording, you can see the SoD problem before you can name it. Draw what you observed, not what the process owner’s slide shows — borrowed flowcharts are the most common way walkthroughs inherit the documentation’s errors — and keep the symbol set small enough that another auditor could redraw it from the narrative.
Part 4 — Control-point call-outs
| CP# | Step | Control (what it does) | Type | Frequency | Performer | Evidence produced | Risk(s) addressed |
|---|---|---|---|---|---|---|---|
| [CP1] | [n] | [Specific action — who checks what against what, with what threshold] | [P/D/C; manual/auto] | [per transaction / daily / monthly] | [role] | [signature, system log, reconciliation file, exception report] | [R# from memo] |
Drafting guidance. Each control gets one row written to the five-element standard — who, what, when, how, evidence — the same discipline as the RCM, because this table feeds it directly. Type tags (preventive, detective, corrective; manual or automated) determine how each control will be tested later. The evidence column is the one to be honest in: if the control leaves no trace (“the supervisor looks it over”), say so here, because an untraceable control is a testing problem you want to know about before fieldwork, not during it. The risk column closes the loop to the planning memo — a control addressing no listed risk is either a discovery or a redundancy, and a listed risk with no control point is a finding forming.
Part 5 — System handoffs and data flows
Handoff register. Every point at which the transaction changes hands — between systems, or between a system and a person — is listed below. For each handoff we record how the data moves, what could be lost or altered in transit, and which control, if any, would notice.
| H# | From → To | Mechanism | What can go wrong in transit | Integrity control | Observed operating? |
|---|---|---|---|---|---|
| H1 | [Source system] → [target system] | Automated interface, nightly batch | Dropped or duplicated records; failed batch unnoticed | Interface exception report reviewed by [role] each morning | [Yes / No / Partially] |
| H2 | [System] → [spreadsheet or manual step] | Manual re-key by [role] | Keying error; omitted items; unversioned file | Re-keyed total agreed to source by [independent role] | [Yes / No / Partially] |
| H3 | [Person] → [person or team] | Email, paper, shared folder | Item never arrives; no record that it was sent; aging invisible to the receiver | Acknowledgement, log, or receiver-side aging review | [Yes / No / Partially] |
Drafting guidance. Handoffs are where controls go silent. A process with five controls and four handoffs has nine points of interest, and the handoffs are usually the undocumented five — nobody writes a procedure for “the spreadsheet we re-key into because the module can’t print the bank’s format.” Ask three questions at each one: is it automated or manual; if automated, who finds out when it fails; if manual, is there a reconciliation performed by someone other than the re-keyer that would notice a difference. Where a handoff produces a report you will later rely on as evidence, that report’s completeness and accuracy is the IPE question, and the register is the place to note it. Keep the “observed operating” column honest: a control the process owner describes but you did not see is “not observed,” and it stays that way until testing.
Part 6 — Evidence inventory
Evidence obtained during the walkthrough. Each item is filed at the workpaper reference shown. Items marked “copy” are retained; items marked “observed” were inspected on screen or in person and not retained, and must be re-obtained as copies before they are used to support a test conclusion.
| Ref | Item | Source | Date / period | Obtained from | Copy / observed | W/P ref |
|---|---|---|---|---|---|---|
| E1 | Signed control record for the walked transaction (count sheet, approval form, checklist) | [Location] | [Date] | [Role] | Copy | [Ref] |
| E2 | System record of the walked transaction (screen print with record ID, status, timestamps) | [System] | [Date] | [Role] | Copy | [Ref] |
| E3 | Exception or override report covering the walkthrough period | [System] | [Period] | [Role] | Copy | [Ref] |
| E4 | Current procedure document and policy — the versions compared in Part 7 | [Intranet / DMS] | Current | [Process owner] | Copy | [Ref] |
Drafting guidance. Walkthrough evidence does two jobs. It proves the walkthrough happened as described — a reviewer can open E1 and see the signed sheet for the very transaction in the header — and it seeds the testing file, because the first sample item is already in hand. One rule governs the inventory: for every control in the Part 4 table there is at least one evidence item showing that control’s output for the walked transaction. If a control has no evidence item, one of two things is true: the control leaves no trace (record that in the gap log — it will be untestable and the work program needs to know now), or you did not ask to see it (go back). “Observed on screen” is acceptable for a walkthrough and never for a test; flag those items so the fieldwork team re-obtains them as copies rather than discovering the gap during review.
Part 7 — Documented-versus-actual gap log
Gap log. Differences between the documented procedure and the process as actually performed. A gap is recorded whether or not it weakens control; the implication column carries the judgement, and the “carried to” column records where the gap goes next.
| G# | Step | Procedure says | Actually observed | Performer’s explanation | Control implication | Carried to |
|---|---|---|---|---|---|---|
| G1 | [n] | [Quote the procedure, with section reference] | [What you saw, with the evidence ref] | [Their words, close to verbatim] | [Weakens / does not affect / strengthens control over R#; why] | [Conclusion / work program step / issue log / report recommendation] |
| G2 | [n] | Not addressed — step is undocumented | [The step as performed] | [Why it exists] | [Usually: an uncontrolled manual handoff] | [Destination] |
| G3 | [n] | [Step assigned to role A] | [Performed by role B] | [Staffing, turnover, convenience] | [Segregation effect, if any] | [Destination] |
Drafting guidance. The gap log is the walkthrough’s most valuable output and the one auditors most often bury inside the narrative as an aside. Gaps come in three kinds, each with a different implication: undocumented steps (the process does something the procedure never mentions — almost always a manual handoff), unperformed steps (the procedure says something happens and it does not — a control that exists on paper), and reassigned steps (it happens, but a different role does it — the segregation question). Record the performer’s explanation close to verbatim. It is the fastest route to root cause, and it protects you at the closing meeting from “that isn’t what we said.” Then carry every gap somewhere: to the Part 8 conclusion if it changes the design assessment, to the work program if it changes what you test, to the issue log if it is a finding in waiting. A gap with an empty “carried to” cell is a walkthrough that was performed and not used.
Part 8 — Conclusion: design assessment and testing implications
Design conclusion. Based on the walkthrough, the controls over [process] are [designed effectively to address the risks identified in the planning memo / designed effectively except as noted below / not designed effectively] because [reason, tied to CP# and R#].
Key controls selected for testing: CP[ ], CP[ ], CP[ ] — selected because [each is the primary control over a risk rated high in the planning memo / no other control addresses the risk / the control is relied on for financial reporting].
Test approach: [test of design only / design and operating effectiveness] for each key control — see work program section [ ]. Where design is concluded ineffective, no test of operating effectiveness is performed; the response is [compensating analytics / expanded scope / immediate escalation].
Risks with no effective control identified: R[ ] — [description]. Proposed response: [ ].
Changes to the planning memo or work program arising from this walkthrough: [list, or “none” — and if none, say why].
Drafting guidance. The conclusion is a design assessment, not a verdict on the process. It says three things and only three: which risks have a control designed to address them, which controls you will test, and which risks have none. “Designed effectively except as noted” is the honest majority outcome; “designed effectively” with a populated gap log is a contradiction a reviewer will catch. The walkthrough is your test of design for most controls, so say so, and where design has failed do not schedule a test of operating effectiveness — testing whether an ineffective control operates consistently tells you nothing you can use. Finally, a walkthrough that changes nothing in the work program is suspicious. Either the planning was unusually good or the walkthrough was not really performed; write down which.
Completed example: MidState Beverage — Dayton depot, route settlement to bank deposit
This is procedure (1) from the route-cash planning memo: a walkthrough at the Dayton depot before the population analytics and surprise counts begin. The completed document is condensed here — the real one ran nine pages with the flowchart attached — but every part is present, and every entry is the kind you would actually write rather than the kind that looks tidy in a template.
Header
Engagement: FY27-01 Route Cash Handling. Process: Daily route settlement through bank deposit and general-ledger posting, Dayton depot. Transaction walked: Route 14, settlement of Monday 19 January FY27 — $6,412.80 cash and 23 checks totalling $9,870.15 per the handheld; selected because Route 14 is the depot’s highest-cash route. Walkthrough performed: 20–21 January, on site (the deposit confirmation step was observed on the 21st). Participants: depot settlement clerk (performs steps 2–7), depot manager (reviews at steps 5 and 7), Route 14 driver (steps 1–2), Director of Route Accounting by phone (steps 8–9). Procedure compared: Depot Settlement Procedure rev. FY26 and Route Cash Handling Policy v4 (E9). Prepared by: senior auditor, 22 January. Reviewed by: audit manager, 24 January.
Process narrative
- Driver returns and syncs. The Route 14 driver returns to the depot at 16:40, docks the handheld, which syncs the day’s invoices and collections to the ERP route-accounting module, and hands the settlement envelope — cash, checks, signed delivery invoices — to the settlement clerk at the window. Output: a “route expected settlement” record in ERP showing $6,412.80 cash and $9,870.15 checks. Timing: same day, on return.
- Dual cash count. The clerk counts the cash in the driver’s presence; both sign the pre-printed count sheet (E1). Counted: $6,387.80, which is $25.00 short of expected. Output: signed count sheet. Timing: about ten minutes, same day.
- Settlement keyed; variance check. The clerk keys the counted cash and lists each check in the ERP settlement screen. ERP compares counted to expected and requires a reason code for any variance above $25 per route per day. The $25.00 shortage sat exactly at the tolerance and was not flagged; the clerk said shortages “under a bit” are “driver change-fund errors” and post to a driver variance account. Output: settlement record, status “settled” (E2). Timing: same day.
- Checks re-keyed to the deposit spreadsheet. The clerk re-keys each check from the ERP screen into the depot’s deposit spreadsheet (E4), which produces the bank deposit listing. This step is not in the procedure; it exists because the 2013 module cannot print a listing in the bank’s format. Output: one spreadsheet row per check. Timing: same day.
- Overnight custody. The clerk seals cash and checks in a numbered tamper-evident bag, records the bag number on the safe log (E5) and locks it in the depot safe; the depot manager countersigns the safe log at close, around 18:00. The combination is known to the clerk and the manager. Output: safe log entry. Timing: end of day.
- Courier collection. The armored courier collects the bag at about 09:30 the next business day. The clerk prepares the deposit slip from the spreadsheet total; the courier signs a receipt (E6). Output: courier receipt and deposit slip copy. Timing: next day.
- Deposit confirmation and reconciliation. Two days after settlement the clerk checks the bank portal for the deposit (E7), records the confirmed amount on the depot’s weekly settlement summary and reconciles it to the ERP settlement total for that day. The depot manager initials the weekly summary on Friday (E8). The confirmed deposit for 19 January was $16,257.95, agreeing to counted cash plus checks. The manager told us he “checks the total matches the ERP total” and does not look at variances, overrides or individual routes. Output: initialled weekly summary. Timing: daily preparation, weekly review.
- Customer accounts and unapplied cash. On sync, invoices paid in full are marked paid on the customer account. Partial payments, payments without an invoice reference and checks the driver could not match post to a depot unapplied-cash account; on Wednesdays the clerk emails the unapplied listing to HQ Route Accounting, which applies items to customer accounts. Customers on account receive an ERP-generated monthly statement. Output: applied and unapplied cash postings; monthly statements. Timing: weekly and monthly.
- GL posting and month-end reconciliation. HQ Route Accounting posts the daily depot settlement batch to the GL through a nightly automated interface and reconciles the depot cash clearing account at month-end, comparing total settlements to total confirmed deposits for the depot and investigating differences over $500. Output: month-end reconciliation with reviewer sign-off. Timing: monthly.
Flowchart (as attached)
Six swimlanes: Driver; Depot settlement clerk; Depot manager; Courier and bank; HQ Route Accounting; ERP (system lane). The cash moves through lanes one, two and four; the record moves through lanes six, two, five and six again. Two decision diamonds — “variance over $25?” at step 3 and “invoice matched?” at step 8. Seven control markers CP1–CP7 and four handoff markers H1–H4 placed on the connectors, not in the boxes. The chart fits on one landscape page; anything that did not fit was left in the narrative rather than shrunk.
Control-point call-outs
| CP# | Step | Control (what it does) | Type | Frequency | Performer | Evidence produced | Risk(s) addressed |
|---|---|---|---|---|---|---|---|
| CP1 | 2 | Dual cash count with the driver present; count sheet signed by both | Preventive (dual custody at handover) | Daily, per route | Clerk and driver | Signed count sheet (E1) | R1, R2 |
| CP2 | 3 | ERP variance flag: counted versus expected over $25 requires a reason code; clerk can override | Detective, automated with manual override | Daily, per route | ERP; override by clerk | Settlement record; override reason-code report (E3) | R2 — partial (tolerance and self-override; see G1) |
| CP3 | 5 | Tamper-evident bag, safe log, manager countersignature | Preventive | Daily | Clerk; manager | Safe log (E5) | R2 (overnight loss) |
| CP4 | 6 | Courier receipt agreed to deposit slip; daily collection | Preventive / detective | Daily | Clerk; courier | Courier receipt (E6) | R4, R2 |
| CP5 | 7 | Confirmed deposit reconciled to ERP settlement total; weekly manager initial | Detective | Daily preparation; weekly review | Clerk; manager | Weekly settlement summary (E8) | R2, R4 — impaired by R5 (see G2) |
| CP6 | 8 | Monthly customer statements generated by ERP | Detective (depends on the customer) | Monthly | ERP; customer | Statement run log; customer queries | R1, R3 (lapping) |
| CP7 | 9 | Month-end depot cash clearing reconciliation, differences over $500 investigated | Detective | Monthly | HQ Route Accounting | Reconciliation with sign-off (to be obtained in fieldwork) | R2, R4 — at depot-month level only |
Handoff register
| H# | From → To | Mechanism | What can go wrong in transit | Integrity control | Observed operating? |
|---|---|---|---|---|---|
| H1 | Handheld → ERP route module | Automatic sync on docking | Failed or partial sync leaves a route day’s collections unrecorded | Nightly sync exception report — exists in ERP; not reviewed at Dayton (G3) | No |
| H2 | ERP settlement → deposit spreadsheet | Manual re-key by clerk | Keying error; omitted check; altered payee on the listing | None independent — spreadsheet total agreed to ERP only through CP5, by the same clerk | No |
| H3 | Depot → HQ Route Accounting (unapplied cash) | Weekly email | Items dropped; aging invisible at HQ | HQ aging review — described by the Director; not observed in this walkthrough | Not observed |
| H4 | Bank portal → weekly summary | Manual transcription by clerk | Transcription error; deposit recorded that was not made | Manager weekly initial — total only | Partially |
Evidence inventory
| Ref | Item | Source | Date / period | Obtained from | Copy / observed | W/P ref |
|---|---|---|---|---|---|---|
| E1 | Signed count sheet, Route 14, 19 January | Depot | 19 Jan | Clerk | Copy | 1.3.1 |
| E2 | ERP settlement screen, Route 14, 19 January | ERP | 19 Jan | Clerk | Copy (screen print) | 1.3.2 |
| E3 | ERP override reason-code report, Dayton, 1–20 January: 12 overrides, all keyed by the clerk, 9 coded “driver change fund” | ERP | 1–20 Jan | Clerk | Copy | 1.3.3 |
| E4 | Deposit spreadsheet, 19 January tab | Depot shared drive | 19 Jan | Clerk | Copy | 1.3.4 |
| E5 | Safe log, page for 19 January | Depot | 19 Jan | Manager | Copy (photo) | 1.3.5 |
| E6 | Courier receipt and deposit slip copy, 20 January | Depot | 20 Jan | Clerk | Copy | 1.3.6 |
| E7 | Bank portal deposit confirmation, $16,257.95 | Bank portal | 21 Jan | Clerk | Observed — copy to be obtained for testing | 1.3.7 |
| E8 | Weekly settlement summary, week ending 23 January, manager initialled | Depot | w/e 23 Jan | Manager | Copy | 1.3.8 |
| E9 | Depot Settlement Procedure rev. FY26; Route Cash Handling Policy v4 | Intranet | Current | Director of Route Accounting | Copy | 1.1.2 |
Gap log
| G# | Step | Procedure says | Actually observed | Performer’s explanation | Control implication | Carried to |
|---|---|---|---|---|---|---|
| G1 | 3 | “Variance overrides are reviewed daily by the depot manager and initialled on the exception listing” (§4.3) | No daily review. No exception listing is printed. The manager was unaware such a listing exists. All 12 overrides in E3 were keyed and self-approved by the clerk. | Manager: “Never seen it. The system’s been like that since before I got here.” | CP2 operates as a self-approved override, and shortages at or under $25 per route per day never surface at all. Across 300 routes the tolerance permits roughly $7,500 a day system-wide without a flag. | Conclusion (design); work program — override population analysis, all depots; issue log candidate |
| G2 | 7 | “The depot reconciles confirmed deposits to settlements weekly; the reconciliation is reviewed by the depot manager” (§6.1) | Prepared by the same clerk who keys settlements and prepares the deposit slips. The manager’s review is a total-only check. | Clerk: “There’s only me.” Manager: “If the total’s right, the routes are right.” | R5 realised. CP5 cannot detect a clerk-level diversion masked by agreeing the spreadsheet to whatever was deposited. | Conclusion (design deficiency); work program — procedure (2) full-population analytics; issue log; raise with Director now |
| G3 | 1 | Not addressed | The nightly sync exception report is generated by ERP and unread at Dayton. | Clerk: “Didn’t know it went anywhere.” | H1 has no operating integrity control. An unsynced route day would surface only through a customer statement query. | Work program — reconcile handheld route days to ERP settlements for the period, all depots |
| G4 | 4 | Not addressed | Checks are re-keyed into a spreadsheet to produce the deposit listing (undocumented step). | Clerk: “The module can’t print the bank’s format.” | Undocumented manual handoff (H2) with no independent check; the FY26 procedure does not describe the process as performed. | Report — procedure update recommendation; work program — agree sample of spreadsheet listings to ERP check detail |
Conclusion
Design conclusion. Controls over Dayton route settlement are not designed effectively, as performed, to address R2 (short deposit) and R5 (segregation): the two controls intended to detect a short deposit — the variance flag (CP2) and the settlement-to-deposit reconciliation (CP5) — are both performed or overridden by the settlement clerk without independent review (G1, G2). Custody controls CP1, CP3 and CP4 are designed effectively for R1 at the point of handover and for R4. R3 (lapping) relies entirely on monthly customer statements (CP6), a detective control that depends on customers reading and querying their statements; no depot- or HQ-level control addresses lapping directly. This is consistent with the FY26 Dayton loss of $18,400, which was detected by a customer complaint and by nothing else.
Key controls selected for testing: CP1, CP3, CP4, CP7 (design and operating effectiveness across the 40 settlements in procedure 4); CP6 (statement run completeness). CP2 and CP5: test of design concluded — ineffective as performed. No test of operating effectiveness; exposure will be quantified instead through full-population settlement-to-deposit analytics (procedure 2) and customer-account and unapplied-cash analytics (procedure 3).
Risks with no effective control: R3 (lapping) at depot level; unrecorded route days through H1 (G3).
Changes arising: (a) add override reason-code analysis for all twelve depots to procedure (2); (b) add a handheld route-day-to-settlement reconciliation to procedure (2); (c) confirm whether the other depots also re-key deposit listings before the surprise counts are scheduled; (d) raise G2 with the Director of Route Accounting this week — the segregation gap does not wait for the report.
Notice what the walkthrough did to the engagement. The planning memo rated R5 as a risk; the walkthrough turned it into a design deficiency with a named cause and a quantified exposure before a single sample was tested. The override population across twelve depots — not in the memo at all — became the engagement’s central analytic. And the FY26 theft acquired an explanation: the one control that could see a driver-level diversion was the customer’s own statement. When the report is drafted, its findings will trace back to G1, G2 and G3 by number, which is what the “carried to” column is for.
Second example, compact: MidState accounts payable — vendor invoice to payment
The same template, a non-cash process, and half the length — to show what the document looks like when the process is lower risk and mostly automated. This is the non-inventory purchase-to-pay slice at MidState’s head office, walked during the FY27 ICFR support engagement (plan engagement 6).
Transaction walked: vendor invoice 88213 from a fleet-maintenance supplier, $4,180.00, PO-backed, received 3 February, paid 12 February. Participants: AP clerk, AP supervisor, assistant controller. Procedure compared: AP Processing Procedure v3.1.
- The AP clerk clears the AP mailbox each morning and uploads invoice PDFs to the ERP AP module, which reads the PO number where present. Output: invoice record, status “received.”
- PO invoices: ERP performs a three-way match against the PO and goods receipt within a tolerance of 2 percent or $100; matched invoices are approved for payment automatically (CP1). Invoice 88213 matched on first pass. Tolerance settings are maintained by the ERP administrator; no one reviews changes to them.
- Non-PO invoices (about 35 percent by count): the clerk emails the cost-center manager for approval and attaches the reply to the invoice record (CP2). Of the ten most recent non-PO invoices we opened on screen, four had no attached approval; the clerk keeps the emails in Outlook.
- A weekly payment proposal is generated on Thursday; the AP supervisor reviews the listing and releases it in ERP (CP3). The supervisor also holds vendor-master maintenance access.
- The payment file is transmitted to the bank portal, where the controller approves the file (CP4); a positive-pay file is sent with it.
- ERP posts the payments; the assistant controller reconciles the AP sub-ledger to the GL monthly (CP5).
| CP# | Step | Control | Type | Frequency | Evidence | Risk addressed |
|---|---|---|---|---|---|---|
| CP1 | 2 | Automated three-way match within tolerance | Preventive, automated | Per invoice | Match status on invoice record; tolerance configuration | Invalid or overstated invoice paid |
| CP2 | 3 | Cost-center manager approval of non-PO invoices | Preventive, manual | Per invoice | Approval email attached to record — inconsistent (G1) | Unauthorised purchase |
| CP3 | 4 | Supervisor review and release of payment proposal | Detective / preventive | Weekly | Release log in ERP | Duplicate or erroneous payment |
| CP4 | 5 | Controller approval of bank payment file; positive pay | Preventive | Weekly | Portal approval log | Unauthorised or altered payment |
| CP5 | 6 | AP sub-ledger to GL reconciliation | Detective | Monthly | Reconciliation with sign-off | Unrecorded or misposted liabilities |
| G# | Procedure says | Actually observed | Implication | Carried to |
|---|---|---|---|---|
| G1 | “Approval is attached to the invoice record before the invoice is released for payment” (§3.2) | Four of ten recent non-PO invoices had no attached approval; approvals exist in the clerk’s mailbox | CP2 evidence is incomplete in the system of record; the control may be operating but cannot be tested from ERP alone | Work program — test CP2 from the email population, not the ERP attachment; report recommendation |
| G2 | Not addressed | The AP supervisor who releases payments also maintains vendor master data | Segregation gap: a fictitious vendor could be created and paid by one person, subject only to CP4’s file-level approval | Conclusion; ERP user-access engagement (plan engagement 3) — add to role-conflict list; issue log candidate |
| G3 | Not addressed | Match tolerance configuration changes are not reviewed | CP1’s effectiveness depends on a setting nobody monitors | Work program — obtain tolerance change history for the year (ITGC change management) |
Design conclusion: designed effectively except as noted. CP1, CP3, CP4 and CP5 are designed effectively for the risks identified; CP2’s design is adequate but its evidence is not retained in the system of record (G1); a segregation conflict exists at step 4 (G2) that CP4 only partially mitigates. Testing: CP1 — configuration and change history plus a sample of 25 matched invoices; CP2 — sample of 25 non-PO invoices tested to email approvals; CP3, CP4 — sample of 10 weekly runs; CP5 — three month-ends. Changes arising: G2 referred to the user-access engagement; G3 added to the ITGC change-management test.
Half a page of narrative, one control table, three gaps, a conclusion that names what will be tested and how. A low-risk process does not need a shorter template; it needs the same template with shorter entries. The gap log is the part that never shrinks.
Five ways walkthrough documentation fails
| Failure | What it looks like | Why it matters | Cure |
|---|---|---|---|
| The retyped procedure | A narrative that restates the procedure manual in the auditor’s words. No named transaction, no dates, no “we saw.” | It proves nothing, and the gap log is empty by construction — you cannot find a difference between the procedure and itself. | Walk one named transaction. Every step gets a date, an evidence reference and an observation. If a step cannot be shown, that is the first gap. |
| The conference-room walkthrough | Performed with the process owner, away from the workstation, from memory. | You hear the design, not the performance. G1 and G2 in the Dayton example would never have surfaced from the manager alone — he did not know the exception listing existed. | Walk with the person who does the work, at the place they do it. The manager joins for the gap discussion afterwards. |
| Controls without outputs | Call-outs that say “reviewed by manager” with nothing in the evidence column. | Untestable. The work program then invents a test for a control that leaves no trace, and the fieldwork team discovers the problem in week three. | Every CP row names its evidence. “No evidence produced” is itself a gap and goes in the log. |
| Orphaned gaps | Four differences recorded; conclusion says “designed effectively”; work program unchanged. | The walkthrough was performed and not used. External quality reviewers and regulators look for exactly this pattern, because it is the signature of a compliance walkthrough. | The “carried to” column is mandatory. Every gap lands in the conclusion, the work program, the issue log or a report recommendation. |
| The frozen walkthrough | Year three’s document is year one’s with the dates changed. | Processes drift — people leave, modules are patched, spreadsheets appear. A re-read is not a walkthrough, and a reviewer who compares the two years will see it. | Roll forward the structure only. Re-walk a new transaction each cycle; any change to system, people or procedure version restarts the document. |
Adapting the template: tools, ICFR versus operational, the one-hour version
Tooling and the flowchart
Any swimlane tool works — draw.io, Lucidchart, Visio, the process module in your audit-management platform, or PowerPoint if that is what the team already knows. The Part 3 conventions matter far more than the software: one lane per role, one system lane, numbered steps that match the narrative, controls on the connectors. If producing the chart takes longer than writing the narrative, the chart is too detailed; if the reviewer cannot follow the cash from the chart alone, it is too sparse. For a single-system, low-risk process the chart is optional. The narrative never is.
ICFR walkthroughs versus operational audits
For an ICFR or SOX walkthrough, add an assertion column to the control table (existence, completeness, accuracy, cutoff, valuation) and cross-reference each CP to the risk-control matrix; the “what could go wrong” at each step is framed per assertion, and the conclusion feeds the key-control selection directly. For an operational audit, add cycle-time and rework observations to the narrative — how long each step waits, how often an item comes back — so the same document answers both “is it controlled” and “is it efficient.” The preventive-detective-corrective typing in the control table is what lets you see, in either case, whether the process is built to stop errors or merely to find them later.
The one-hour version
When the process is small and the risk is low, keep Parts 1, 2, 4, 7 and 8 — header, narrative, control table, gap log, conclusion — and drop the flowchart, handoff register and evidence inventory, folding any evidence references into the narrative. The second MidState example is close to this shape. What you never drop is the gap log, because it is the only part that records something the process owner did not already know.
Interview craft, in one paragraph
Ask to see, not to hear: “show me the last one” beats “walk me through a typical one” every time, because the last one is real and the typical one is a description. Ask what happens when it goes wrong — the exception path is where the undocumented steps live. When a step cannot be shown, stop, write the gap in the performer’s words, and move on; do not let the walkthrough become a discussion about what should happen. And record who said what. The Dayton gap log is persuasive at the closing meeting because the manager’s own sentence is in it. The site’s guide to audit interview techniques covers question types, listening and note-taking in full.
Where this sits in the engagement
Upstream, the planning memo names the risks and procedures the walkthrough is testing the design against. Downstream, the gap log feeds the work program and, through it, the report and the issue log. Any deficiency you conclude on here will be rated using the same logic as control deficiency evaluation, and the fraud-relevant gaps — G1 and G2 at Dayton — belong on the engagement’s red-flag watch list from the day they are found.
The Templates Suite
- The Annotated Internal Audit Plan Template — the FY27 plan that scheduled this engagement
- The Engagement Planning Memo Template — the route-cash memo whose procedure (1) is this walkthrough
- The Walkthrough Documentation Template — this guide
- The Audit Report Template Set — where G1–G3 become rated findings
- The Finding and Issue Log Template — where they are tracked to closure
Leave a Reply