Use these steps when a supplier asks to change where you send money. They are practice suggestions informed by general control ideas in the sources. Your local policy decides what is enough. A person makes the checks and the decisions. An AI tool may help draft notes, but it does not authenticate anyone and does not approve payments.
Before you start
Gather the request, the approved invoice record, access to the supplier master and your payment policy. Confirm who may open those records. If you lack access, ask the record owner for a read-only view or a named colleague who has it. Do not borrow another person's login.
Steps
- Pause payment. Mark the invoice held and note why. Electronic transfers are hard to recall (CC8, 6.4, England and Wales charities).
- Do not reply on the thread, click links or open unexpected attachments. Do not use contact details from the request.
- Save the request as received. Note date, channel and the sender address as shown.
- Find the preexisting contact route: a supplier master entry, contract or earlier payment record stored before the request. Check who stored it, when, from what source, and current trust under local policy. Unknown or unresolved trust: stop and escalate. If none exists, see Exceptions.
- Open the verification record. Fill Parts A and B.
- Make the callback using that route. A person, not an AI tool, reads the number from your own record. Ask the contact to say whether they sent the request and what is changing. Do not read the new destination aloud for a yes. Never ask for passwords or one-time codes.
- Write the note at once: time, role reached, route, what was confirmed, what was not.
- If you made no callback, record NOT ATTEMPTED and the reason. If you tried and nobody answered, record NOT REACHED. If someone answered but the answer settled nothing, record INCONCLUSIVE. These are different gaps.
- Record what stays unknown. Account ownership is not shown by a callback alone, because the callback confirms only what that person said about the request.
- Check authorization separately for each decision. Ask who may approve a supplier-master change and who may approve a payment release. One role may hold both in local policy, but record each decision on its own line.
- Send the record to the authorized approver named in local policy. Ask for two separate decisions: change the supplier master, and release the payment.
- Record the decisions and update the statuses. Staff act only after that.
Exceptions
- No answer: retry the same preexisting route. Do not switch to the new number. Keep the hold. Record NOT REACHED for each try.
- No preexisting route: do not create one from the request. Ask the approver what local policy allows. Record the callback as NOT ATTEMPTED.
- Contact denies sending the request: keep the hold, report it through your usual reporting route, and tell the approver. The NCSC guidance favors quick, blame-free reporting.
- If the due date arrives during a hold, an internal hold does not by itself change contract terms or remove effects of delay. As practice, the responsible owner assesses consequences and options under applicable terms and local policy without weakening checks.
- Approver unavailable: use the delegation rules in local policy. The decisions guidance says a delegation should state what a person can and cannot decide.
- No records access: stop at step 4 and ask the record owner or approver. Do not guess the contact route.
Output
A completed record with statuses, evidence, gaps and decisions. Name the exact finding the callback produced, for example 'the contact said they sent a request to change the destination'. Do not write a general 'verified' label. Identity and account ownership stay uncertain unless local policy and evidence show otherwise.
Fictional example
Supplier S-14, invoice INV-28 for USD480, due November 6. The November 1 email offered a new phone number. VC-07 was stored earlier. Today: payment held, master unchanged, callback NOT ATTEMPTED, destination authenticity unknown.