Using Walkthroughs, Flowcharts, and Narratives to Document Controls

Walkthroughs, flowcharts, and narratives help auditors understand how transactions move from initiation to recording. The documentation is useful only if it connects process steps to assertions, control points, responsible parties, IT dependencies, and exceptions.

For AUD, these tools support risk assessment and control understanding. A walkthrough traces one transaction or a small selection through the process. A flowchart shows the process visually. A narrative explains the process in writing and can capture context that a diagram omits.

What Each Documentation Method Does

The auditor chooses the method based on complexity. A simple cash disbursement process may be clear in a narrative. A complex order-to-cash cycle with system interfaces, credit approvals, shipping, invoicing, and collections may need a flowchart plus a narrative.

Walkthroughs

A walkthrough traces a transaction from initiation through authorization, processing, recording, and reporting. The auditor may use inquiry, observation, inspection, and reperformance while following the transaction path.

Walkthroughs help the auditor understand:

• Whether the process described by management actually exists.
• Whether controls are designed to address relevant risks.
• Whether controls have been implemented.
• Which documents, systems, reports, and people are involved.
• Where errors, overrides, or exceptions could occur.
• Whether IT dependencies affect manual or automated controls.

A walkthrough is not the same as a test of operating effectiveness. It can support understanding of design and implementation, but relying on a control usually requires additional evidence about consistent operation over the relevant period.

Flowcharts

Flowcharts are most useful when a process has multiple handoffs, systems, documents, approvals, or decision points. A good audit flowchart does more than show movement. It identifies control points and risk points.

    flowchart TD
	    A["Invoice received"] --> B["Match to purchase order and receiving evidence"]
	    B --> C{"Match within tolerance?"}
	    C -- "Yes" --> D["Approve for payment"]
	    C -- "No" --> E["Route exception for review"]
	    E --> F{"Exception resolved?"}
	    F -- "Yes" --> D
	    F -- "No" --> G["Hold invoice and investigate"]
	    D --> H["Record payable and schedule payment"]

In this example, the decision points matter because they show where controls should operate. The auditor would ask who reviews exceptions, what evidence supports resolution, whether system tolerances can be changed, and whether held invoices are monitored.

Narratives

A narrative explains the process in words. It is especially useful for describing judgment, exception handling, frequency, responsible parties, system names, report names, and why a control addresses a risk.

A strong narrative usually identifies:

• The transaction source and initiation point.
• The roles responsible for authorization, recording, custody, and review.
• Documents, reports, and system screens used.
• Manual and automated controls.
• Frequency of controls.
• Exception handling.
• Segregation-of-duties considerations.
• Financial statement assertions affected.

The weakness of a narrative is that it can hide complexity. If the process has many branches, a flowchart may reveal gaps more clearly.

Documentation Quality

Control documentation should be current, risk-linked, and reviewable. The auditor should be able to read the documentation and understand what risk the control addresses and how the auditor confirmed implementation.

Inquiry alone is generally not enough. The auditor should corroborate process understanding through observation, inspection, or reperformance where appropriate.

Example: Inventory Adjustment Process

A warehouse supervisor can enter inventory adjustments in the inventory module. The accounting department receives a weekly adjustment report and reviews unusual items. The auditor performs a walkthrough for one adjustment from warehouse initiation through accounting review.

The walkthrough shows that:

• The system allows several warehouse users to enter adjustments.
• The weekly report is generated automatically.
• Accounting reviews large adjustments but does not review small recurring adjustments.
• The report parameters can be changed by the warehouse supervisor.
• Evidence of review is inconsistent.

This documentation changes the risk assessment. The issue is not only that inventory adjustments exist. The risk is that unauthorized or unsupported adjustments may affect existence, completeness, and valuation of inventory. The auditor may need to evaluate user access, report reliability, review-control design, and substantive inventory procedures.

Common Exam Traps

• Treating a walkthrough as a full test of operating effectiveness.
• Relying on inquiry alone to understand implementation.
• Creating process documentation that does not identify control points.
• Ignoring IT dependencies in a process that uses system reports or automated approvals.
• Failing to update documentation after system or personnel changes.
• Documenting what should happen under policy without identifying what actually happens in practice.

Key Takeaways

• Walkthroughs validate understanding of design and implementation.
• Flowcharts show sequence, handoffs, decisions, and control points.
• Narratives explain context, roles, frequency, exceptions, and rationale.
• Documentation must link controls to risks and assertions.
• Current-year process changes can make prior-year documentation unreliable.

Walkthroughs, Flowcharts, and Narratives Quiz