An audit walkthrough traces one real transaction from start to finish through a process, asking the people involved what they actually do at each step and inspecting the document produced. Its purpose is to confirm that your understanding of the process and its controls is accurate, which SA 315 (Revised) requires before you assess risks of material misstatement. A walkthrough shows how a process is designed to work; it does not on its own prove that a control operates effectively.
Facts checked: 10 October 2026. SA 315 (Revised) requiring an understanding of the entity's information system and control activities was confirmed from an ICAI branch newsletter reproducing the standard (secondary), not from the standard on icai.org, which could not be fetched. The word "walkthrough" is practice terminology; to our reading SA 315 does not mandate it by name. The 15 questions and the example are our own working method, not an ICAI prescription.
What a walkthrough is, and why auditors do it
SA 315 asks the auditor to understand the entity's information system, including the business processes relevant to financial reporting, and the control activities that address risks. Inquiry alone is weak evidence. A walkthrough combines inquiry, observation and inspection of one transaction, so you catch the common gap between the written procedure and what staff really do.
It serves three purposes: confirm you have identified the right points where errors could arise, confirm that the controls you plan to rely on are actually implemented, and decide where to test operating effectiveness under SA 330. For the surrounding steps, see the audit process from planning to report.
How to run one
- Pick a transaction from the current year, ideally a recent one that went through the full cycle.
- Interview the person who does each step, not only the manager who owns the process.
- Ask them to show you the system screen or document, not describe it.
- Follow the transaction to the general ledger and to the financial statements.
- Note every deviation from the process narrative or RCM and resolve it before you rely on the control.
The 15 questions, with good and bad answers
| # | Stage | Question | Good answer | Warning sign |
|---|---|---|---|---|
| 1 | Initiation | What triggers this transaction, and where is it first recorded? | A system-generated or approved document with a unique number | "We note it down and enter it later" |
| 2 | Initiation | Who can initiate it, and how is that limited? | Role-based access, list reviewed periodically | Anyone in the team, shared logins |
| 3 | Initiation | Which master data (customer, rate, vendor) does it depend on? | Master changes need approval and are logged | Sales staff edit price lists freely |
| 4 | Authorisation | Who approves it, and what are the limits? | Written delegation of authority, limits enforced by the system | Approval is verbal or after the fact |
| 5 | Authorisation | What does the approver see before approving? | Supporting documents and checks against credit or budget | Approves on a summary only |
| 6 | Authorisation | Can the same person initiate and approve? | System blocks it | "It happens when the manager is away" |
| 7 | Recording | How does it reach the books, and how soon? | Automatic posting, with date controls | Manual journal at month end |
| 8 | Recording | What reconciles this ledger to its source? | Monthly reconciliation signed by someone independent | No reconciliation, or prepared and reviewed by one person |
| 9 | Recording | How are errors and exceptions handled? | Exception report, logged and cleared | Corrected by overwriting |
| 10 | Custody | Who has physical or system custody of the asset, cash or goods? | Separate from those who record | Same person dispatches and invoices |
| 11 | Custody | How is movement of the asset evidenced? | Gate pass, delivery challan or bank advice matched to the record | No document, or created later |
| 12 | Custody | What happens to documents after processing? | Filed, retrievable, retention policy known | Cannot produce on request |
| 13 | Reporting | Which reports from this process go to management? | Defined reports, reviewed with evidence of review | Report exists but nobody acts on it |
| 14 | Reporting | How are unusual items escalated? | Written escalation with thresholds | Informal phone call |
| 15 | Reporting | What changed in this process this year? | Change log, new system or people noted | "Nothing" when staff say otherwise |
Worked example (illustrative): order-to-cash
Entity: a fictitious manufacturer, Kaveri Fasteners Private Limited, Coimbatore. Transaction chosen: sales invoice KF/26-27/04182 for ₹8,64,000 plus GST, dated 14 August 2026, to a Pune distributor.
- Initiation (Q1 to 3): The distributor's purchase order was entered by a sales coordinator in the ERP. You ask her to open the order; it carries a system number. Price came from the approved price list, and you confirm list changes need a sales head's approval.
- Authorisation (Q4 to 6): The credit limit for this customer is ₹10,00,000 and the order passed the system check. The finance team released it. You note that credit limit changes are made by the finance controller, not sales.
- Custody (Q10 to 11): The warehouse issued goods against a dispatch note and the gate pass shows the vehicle number. The warehouse staff do not have invoicing access.
- Recording (Q7 to 9): The invoice posted automatically to revenue and receivables. You find that the e-invoice acknowledgement appears only after posting, and ask what happens on a failure. The answer is a manual retry log, which you request.
- Reporting (Q13 to 15): The monthly debtors ageing goes to the CFO. You ask for last month's copy showing a review signature. It had none.
Conclusion for the working paper: design of credit, pricing and segregation controls is appropriate; the debtors-ageing review is not evidenced. You move the ageing review to the list of controls to test, or treat it as not relied upon and extend substantive procedures on debtors.
Documenting it in the working paper
Record: the process and period covered, the transaction identified by number, date and amount, each person interviewed with role and date, the document inspected at each step, the control identified and its type (manual, automated, IT-dependent), deviations from the narrative, your conclusion on design and implementation, and the effect on your audit plan. Attach copies of the documents. A reviewer should be able to re-perform the trace from your file.
AI-assisted preparation of walkthrough questions is covered in AI prompts for internal audit. Use the order-to-cash checklist or the procure-to-pay checklist to build the process-specific question list.
Frequently asked questions
Is a walkthrough the same as a test of controls?
No. A walkthrough usually covers one transaction to confirm design and implementation. A test of controls samples many transactions to conclude on operating effectiveness.
How many transactions should I walk through?
Usually one per significant class of transaction or process, per year. Use more where the process has distinct variants, such as export and domestic sales.
Can I rely on last year's walkthrough?
Not without inquiry. You must confirm what changed. If the process, system or people are unchanged, a lighter update is common practice; document the basis for that.
Who should I speak to?
The people who perform each step, plus the process owner. Interviewing only the owner is the most common reason a walkthrough misses the real process.
Does a clean walkthrough mean the control works?
No. It shows design and implementation at one point in time. Operating effectiveness needs testing across the period.
Where do walkthroughs fit in internal audit?
They feed the risk and control matrix and the audit programme. See what internal audit is and who needs it.
For definitions of terms used here, see the audit glossary.
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error