What Can Go Wrong? From Process Flow to Control Test

A control test should begin with a possible failure in the process, not with a convenient document to inspect. Understanding the transaction flow gives the test its purpose.

Map the transaction before naming the control

In an illustrative purchasing process, follow the request, authorisation, order, receipt, invoice and payment. Identify where information is created, changed, transferred and reviewed.

The useful map includes exceptions and bypass routes. A flowchart that shows only the standard path may hide the point where a transaction can proceed without the intended challenge.

State what can go wrong precisely

“Purchasing risk” is too broad to guide testing. A more useful illustrative statement is: an invoice for goods not received could proceed to payment if the receipt is not independently validated.

This statement identifies a failure, an enabling condition and a consequence. It can be linked to the relevant business objective and, for financial-reporting assurance, the assertion at risk. The same process can have several distinct failures; do not force them into one generic risk sentence.

Connect the control to that failure

An illustrative matching control might require an independent comparison of order, receipt and invoice, with differences investigated before payment.

Ask what makes that control capable of interrupting the failure: the information used, criteria, reviewer, timing and treatment of differences. An approval label alone does not explain how the control addresses the risk.

Evaluating design and determining implementation are separate from establishing operating effectiveness. ASA 315, paragraph 26(d) and A180

Design a test of the action

If the purpose is to assess whether the matching control operated, seek evidence about the matching performed and exception resolution. Depending on the control and circumstances, this could involve inspection and reperformance, together with understanding who performed the activity and when.

A financial balance check may answer a different question. Do not describe every procedure over the same transactions as a test of that control.

Control testing considers actual operation, relevant dependencies and the period of intended reliance; enquiry is combined with other procedures. ASA 330, paragraphs 10–11

Follow the evidence back to the risk

The workpaper should show a traceable chain:

• Process: where the transaction and information move.
• What can go wrong: the specific failure and consequence.
• Control: the action expected to address that failure.
• Test: the procedure and scope designed to assess the action.
• Evidence: what was obtained, including exceptions.
• Conclusion: what the result supports and what remains unresolved.

This is an original working structure, not a mandated six-box template.

For the illustrative purchasing case, finding a signed matching sheet may lead to further questions about the receipt information or an unresolved difference. The conclusion should reflect those facts, rather than stop at “document available.”

Keep three conclusions distinct

A control can appear suitably designed, be implemented at a point in time, and still fail during operation. Conversely, an isolated exception requires evaluation in context rather than an automatic conclusion about every transaction.

The absence of a detected misstatement does not itself demonstrate that a related control operated effectively. ASA 330, paragraph 16

Document which question was answered. If a needed control is absent or poorly designed, do not invent evidence of effectiveness; assess the implications and appropriate response.

Use the map to improve decisions

A clear chain helps management see the failure mechanism and helps a reviewer evaluate whether the procedure addressed it. It also keeps remediation focused on the cause instead of adding another vague approval.

This educational application uses Australian auditing standards as references. Actual testing requires the process, risk, engagement objectives and applicable requirements.

Every test needs a line back to what can go wrong.