PRACTICAL ASSURANCE GUIDES
Managing client evidence requests
A good evidence request tells the right person what to provide, why it is needed, which period it covers and when it is due. A shared request register makes the remaining work visible to both the engagement team and the client.
Build requests from the planned work
Start with the agreed scope, control or work-program step. Ask what information is needed to perform the planned procedure and whether it already exists in the engagement files. This reduces duplicate requests and helps the client understand the purpose of the work.
Separate requests that have different owners or acceptance criteria. A population export, an approval policy and supporting records for selected items may belong to the same test, but they need different instructions. Avoid a single request called “procurement documents” that remains open because nobody knows what would complete it.
Define what a usable response looks like
Include a stable request reference, named client owner, purpose, required period, expected format, due date and secure delivery route. Specify the fields or supporting detail needed. Explain whether the request covers a full population or selected items, and identify any exclusions that were agreed.
Do not request sensitive fields simply because they are available. Agree the minimum information needed for the procedure and the appropriate access arrangements. If the client cannot provide the proposed format, discuss an alternative before the deadline rather than accepting an unusable file.
A worked example: a purchase-order population
A fictional internal audit covers purchasing from 1 July to 30 September. The team needs a population before selecting items for testing.
| Owner and due date | Procurement operations lead; 12 October. |
|---|---|
| Purpose | Establish the purchase-order population for the scoped period before selecting items. |
| Requested information | Export of orders created in the period, including reference, creation date, value, currency, status and supplier reference. Include cancelled orders with their status visible. |
| Coverage information | System/report name, extraction date, filters used and record count. Explain known exclusions. |
| Delivery and acceptance | Upload the export through the agreed secure route. The audit team checks period coverage, required fields and supporting reconciliation before accepting it as usable. |
Receipt is not acceptance. If the export contains only open orders, explain why it does not yet meet the request and agree the next action. Whether the population is sufficient for testing remains an audit judgement.
Use statuses that describe the next action
Keep “requested”, “received”, “in review”, “clarification needed” and “accepted” distinct. A request marked received tells the team that a file arrived; it should not imply that the evidence is complete. Record the reason for a clarification and identify who needs to respond next.
When the scope changes, retain the original request and document the amendment. If a request is withdrawn, explain why instead of leaving it overdue. Track replacement files and identify which version is being used in the work.
Chase the blocker, not every open request
Review upcoming deadlines and dependencies with the client. A population needed for sample selection may block fieldwork, while a clarification for a later reporting point may be less urgent. Prioritise follow-up around those dependencies and the agreed timetable.
A useful reminder contains the request reference, what remains outstanding, the impact on the work and the agreed next date. Keep the conversation attached to the request so another team member can understand the position without searching separate email chains. Escalate through the agreed engagement contacts when necessary.
Close the loop with the working papers
Once accepted, link the response to the test or work-program step that uses it. Retain the original source and record any limitations identified during the work. If the evidence later proves insufficient, reopen the relevant follow-up rather than treating an accepted request as a permanent assurance conclusion.
At the end of fieldwork, review unresolved requests and explain their effect on the engagement. Some may require additional procedures; others may need a documented limitation or further discussion. Apply your firm's methodology and agreed scope when deciding what the remaining gaps mean.
Give every request a clear next step.
Explore how AccordWise connects evidence requests, client contributions and fieldwork in one engagement workflow.
Explore the evidence workflow