A message arrives from a familiar supplier: their bank has changed, and this week's payment must go to the new account today. It might be genuine. It might also come from someone who has gained access to the supplier's email or is imitating it. The record you update decides where future payments go, so the request deserves a process rather than a quick reply.
This guide covers one narrow job: handling a request to change a supplier's payment details, from receipt to closure. It does not cover approving invoices, technical email security or any reporting obligations. The supplier, people and references in the example are fictional, and the case is deliberately shown on hold.
Treat the request as a case, not an instruction
Give each request its own case reference and record its scope: which supplier, which details are changing, which records would be affected, the effective date requested, the channel it arrived through and who received it. Save the original message exactly as received. If the same supplier sends a second request, open it as a new entry linked to the first rather than overwriting it.
Hold the record change until independent supplier verification and internal authorisation are recorded. Keep payment to the new details on hold until the authorised change and independent check are complete; the payment itself still needs its usual approval. Do not reply in the same thread, call a number given in the message or follow a link in it to check, because each of those routes may be controlled by whoever sent it.
Keep bank details out of the shared case record. Note where the protected copy is held and record comparison results, such as whether the details stated by the supplier match the request, rather than the account numbers themselves.
Recognise the pressure signals
Some features of a request call for extra care: a change of bank details nobody expected, urgency or warnings about consequences if payment is late, a request to skip the usual process or keep it quiet, and a sender address or name that does not quite match previous correspondence. Record any of these on the case.
Their absence proves nothing. A well-prepared false request can be polite, unhurried and sent from a genuine account that has been compromised. The verification step applies to every change request, however ordinary it looks.
Verify through a route you already trusted
Contact the supplier using details established independently of the request and before it arrived: the contact recorded when the supplier was set up, a number on a signed agreement or a contact previously confirmed in person. Record where that contact detail came from, who made the call, who answered and when.
Ask the supplier to state the change they intend to make rather than reading the new details to them and asking for a yes. Compare what they say with the request and record the result. If you cannot reach the trusted contact, the case stays on hold; an unanswered call is not a confirmation.
Check that the person reached is authorised to confirm the supplier’s payment details. A familiar caller ID, a forwarded message or someone saying they work for the supplier is not enough by itself. If the trusted route or authority cannot be established, retain the hold and escalate through the defined process.
Worked example: a request on hold
In this fictional case, SPC-07, an email appears to come from Harbour Greens, a produce supplier, on a Thursday afternoon. It says the supplier has moved banks and asks for the invoice due that week to be paid to a new account the same day. The accounts lead opens a case, saves the message and places the change on hold.
The trusted contact is the phone number recorded when Harbour Greens was set up. The call is made, but that contact is away until Monday, so the reviewer records a follow-up call to that independently verified number on Monday. An incoming callback or familiar caller ID alone will not complete verification. Verification is pending and every later stage is waiting. Payment of the invoice remains a separate decision for the authorised payment owner under the usual process; nothing in this case authorises a payment to the new account.
| Stage (fictional case SPC-07) | Status | Evidence or note |
|---|---|---|
| 1. Request recorded | Complete | Email received Thursday 14:10; original saved under SPC-07 |
| 2. Change held | Complete | Record change held pending verification and authorisation; payment to new details held pending independent check |
| 3. Trusted route identified | Complete | Phone number from supplier setup file, recorded before this request |
| 4. Supplier confirmation | Pending | Call Thursday 15:00; contact away; follow-up outbound call to verified number planned |
| 5. Internal authorisation | Not started | Requires stage 4 confirmed |
| 6. Change applied | Not started | Requires stage 5 |
| 7. Independent post-change check | Not started | Requires stage 6 |
| 8. Closure | Open | Follow-up owner named; next check Monday 11:00 |
Four steps that are not the same
Supplier confirmation shows that the supplier, reached through a trusted route, says the request is theirs. It does not authorise anything. Internal authorisation is the decision, by someone with the authority to make it, that the record may be changed. Application is the change itself, made by an authorised person, with a reference to the protected record. The independent post-change check is a comparison, by someone other than the person who applied the change, between the updated record and the verified evidence.
Keep each step as its own entry with a responsible role, date and protected evidence reference. A change proceeding to application needs each prerequisite evidenced. A rejected or withdrawn case can close without applying a change, with unused stages marked not applicable and the reason recorded. Where staffing allows, the person who authorises, the person who applies and the person who checks should be different people.
Keep rejected and superseded requests visible
Record the outcome explicitly: confirmed, authorised, applied and independently checked; rejected because the supplier denied sending it; withdrawn; or superseded by a linked request. An unresolved case stays open with an owner and next review date. A rejected request is useful evidence. Tell the supplier through the trusted route that a request in their name was received, so they can check their own systems.
Retain rejected and replaced cases with their evidence and links under the organisation’s record-retention rules. Their history can help the team recognise related requests.
If a payment has already gone
If money has already been sent to unverified details, or a record was changed without verification, escalate at once to the person responsible for payments or incidents through your established process, so that they can contact the bank promptly. Record the time the issue was found and every action taken, and preserve the messages involved. Speed matters, but there is no guarantee that funds can be recovered.
Have the responsible owner review affected records and payments and control further use of the disputed details. Any replacement or restoration must use freshly verified, currently valid details and the authorised process, followed by an independent check. Do not assume the old account remains usable.
What the record does not decide
The case record organises evidence and decisions. It produces no score, readiness percentage or risk rating, it does not determine whether a request is fraudulent and it does not approve a payment. Those judgements stay with the people who hold the relevant authority.
Where the principle comes from
Australian Government guidance on business email compromise recommends a clear and consistent business process for verifying requests that involve payments or account changes, contacting the other party through separately verified details, treating unexpected changes of bank details and urgent payment demands as warning signs, and contacting your bank immediately if money has been sent. Only those general principles are used here. Its technical controls and national reporting arrangements are not applied.
Put it into practice
Your action checklist
Your progress saves in this browser. No sign-up needed.
0 of 9 complete
From reading to doing
Supplier payment change verification case
The Supplier Payment Changes worksheet holds one request case per sheet as a manual evidence form. It records the case reference, supplier, scope of the requested change, affected records, requested effective date, channel, receipt details and links to earlier or later requests. An ordered checklist covers eight stages: request recorded, change held, trusted route identified with its source, supplier confirmation and outcome, internal authorisation, application, independent post-change comparison, and closure with follow-up owner and date. Each stage takes a manual state, responsible role, date and evidence reference. The reviewer checks prerequisites and explains any not-applicable stage; the form does not automatically validate evidence or approve progression. The outcome record distinguishes checked completion, rejection, withdrawal and supersession, with unresolved work kept open. A separate section records escalation if a payment has already been made or a record was changed without verification. Use protected record references only, never credentials or full bank account details. The sheet produces no score or percentage, does not determine fraud and does not approve payments or record updates.
Open the Supplier Payment Changes tab in the launch workbook. Keep a copy for your own business.
Download the free workbook See what’s inside the toolkit →Sources & further reading
- Protecting against business email compromise (Australian Government, cyber.gov.au) ↗
Retrieved 8 November 2026. Used only for general principles: a clear and consistent process to verify requests involving payments and account changes, contact through separately verified details, unexpected bank-detail changes and urgent payment requests as warning signs, and prompt contact with the bank if money has been sent. Technical email controls, Australian reporting arrangements and statements about other organisations are not applied, and no certification is implied. The case and names here are original fiction.
Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.