A walkthrough that ends with “process owner confirmed the narrative is accurate” has tested nothing. The narrative was written by the person who confirmed it, the controls in the risk-control matrix were listed by the same person, and the one transaction you traced was the one they handed you. Testing starts, twenty-five samples pass, and the deficiency that surfaces eleven months later sits in a step nobody wrote down: the goods receipt keyed by the purchasing coordinator, the match tolerance untouched since 2019, the spreadsheet between the OCR tool and the ledger. The walkthrough is the one point in an engagement where those steps can be found cheaply, because you are sitting next to the person who performs them, with the real transaction on the real screen.
This guide covers the conduct of the walkthrough: selecting the transaction, deciding who to sit with, asking what could go wrong at each step, following the item across system boundaries, collecting evidence that survives review, and turning what you saw into a design conclusion and a test plan. It gives you a 36-prompt what-could-go-wrong question bank by step type, a before/during/after planning checklist, an interview script with probes, a worked purchase-order-to-payment walkthrough with two gaps and a written design conclusion, a time-budget table, and a common failures table. It was rewritten in September 2026 to reflect the Global Internal Audit Standards and current SOX practice. The write-up format lives in the site’s walkthrough documentation template, and the distinction the walkthrough feeds is explained in test of design vs. operating effectiveness; neither is repeated here.
In this guide
- What a walkthrough is for, and what it is not
- What SOX expects: AS 2201 explained for internal auditors
- Planning: the transaction, the people, and the checklist
- The what-could-go-wrong question bank, by step type
- The interview script
- Following the transaction through systems and collecting evidence
- From gaps to design conclusions and test plans
- Worked example: a purchase-order-to-payment walkthrough at MidState Beverage
- Remote walkthroughs, time budgets, and edge cases
- Common walkthrough failures
What a walkthrough is for, and what it is not
A walkthrough follows one real transaction from the business event that created it to the ledger entry and the bank movement that closed it, using the documents and systems the company’s own people use, and asks at each step what could go wrong and what stops it. Three outputs come out of a complete one: a verified understanding of the flow as performed rather than as described; the list of points where an error or a fraud could enter, the what-could-go-wrong points (WCGWs in the shorthand of several firms’ SOX methodologies); and, for each point, either a control that addresses it or a note that nothing does. The design conclusion, whether the control as it exists can prevent or detect what it is supposed to catch, is the product of the third output, and it feeds the risk and control columns of the RCM, the deficiency evaluation, and the substantive procedures that replace control testing where a control is missing.
It is not an interview; an interview with the process owner produces the process as designed, which is the narrative you already had. It is not a flowcharting exercise; the map is a by-product. And it is not a test of one. A single traced transaction says nothing about whether a control operated across a period, which is the job of the operating-effectiveness sample sized under the 25/40/60 sampling guide. The walkthrough tells you whether the control is worth sampling at all.
Under the Global Internal Audit Standards, the walkthrough sits inside the engagement risk assessment of Standard 13.2 and produces the understanding on which the Standard 13.6 work program is built; the information it yields has to meet Standard 14.1’s test of sufficient, reliable, relevant, and useful, which is why “the owner told me” is not enough for a design conclusion. In COSO terms, Principle 10 (control activities that mitigate risks to acceptable levels) is the question the design conclusion answers, and Principle 12 (deployment through policies and procedures) is the one the walkthrough tests most directly, because a control that exists in the policy but not at the desk fails Principle 12 before it reaches Principle 10; the COSO 17 principles guide maps both. For SOX-scoped processes the walkthrough is annual in practice. For operational audits the only sound reason to skip it is a walkthrough less than twelve months old plus confirmation from the performers, not just the owner, that nothing has changed.
What SOX expects: AS 2201 explained for internal auditors
The external auditor’s rulebook for the integrated audit is PCAOB AS 2201, and even if you never support SOX 404 it contains the most precise description of a walkthrough in any standard. Paragraph 34 sets four objectives for understanding the likely sources of potential misstatement: understand the flow of transactions, including how they are initiated, authorized, processed, and recorded; verify that the points at which a misstatement, including one due to fraud, could arise have been identified; identify the controls management has implemented at those points; and identify the controls over unauthorized acquisition, use, or disposition of assets. Paragraph 37 says walkthroughs “will frequently be the most effective way” of achieving them, and defines one as 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, through a combination of inquiry, observation, inspection, and re-performance.
Paragraph 38 is the one most walkthroughs miss: at the points where important processing occurs, the auditor questions personnel about what the prescribed procedures require, and those probing questions are what allow the auditor to identify points at which a necessary control is missing or not designed effectively. Paragraph 42 defines design effectiveness as whether the controls, operated as prescribed by people with the necessary authority and competence, can prevent or detect errors or fraud that could result in material misstatement, and paragraph 43 states that walkthroughs including inquiry, observation, and inspection “ordinarily are sufficient to evaluate design effectiveness.” Nothing there says a walkthrough evaluates operating effectiveness; that begins at paragraph 44 and needs a sample across the period.
For an internal audit function supporting SOX, paragraph 35 matters most: the external auditor must achieve the paragraph-34 objectives personally or through people under their direct supervision. Under paragraphs 16 and 17 they may use your work or take direct assistance from you, but they will not adopt your walkthrough as their own unless they supervised it, so offer a joint session rather than making the auditee tell the story twice. Management’s own 404(a) assessment needs its own basis for design conclusions, and the walkthrough is where most companies get it; the SOX scoping guide covers how the significant processes and classes of transactions that set the number of walkthroughs are chosen.
| AS 2201 concept | What it means at the desk |
|---|---|
| Origination to financial records (para. 37) | Start at the business event, not the journal entry; finish at the ledger posting and the bank statement, not the approval |
| Same documents and IT that personnel use (para. 37) | The performer’s live screen; a PDF export of the approval log is inspection, a slide of the workflow is nothing |
| Inquiry, observation, inspection, re-performance (para. 37) | Ask, watch the step happen, read what it produced, and redo the control yourself: recompute, re-match, re-check the approver against the delegation of authority |
| Probing questions, beyond the single transaction (para. 38) | The question bank below, plus the variant questions: non-PO, emergency, credit memo |
| Design effectiveness (paras. 42 and 43) | Capability, precision, and independence of the control, not whether it happened this time |
| Direct assistance (paras. 16, 17, 35) | Joint walkthroughs; hand over the evidence set with identifiers, not just the narrative |
Planning: the transaction, the people, and the checklist
Selecting the transaction
Four rules. Recent: within the last 60 to 90 days, so people remember it and the logs still exist (workflow histories in older ERPs are often purged at 90 days, OCR logs at 30). Complete: it has reached the ledger and the cash has moved, otherwise the recording, custody, and reconciliation steps, where most gaps sit, cannot be walked. Representative: it followed the dominant path with no emergency flag and no override, because you want the design of the normal control and will cover exceptions separately. Traceable: every document exists; a transaction whose invoice image is “on Priya’s desktop” is a retention observation, not a walkthrough item. Select it yourself from a population listing, such as purchase orders closed last month sorted by value, and take one from the middle of the range. Never accept the item the owner offers, which is reliably the cleanest one they have.
One walkthrough covers one path. Purchase-to-pay at a mid-sized company runs on at least six: PO-backed inventory purchases received in a warehouse module (largest by value, and the only true three-way match); PO-backed non-inventory purchases (largest by count; receipt is often an email or a service-entry sheet); non-PO invoices such as utilities and legal (authorization at invoice approval, manual coding, the highest duplicate risk); contract and recurring payments (authorized years ago, so the question is who checks the amount is still right); reimbursements and purchasing cards; and manual payments, wires, credit memos, and refunds (overrides by design, and where fraud goes once the main path is controlled). Walk the two largest paths by value and by count, run a twenty-minute mini-walk of one example for each remaining path, and record which paths you did not walk. The procurement and accounts payable guides lay out the risks on each.
Who to walk with
The process owner describes the process as designed; the clerk describes the process as performed. Spend twenty to thirty minutes with the owner for the map, the RCM as they understand it, and permission to sit with their people, then walk the transaction with the person who performed each step, at their desk or on their screen, in the order the transaction traveled; for a purchase-to-pay walk that is five to seven people across three departments. If the owner offers to walk you through the whole thing, decline; the object is to see what the owner does not see. Include the system administrator for every automated control, because the configuration is the control and only the administrator can show it to you. Ask each performer who covers when they are out and add the backup to the list; backup arrangements are where segregation of duties breaks.
The planning checklist
| Phase | Item | Done when |
|---|---|---|
| Before | Obtain the prior walkthrough, narrative, RCM, and delegation of authority policy; mark each RCM control with the step at which it should appear | A one-page map exists with numbered expected control points |
| Before | Pull the population listing, select the item yourself, and request its document set 48 hours ahead | The request names the PO, invoice, and payment identifiers |
| Before | Identify the systems and the interfaces between them; book the administrator for configuration screenshots | Every system boundary on the map has a named owner |
| Before | Confirm performers and backups by name and step; schedule 30 to 45 minutes each, in transaction order | One calendar slot per performer, at their screen |
| During | Open with the purpose statement and the “show me, don’t tell me” rule | The real transaction is open before the first question |
| During | For each step capture performer, trigger, system, document produced, control, and what happens when it fails; mark the step observed, inspected, inquired, or re-performed | All six fields and the procedure code exist for every step |
| During | Capture evidence as you go, with date, time, user, and record identifier visible | Every screenshot is named with step number and identifier |
| During | Record the timeline and ask the variant questions before leaving each desk | Elapsed time between steps is written down; the list of paths not walked exists |
| After | Reconcile what you saw against the RCM the same day: controls not seen, seen but different, seen but not in the RCM | Three lists exist |
| After | Write the design conclusion per control; clear facts with the performers, then the owner | The owner has confirmed facts, not conclusions |
| After | Update the audit work program and file using the documentation template, with evidence linked by identifier | A reviewer can re-trace the item without asking you |
The what-could-go-wrong question bank, by step type
The question at each step is not “what is the control here?”, which invites a recital of the RCM, but “what could go wrong at this step, and what would you see if it did?” The bank is organized by the six things a step can be: initiation (something creates a transaction), authorization (someone decides it may proceed), recording (it enters a system or ledger), custody (an asset, a payment instrument, or a credential is handled), reconciliation (two records are compared), and reporting (numbers leave the process for a decision maker). Classify each step on your map, ask the six prompts for its type, and follow the answers. The third column is what a worrying answer sounds like; you will hear the exact words more often than you expect. The Risk Library holds the process-level what-could-go-wrong entries these prompts are meant to surface.
Initiation steps
| Prompt | What it tests | The answer that should worry you |
|---|---|---|
| What event tells you a transaction needs to start, and where do you see it? | Completeness of initiation | “People email me” or “I check when I remember” |
| Can this be started twice for the same event, and how would you know? | Duplicate prevention at source | “The system lets you; we’d probably catch it later” |
| Who else can start one of these? Can a vendor or customer start it directly? | Population of initiators | “Anyone with ERP access” |
| What here is typed by hand, and what is pulled from a master record? | Accuracy at source; master data dependence | “I type the price from the quote” |
| What happens to one that is started and then abandoned? | Cancellation handling; audit trail | “We just delete it” |
| When did one last get started that should not have been? | Validity; the performer’s failure memory | “That doesn’t happen” |
Authorization steps
| Prompt | What it tests | The answer that should worry you |
|---|---|---|
| Who approved this one, and how did the system decide it was their turn? | Routing and DoA enforcement | “It goes to whoever is in the box” or “I pick the approver” |
| What did the approver actually see when they approved? Show me the screen. | Informed, precise approval | “Just the header and the amount” |
| Can the requester approve their own item, or approve for their manager? | Segregation; proxy settings | “If they’re on vacation I approve for them” |
| What are the limits, where are they maintained, and who can change them? | The DoA table as configuration | “IT set it up when we went live” |
| What happens if the approver does not respond in three days? | Timeouts and bypass paths | “After a week it auto-approves” or “We get a verbal” |
| How would something above the approver’s limit get approved? Show me one. | Split transactions; overrides | “You’d split it into two” |
Recording steps
| Prompt | What it tests | The answer that should worry you |
|---|---|---|
| What does the system check before it accepts this? | Validations and matching | “It takes whatever you enter” |
| What data comes from the previous system, and how do you know all of it arrived? | Interface completeness; rejects | “The file just loads” or “Rejects go to a folder” |
| What can be changed after posting, by whom, and does anything show it? | Change control; audit trail | “I can edit the amount if it’s wrong” |
| Where do the entries that do not fit the standard path get recorded? | The “other” queue; spreadsheets | “There’s a spreadsheet for those” |
| What date does the system use, and can you override it? | Cutoff; back-dating | “We change the posting date at month-end” |
| If you recorded this wrong, who would notice, and when? | Detective coverage and timing | “The auditors, I guess” |
Custody steps
| Prompt | What it tests | The answer that should worry you |
|---|---|---|
| Who can release the payment, move the stock, or hand over the asset, and who checks? | Dual control over assets | “One person, it’s faster” |
| Between this step and the next, where physically is the asset or the payment file? | The exposure window | “In the shared drive until Thursday” |
| Who holds the tokens, cards, keys, or portal credentials, and are any shared? | Access to assets | “We share the bank login” |
| What gets counted or confirmed, how often, and against which record? | Verification of custody | “We haven’t counted that in a while” |
| Can the person who ordered or approved this also receive or release it? | Ordering versus custody | “Yes, at the smaller depots” |
| Where do returns, refunds, and voided items go? | Reverse flows; diversion | “Back to whoever processed the original” |
Reconciliation steps
| Prompt | What it tests | The answer that should worry you |
|---|---|---|
| Which two records does this compare, and where does each come from? | Independence of sources | “The report and the same system’s other report” |
| Who prepares it, who reviews it, and what does the reviewer look at? | Independence and depth of review | “I prepare it and sign it off” |
| What is the threshold for investigating a difference, and who set it? | Precision | “Anything big” or “We don’t really have one” |
| Show me last month’s. Which items were open, for how long, and who cleared them? | Aging; write-off authority | “Those have been there since the conversion” |
| Is the report you reconcile from edited before you use it? | Reliability of the information | “I clean it up in Excel first” |
| What happens when the reconciliation is late? | Timeliness; visibility | “Nobody asks” |
Reporting steps
| Prompt | What it tests | The answer that should worry you |
|---|---|---|
| Who receives this report, and what decision do they make with it? | Relevance; control or formality | “I don’t know if anyone reads it” |
| How is it produced, which parameters does it use, and can the preparer change them? | Completeness and accuracy; parameters | “I run it with last month’s settings” |
| What in this report would make the reviewer act? Show me a time they did. | Precision and evidence of review | “It’s usually fine” |
| Are numbers re-keyed or copied between reports before they reach the reviewer? | Manual transfer; manipulation | “I paste the totals into the deck” |
| Who can change the report logic or the underlying query? | ITGCs over reporting | “The analyst who built it” |
| If this report were wrong by ten percent, who would catch it, and how? | Detective coverage | “Probably no one until year-end” |
Do not ask all 36 at every step; ask the six for the step’s type and follow the answer, because the useful discoveries come from the second question. An edited report surfaced by a reconciliation prompt is information produced by the entity on which the design conclusion now depends; the IPE testing guide covers what to do with it. A reviewer who signs without a threshold or a follow-up is a management review control with no precision, which the management review controls guide shows how to evaluate.
The interview script
Sit beside the performer, not across from them, so the conversation is about the transaction on the screen rather than about them. Ask for one transaction at a time and refuse the summary (“normally what happens is…”), because the summary is the narrative you already have. Write timestamps as the performer reads them off the screen. Leave silence after “what could go wrong here”; the first answer is the rehearsed one and the second is the real one. The script is written for a purchase-to-pay walk, but the structure transfers to any process.
Opening. “Thanks for making the time. I am following one real transaction, purchase order 48117, the handheld devices for the Columbus depot, from the moment somebody decided to buy them until the cash left the bank. I will ask you to show me on your screen rather than describe it, because I need to see the actual records. I am evaluating how the process is designed, not how you did your job. If the process makes you do something awkward to get your work done, that is exactly what I need to hear.”
At each step. “Show me what arrived at your desk for this one. What told you it had arrived? Now show me what you did with it, in the order you did it.”
Probe: failure memory. “What could go wrong at this step, in your experience? When did it last go wrong, and how did you find out?”
Probe: coverage. “Who else can do this step? Who did it when you were out in June? Did they do it the same way?”
Probe: the record. “Where did that get recorded? Open it. What did the system check before it let you save?”
Probe: the exception. “What happens when one doesn’t fit: the vendor isn’t set up, the amount is over the limit, the approver is away? Show me the last one like that.”
Probe: the shadow record. “Is there anything you keep outside the system to make this step work? A spreadsheet, an email folder, a notebook?”
Handoff. “Where does it go next, and how does that person know it is there? What do you send them, exactly? Show me the last one.”
Configuration (with the administrator). “Show me the setting that makes this happen: the tolerance, the routing rule, the limit table. When was it last changed, by whom, and where is that recorded? Who can change it today?”
Closing. “What did I not ask about that I should have? What is the step that only you know how to do? If you could change one thing about this process, what would it be?”
After the walk. “I will send you the factual parts of my write-up to confirm. Not my conclusions, only whether I have described what you do correctly.”
Three probes carry most of the value. “Who did it when you were out” exposes the untrained backup whose access was granted for a week in 2023 and never removed. “Show me the last one like that” converts a described exception path into an observed one, and about a third of the time the performer cannot find one, which tells you the path is undocumented. “The step that only you know how to do” produces the undocumented steps, workarounds, and key-person dependencies, volunteered by the person who owns them. Auditees who have read the site’s guide to what to expect during an internal audit tend to answer it more openly.
Following the transaction through systems and collecting evidence
System boundaries are where the narrative goes quiet
The dangerous places in any process are the seams, where the item leaves one system and enters another. A typical purchase-to-pay flow has four: the OCR tool into the payables module, purchasing into payables through the goods receipt, the ERP into the bank portal through a payment file, and the bank back into the ERP through the cleared-items feed. At each seam ask three things: how does the receiving side know it got everything (control totals, record counts, sequence numbers); what happens to rejects and who works them; and who can touch the data between the two systems. The payment file that sits in a shared folder for forty minutes between generation and upload is the classic, and the narrative never mentions it because from the performer’s point of view nothing happens in those forty minutes. The ITGC primer for non-IT auditors explains the interface and access concepts you need at the seams.
Automated controls need the configuration, not the story
For every automated control, the design evidence is the configuration screen, the date it was last changed, and the list of people who can change it. “The system won’t let you” is inquiry; the screenshot of the parameter is inspection. Ask for the change log as well, because a tolerance last changed by a consultant account in 2019 is itself a design observation: nobody currently employed decided the setting is right. The design conclusion on an automated control then rests on general IT controls over change and access to the parameter, the dependency the ITGC vs. application controls guide describes; if those ITGCs are not tested, the conclusion is conditional and should say so.
The evidence set
| Step | Evidence to capture | What it proves |
|---|---|---|
| Initiation | Requisition or order record with creator and timestamp, plus the quote or contract each keyed value came from | Who starts transactions and what is entered by hand |
| Authorization | Workflow log with approver, timestamp, and limit; DoA table screenshot; the board-approved DoA policy | Routing and limit enforcement; approver authority |
| Master data | Vendor or customer record with creation date, last change, and changer | Dependence on master data; see the vendor master audit guide |
| Recording | The posted voucher with its match result, and the ledger document | Which validations ran and which tolerance applied |
| Interface | Control total, batch log, or reject report for each transfer; folder permissions | Completeness of transfer; exposure between systems |
| Custody | Payment proposal with approval; bank portal audit trail with uploader and releaser | Dual control over the release of cash |
| Reconciliation | The month’s reconciliation with preparer, reviewer, dates, and aged open items | Independence, timeliness, precision |
| Configuration | Parameter screens for each automated control with last-change date and changer | Existence and stability of the automated control |
| Roles | Role assignments for every performer and backup | Segregation across the four functions |
Evidence should be contemporaneous, system-generated where the system can generate it, and linked in a chain of identifiers (requisition, PO, receipt, invoice, payment, ledger document, bank reference) so a reviewer can re-trace the item without you. Take the screenshots yourself with system date, user, and identifier visible; “I’ll send it later” produces cropped, undated images a week after the walk. Re-perform what can be re-performed: re-match the invoice to the PO and the receipt, recompute the amount, and check the approver against the DoA policy rather than the DoA table, since the table is the thing being tested. The audit evidence guide sets out the reliability hierarchy and the workpaper best practices guide the file conventions.
Spotting undocumented steps and segregation problems
| Signal during the walk | What it usually means | What to do |
|---|---|---|
| “Usually,” “normally,” “unless” | A second path with different controls, or none | Ask for the last one that was not usual and walk it |
| A name instead of a role (“I send it to Dana”) | The control depends on an individual, with no backup or segregation analysis | Get the role assignment; ask who does it when Dana is out |
| A gap in the timeline (approved on the 10th, received on the 24th) | Something undescribed happened in between: an email, a spreadsheet, a call | Ask what happened on each day in between; read the email |
| A spreadsheet, an email folder, a notebook | A control or record lives outside the system, without access control or audit trail | Inspect it; treat it as information produced by the entity |
| Printing, signing, scanning | A manual control layered on a system transaction; the original may be gone | Establish whether the system approval exists and whether the paper adds anything |
| “I just…” or “we just…” | A workaround that bypasses a control the RCM lists | Ask what the system would do if they did not; that is the missing control |
| The same person on two consecutive steps | Request and approve, receive and match, prepare and release, reconcile and post | Map the four functions per person before concluding |
| “The system won’t let you” | A claimed automated control | Get the configuration and the change log before writing it down as a control |
The segregation test in a walkthrough is simple and rarely done: write each performer and backup next to each step, then check every person against the four incompatible functions of authorization, custody, recording, and reconciliation. Two in the same hands is a question; three is a finding unless a documented compensating control exists, and “the controller looks at everything” is not documented. The segregation of duties guide covers compensating controls for small teams and the ERP SoD analysis guide the system-wide version. Classify each control as preventive or detective while you remember how it behaved; the preventive, detective, and corrective controls guide explains why a process whose only controls are detective and monthly leaves a thirty-day window in which anything can happen.
From gaps to design conclusions and test plans
The design question has three parts, and a conclusion that answers only the first is incomplete. Does a control exist at the what-could-go-wrong point, as performed rather than as described? Is it precise enough to catch an error or fraud of the size that matters, given its threshold, its level of aggregation, and its frequency? Is it performed by someone independent of the step it checks, with the competence, authority, and information to perform it? A monthly budget-versus-actual review by the person who raised the requisitions, at account level, with a $5,000 investigation threshold, exists, and fails the second and third parts for a $1,170 overbilling. Build the RCM from those three answers; the free RCM Workbench on the site’s Tools page and the risk-control matrix template carry precision and independence columns for this reason.
| What you observed | Design conclusion | What happens next |
|---|---|---|
| Control exists as described, addresses the point, and is precise and independent | Designed effectively | Test operating effectiveness with a sample sized to frequency and risk |
| Control exists but differs from the RCM and still addresses the risk | Designed effectively; RCM inaccurate | Correct the RCM; test the control as it actually operates |
| Control exists but is too coarse for the risk (threshold too high, account-level review, tolerance without a cap) | Design deficiency for the risk below its precision | No operating-effectiveness test for that portion; look for another control; size the exposure with analytics or substantive work |
| Performer is not independent of the step checked | Design deficiency unless a compensating control exists | Evaluate the compensating control on its own merits; otherwise deficiency plus substantive procedures |
| Control relies on unvalidated information (an edited report, a spreadsheet, an email) | Depends on the reliability of the information | Test the information; if unreliable, the control cannot be relied on however well it is performed |
| No control at the point | Design gap | Deficiency evaluation; substantive procedures to establish whether loss occurred; finding |
| Effective control observed but absent from the RCM | Designed effectively; undocumented | Add it; consider testing it in place of a weaker documented control |
When a control fails design, do not sample twenty-five of it “to see how it is operating.” A control that cannot catch the risk will operate consistently and prove nothing, and the hours come out of the work that matters. The only reason to look at the population is to size the exposure, which is substantive work planned as such; the substantive testing guide covers the design and the control deficiency evaluation guide the rating. Document the gap the same day with the evidence attached, clear the facts with the performer and the owner before writing the conclusion, and rate it with the site’s finding severity ratings. A design deficiency observed on one transaction is reportable on that basis alone, because the question is whether the control could work, not whether it did this time; the substantive work tells you what it cost.
Worked example: a purchase-order-to-payment walkthrough at MidState Beverage
MidState Beverage is the site’s running example: a three-state distributor with 12 depots, 300 routes, a 2013 ERP with a route-accounting module, two recently acquired distributors not yet on the ERP, a lean finance team, and a six-person internal audit function. Its FY27 plan includes ICFR support, and purchase-to-pay is one of the significant processes walked each year for it. In August 2026 the audit senior selected PO 48117 from the 187 purchase orders closed in June, sorted by value, taking an item near the middle of the range: 24 rugged handheld route devices for the Columbus depot from Ridgeline Mobile Solutions (vendor V-20388) at $1,185 each, PO value $28,440, invoice $29,610, paid 2 July 2026. It was recent, complete, traceable, and on the largest path by count, PO-backed non-inventory purchases; the depot’s motive was clear too, since the FY27-01 route cash report had found handheld sync failures unmonitored and Columbus was replacing failing units. The prior-year narrative listed nine controls, P2P-01 through P2P-09.
| Step | Performer and system | What we observed | RCM control | Evidence captured |
|---|---|---|---|---|
| 1. Requisition | Luis Ortega, Columbus depot manager; ERP purchasing, REQ-9932, 9 June 09:14 | Raised with quote Q-2026-311 attached; unit price keyed by hand from the quote | None; P2P-01 sits at approval | Requisition screen; quote PDF |
| 2. Approval | Marcus Bell, regional operations director; ERP workflow, 10 June 08:42 | Routed to Bell because the amount exceeded the depot manager’s $10,000 limit; Bell saw header, amount, and quote | P2P-01: DoA approval enforced by workflow | Workflow log; DoA table screenshot (limits last changed March 2025, matching the board policy) |
| 3. PO creation | Dana Whitfield, purchasing coordinator; ERP, PO 48117, 10 June 11:05 | Vendor selected from the master; the system refused an inactive vendor when tried on screen | P2P-02: PO only to active approved vendors | PO PDF; vendor record (created 2019); role listing showing Whitfield also holds the vendor-maintain role, referred to the FY27 ERP user access engagement |
| 4. Goods receipt | Whitfield, on an email from Ortega; ERP receipt against PO 48117, 24 June 16:20 | Ortega emailed “24 received, all working” at 15:52; Whitfield keyed the receipt. Nine of twelve depots have no receiving screen for non-inventory items | P2P-03: receipt recorded by receiving personnel independent of purchasing | Ortega’s email; receipt screen showing Whitfield as user; receipt user report: 1,840 of 2,310 FY26 non-inventory receipts entered by purchasing |
| 5. Invoice capture | Priya Raman, AP specialist; OCR tool into the ERP voucher, 22 June | Invoice INV-77120 dated 19 June arrived in the AP mailbox; OCR built the voucher; Raman corrected the date field and released it to match, where it waited for the receipt | P2P-05: invoice indexed and duplicate-checked on vendor plus invoice number | Invoice image; OCR log; duplicate-check parameter screen |
| 6. Three-way match | ERP automated; 24 June 16:31 | Quantity 24/24/24. Header $29,610 against PO $28,440: $1,170 (4.1 percent) for $780 freight and a $390 license, neither on the PO; passed because the price tolerance is 10 percent with no dollar cap. Raman on the within-tolerance variance report: “I don’t think anyone looks at that” | P2P-04: automated three-way match; variances outside tolerance blocked | Match log; tolerance configuration (10 percent, no cap, last changed 14 November 2019 by a consultant account); variance report: 212 FY26 invoices, $143,600, largest $9,850 |
| 7. Payment proposal | Raman prepares; Janet Moore, controller, approves by email; 2 July 14:05 | Weekly Thursday run; Moore reviewed vendor, invoice, amount, and due date; the listing does not show PO variance | P2P-06: payment run approved by the controller | Proposal listing; approval email |
| 8. Payment release | Tom Keane, treasury analyst, uploads; Renee Alvarez, assistant controller, releases; bank portal, 2 July 15:20 | ACH file written by the ERP to a shared folder writable by all of finance for about forty minutes before upload | P2P-07: dual control over payment release | Bank portal audit trail; folder permissions listing |
| 9. Recording and reconciliation | ERP posting; AP-to-GL reconciliation by Raman, reviewed by Alvarez; bank reconciliation reviewed by Moore, 9 July | Expensed to account 6410, route equipment, Columbus cost center, under the $2,500 per-unit capitalization threshold; June AP reconciliation had three items open over 60 days, all explained | P2P-08 and P2P-09: subledger and bank reconciliations | Ledger document; June reconciliations with sign-offs and dates |
Gap 1: the third leg of the match is purchasing
The RCM describes P2P-03 as a receipt recorded by receiving personnel independent of purchasing. For non-inventory purchases at nine of the twelve depots, the receipt is keyed by the purchasing coordinator on the strength of an email from the person who asked for the goods. Independence is lost twice: purchasing records the receipt, and the requester, the one person with something to gain from a fictitious or short receipt, is the only source of confirmation. The three-way match on this path is a two-way match plus an email, on $7.9 million of the $11.2 million non-inventory PO spend in FY26. Goods paid for and never received, short shipments accepted in full, personal purchases routed to a depot, a kickback arrangement with a vendor: no control on the path addresses any of them. The candidate compensating control, the depot manager’s monthly budget-versus-actual review, is performed by the requester at account level with a $5,000 threshold and confirms spending against plan, not receipt. Conclusion: design deficiency; the control described in the RCM does not exist for this path.
Gap 2: a tolerance that is not a control
A 10 percent price tolerance with no monetary cap lets the match pass an overbilling of up to $2,844 on this PO and $20,000 on a $200,000 PO without anyone seeing it. The setting would be defensible if the within-tolerance variance report were reviewed, which would turn the pass-through into a detective control; nobody runs it. The administrator ran it during the walkthrough: 212 FY26 invoices with price variances totaling $143,600. Not all of that is improper, since freight legitimately appears on invoices and not on POs, but nobody has decided which part is, and the controller’s payment approval cannot catch it because the listing does not show PO variance. Conclusion: P2P-04 is designed effectively for quantity and for variances above 10 percent, and not for price variances within tolerance. The accounts payable analytics guide has the invoice-to-PO variance query that turned the gap into a population number the same afternoon.
The design conclusion as written
P2P-03, goods receipt independent of purchasing. Conclusion: not designed effectively for non-inventory purchases received at depots without the inventory receiving module (nine of twelve depots; $7.9 million of FY26 PO spend). Basis: receipt recorded by the purchasing coordinator on the strength of an email from the requester, observed on PO 48117 (receipt entered 24 June 2026 by user DWHITFIELD); the receipt user report shows 1,840 of 2,310 FY26 non-inventory receipts entered by purchasing. No compensating control: the depot budget review is performed by the requester at account level with a $5,000 threshold and does not confirm receipt. Effect on testing: no test of operating effectiveness; substantive procedure added, 40 FY26 depot receipts traced to asset registers or serial-number records and to carrier delivery evidence. Reported as a High finding.
P2P-04, automated three-way match. Conclusion: designed effectively for quantity matching and for price variances above 10 percent; not designed effectively for price variances within tolerance. Basis: tolerance configured at 10 percent of PO value with no monetary cap (inspected 12 August 2026 with the ERP administrator; last changed 14 November 2019); the within-tolerance variance report is reviewed by no one; the payment approval (P2P-06) does not present PO variance. Observed on PO 48117: $1,170 (4.1 percent) paid without review; population indicator 212 FY26 invoices, $143,600. Effect on testing: operating-effectiveness test limited to quantity matching and above-tolerance blocking, 25 items from the blocked-invoice log; analytics over the full FY26 invoice population for price variance by vendor and by requester. Recommendation: tolerance of the lesser of 2 percent or $250, with weekly review of the variance report by the AP supervisor. Reported as a Moderate finding.
What changed in the work program
P2P-01 and P2P-02 go to operating-effectiveness testing as planned, 25 approvals against the DoA policy and 25 POs against vendor status. P2P-03 is dropped from operating-effectiveness testing for the depot path and replaced by the 40-item receipt trace. P2P-04 is tested only for what it is designed to do, with analytics carrying the rest. P2P-06 is tested as a management review control across five weekly runs, with the question of what Moore would have to see to reject a payment written into the test. P2P-07 is tested across 25 releases, and the writable shared folder goes into the report as a Low observation with an immediate fix. P2P-08 and P2P-09 are tested for three months each. Whitfield’s vendor-maintain role was passed to the FY27 ERP user access engagement rather than reported twice, and the two acquired distributors, which run their own purchasing systems, were scheduled for separate walkthroughs. The whole exercise took 14 hours; the breakdown is in the next section.
Remote walkthroughs, time budgets, and edge cases
Remote and virtual walkthroughs
A remote walkthrough can meet the AS 2201 definition, since the performer’s shared screen is the same information technology company personnel use, but it loses the peripheral vision that makes in-person walks productive: the second monitor with the spreadsheet open, the sticky note with the shared password, the stack of unreceived invoices on the desk. Insist on the live application window, never a slide deck or a recording made in advance, and record the session with consent so the evidence is the recording rather than your notes. For custody steps in cash and inventory processes, a video call is not a substitute; put a site visit in the plan.
| In-person move | Remote substitute | What you lose, and how to compensate |
|---|---|---|
| Sit beside the performer and watch the screen | Performer shares the live application window | Peripheral vision; ask “what else is open for this process right now” and “what is on your desk for this” |
| Capture screenshots yourself | Ask the performer to pause; capture from the shared screen with date, time, user, and identifier visible | Control over cropping; keep a capture log and name each capture immediately |
| Observe the handoff between two people | Bring both into the same call for the handoff step | The queue between them; ask each to show their worklist live |
| Meet the administrator at the console | Administrator shares the configuration screen and the change log | Nothing in evidence quality; scheduling friction, so book the administrator at planning |
| Read hesitation | Camera on, one transaction at a time, silence after “what could go wrong” | Some candor; ask the closing questions one-on-one rather than in a group |
Time budgets
Walkthroughs run over budget for three reasons: the auditor walked with the owner only and had to go back, evidence was promised rather than captured and had to be chased, and documentation was left for a week and reconstructed from memory. Budget by complexity tier, and treat documentation and the reconciliation to the RCM as a third of the total, because that is where the design conclusions get written. Each additional path walked adds roughly 40 percent of the session and evidence hours and 25 percent of the documentation hours.
| Tier | Example | Preparation | Sessions | Evidence and configuration | Documentation, RCM reconciliation, review | Total hours |
|---|---|---|---|---|---|---|
| Simple: one department, one system, three to five steps | Fixed asset additions; payroll master data changes | 1.5 | 1.5 | 1.0 | 2.0 | 6 |
| Standard: two or three departments, one ERP plus a satellite tool, six to ten steps | PO-to-payment for non-inventory; order-to-cash for standard sales | 2.0 | 4.0 | 2.5 | 5.5 | 14 |
| Complex: multiple entities or systems, manual interfaces, high exception volume | Route cash settlement across depots; revenue with manual pricing; acquired entities on legacy systems | 4.0 | 8.0 | 5.0 | 9.0 | 26 |
| MidState PO 48117, actual | Owner 1.0; six performers 3.0; administrator 0.5 | 2.0 | 4.5 | 2.5 | 5.0 | 14 |
Edge cases
Fully automated steps have no performer to sit with; walk them with the system owner and the configuration, treat the job log as the evidence of the step, and ask who is alerted when the job fails, because an automated step with no failure alert is an undocumented manual step waiting to happen. Outsourced steps are walked with the provider’s staff where the contract allows; where it does not, the SOC 1 Type 2 report stands in for the provider’s controls and the complementary user entity controls it lists become steps you walk on your own side. Acquired entities on legacy systems, MidState’s two distributors among them, get their own walkthroughs from the start; assuming the parent’s process applies is the most common way an acquisition’s gaps survive two audit cycles. Small teams where one person initiates, records, and reconciles need the walk to concentrate on owner-level compensating controls, with the conclusion stating which risks those cover and which they do not. High-volume cyclical processes such as route cash settlement are walked as one full cycle at one location and then re-walked at a second, because locations differ; the FY27-01 finding that settlement reconciliations were not independent at nine of twelve depots would never have surfaced from a walk of the best-run depot. Where fraud exposure is known, carry the process’s fraud red flags into the session as extra prompts.
Common walkthrough failures
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Walking with the owner only | The narrative is confirmed by the person who wrote it | Design as described; undocumented steps stay invisible | Thirty minutes with the owner, then one session per performer at their screen |
| Accepting the auditee’s sample | “Here is a clean one from last week” | Selection bias; the process on its best day | Select from the population listing yourself and state the basis |
| Stopping at the approval | The walk ends when the PO is approved or the invoice is coded | Recording, custody, and reconciliation go unseen, and payment release is where cash leaves | Origination to the bank statement, every time |
| Inquiry recorded as observation | “Observed that the system blocks…” when the auditor was told it | The conclusion rests on hearsay a reviewer cannot rely on | Mark each step O, I, Q, or R; get the configuration for anything automated |
| Treating the walkthrough as a test of one | The walked item counts toward, or replaces, the operating-effectiveness sample | One purposively chosen item proves nothing about a period | Keep design and operating effectiveness separate |
| Testing operating effectiveness of a control that failed design | Twenty-five samples of a receipt entry keyed by purchasing | Hours spent proving a non-control operated consistently | Stop at the design conclusion; redirect the hours to substantive work |
| No segregation map | Performer names not captured per step; conflicts noticed months later | The cheapest segregation test in the engagement is skipped | Performer and backup per step, four-function check before leaving |
| Writing it up a week later | Unnamed screenshots, a timeline reconstructed from memory | The details that made the gap visible are gone | Same-day RCM reconciliation; documentation within two working days |
| Clearing conclusions with the owner instead of facts | The deficiency is negotiated away in the closing meeting | Disagreement about the rating becomes disagreement about what was seen | Facts with the performers and owner, conclusions with your manager; the owner’s disagreement goes in the report |
The pattern across all nine is the same: the walkthrough degrades into an interview the moment the auditor stops insisting on the real transaction, the real screen, and the real performer. Hold those three and the design conclusions write themselves. The workpaper example shows what a filed walkthrough with its conclusions looks like, and the 5 Cs of audit findings gives the structure for turning the two MidState gaps into findings the audit committee can act on.
Related guides
- Walkthrough documentation template — the write-up format this guide’s conduct feeds into
- Test of design vs. operating effectiveness — the distinction every design conclusion depends on
- Audit evidence — the reliability hierarchy for the evidence set
- Audit work program — where the post-walkthrough test plan lives
- Segregation of duties — the four-function analysis and compensating controls
- Control deficiency evaluation — rating the gaps a walkthrough finds
- How to audit accounts payable — the full risk and test catalog for the process walked above
- IPE testing — what to do when the control relies on a report
- Topics — every guide on the site by subject
- All Guides — the full index
Leave a Reply