## Designing Confirmation Requests: ALARM2 Framework
When designing a confirmation request, the auditor considers the following factors (mnemonic: ALARM2):
| Letter | Factor |
|---|---|
| A | Assertions for which external confirmation is being prepared |
| L | Layout and presentation of the confirmation request |
| A | Ability and willingness of the intended confirming party to confirm |
| R | Risk of material misstatement (ROMM), including fraud risk |
| M1 | Mode of communication — paper, electronic, or other medium |
| M2 | Management's authorisation for third parties to respond (confirming parties may refuse without it) |
| S | Prior experience on the audit or similar engagements |
---
## Controls over the External Confirmation Procedure (4 Steps)
Step 1 – Determine information to be confirmed/requested
May include terms of agreements, contracts, or transactions; may also confirm the absence of conditions (e.g., no side agreements).
Step 2 – Select appropriate confirming party
Responses are more reliable when sent to a party the auditor believes is knowledgeable about the information being confirmed.
Step 3 – Design confirmation requests
Apply the ALARM2 framework.
Step 4 – Send requests and follow-up requests
If no reply is received within a reasonable time, the auditor may send an additional confirmation request.
---
## Evaluating Evidence Obtained from Confirmations
The auditor categorises results from individual confirmation requests into four groups:
| Category | Description |
|---|---|
| Agreement | Response confirms the information — provides direct audit evidence |
| Response deemed unreliable | e.g., returned unsigned, intercepted, or from unauthorised party — treat with scepticism |
| Non-response | No reply received — perform alternative procedures |
| Exception (disagreement) | Confirming party disputes the amount or fact — investigate the difference |