Supplier bank-details change control: verify the payee before a transfer
A practical restaurant control for checking changed supplier payment details, preserving evidence, and holding a transfer when verification is incomplete.
Bank-detail changes sit at the junction of supplier master data, accounts payable, and payment execution. A normal invoice match can still point to the wrong destination if the payee record was changed without a trustworthy confirmation. Start with the exact request as received: preserve sender information, message content, attachments, timestamp, claimed effective date, and any callback details. Then compare it with the supplier contract and prior records. Avoid forwarding sensitive account numbers more widely than the review requires. The purpose is to create a verifiable chain from request to decision, not to decide that a message is genuine because its wording or branding looks familiar.
Build an independent verification path
Independence matters because an attacker can control the channel that carries the change request. Use a telephone number already stored from an earlier trusted interaction, a verified contract contact, or another route approved by the restaurant. Do not use a new number, reply address, QR code, or link supplied only by the change message unless your separate policy confirms it through another source. Ask the supplier to confirm the requested change without disclosing more information than needed. Record who confirmed it, when, through which channel, what was confirmed, and whether the person has authority under your supplier process. If the supplier cannot be reached, leave the old payee unchanged and hold the affected payment rather than filling the gap with an assumption.
- Preserve the original request and its metadata before copying any account identifier into a master record.
- Compare legal supplier name, contract reference, invoice identity, currency, payment terms, and account-change reason with trusted records.
- Use a callback or second channel that was not introduced by the change request, and note the source of that channel.
- Mask or restrict bank data in general notes; give reviewers enough detail to compare records without creating a new disclosure risk.
- Mark the old account as superseded only after approval, and retain the previous value in an auditable history rather than deleting it.
Make the hold and approval states operational
A policy is weak when a reviewer can verify a change but the payment queue releases it before the record is updated. Use explicit states such as received, evidence requested, verification in progress, verified, rejected, or payment held. Tie the state to permissions: the person who enters a proposed account should not silently approve the change and release the first payment when a workable separation exists. If a small team must combine duties, define a compensating review by an owner or finance lead and document it. An urgent request should create a visible exception with a reason and review deadline, not an invisible shortcut. Reconcile the final payment destination to the approved case immediately before release.
Clearly labeled illustrative example: one changed payee case
A restaurant enters this scenario to test its workflow. Every name, account ending, date, amount, role, and status is illustrative and operator-entered; none is a supplier fact, bank instruction, fraud statistic, payment demand, loss, saving, or legal conclusion. Replace it with the actual contract, trusted contact evidence, approved permissions, and current bank or adviser guidance.
| Incoming request | Illustrative operator-entered: a message proposes changing the supplier account ending from 4821 to 9074 before the next payment | Illustrative identifiers only; preserve the source without treating it as authentic |
|---|---|---|
| Independent check | Illustrative operator-entered: the reviewer calls a previously used supplier number and records the name, time, channel, and confirmation result | Illustrative control step; the route must come from trusted records |
| Commercial comparison | Illustrative operator-entered: contract reference, recent invoice identity, currency, and payment terms are compared with the change case | Illustrative evidence list; do not invent a match |
| Approval | Illustrative operator-entered: finance lead approves the data update after verification; the data-entry user cannot release the first payment | Illustrative segregation; use the restaurant’s actual policy |
| Payment gate | Illustrative operator-entered: payment remains held until the approved destination is rechecked in the payment batch | Illustrative status; hold rules and timing are local decisions |
The illustrative operator-entered case keeps the request, independent confirmation, comparison, approval, and payment hold as separate evidence. The account endings, roles, timing, and outcome are examples only; verify the real change before editing or paying.
A repeatable supplier bank-detail change process
- 1Freeze the request. Save the message, attachment, sender details, claimed effective date, and related invoice, then mark the supplier record or payment as under review.
- 2Compare trusted records. Check supplier legal identity, contract, prior account, recent invoices, payment terms, and the stated reason against records already held by the restaurant.
- 3Verify independently. Use a previously used or independently sourced contact route. Record the confirming person, authority, time, channel, questions, and result.
- 4Review access and approval. Have an authorised reviewer assess the evidence and confirm who may enter, approve, and release a payment; record any compensating control.
- 5Update with history. If approved, update the master data with effective date and case reference while preserving the prior value and the verification trail.
- 6Recheck before release. Compare the payment batch to the approved destination and case. Hold, escalate, or contact the bank through an official route if anything differs.
FAQ
- Is an email from a known supplier contact enough?
- No. A familiar address or writing style does not prove that the request is genuine or that the destination is correct. Use an independent route already trusted by the restaurant, preserve the evidence, and follow your approval policy before changing data or paying.
- Which phone number should the reviewer call?
- Use a number already used and retained in trusted supplier records, a contract, or another independently verified source. Do not rely solely on a number or link introduced in the change message. If you cannot verify the request, hold it and assign an owner.
- Should the old bank details be deleted after approval?
- Usually keep the prior value in a restricted audit history with effective date, case reference, reviewer, and reason. Retention and access must follow your local policy and data-protection obligations. Do not copy sensitive details into broad notes.
- Can an urgent payment bypass the change control?
- Do not make an exception invisible. Record why normal verification was unavailable, who authorised the temporary route, what evidence exists, how long the exception lasts, and when a retrospective review must occur. A payment should remain held when the destination is not trusted.
- Does independent verification prove there was no fraud?
- No. It reduces one exposure by checking the request through a separate route; it is not a guarantee, investigation, bank decision, or legal finding. Escalate suspicious requests to the bank and the appropriate current authority or adviser.
Keep reading
- Supplier contract renewal calendar for restaurants: review before renewal
A practical calendar for notice dates, price-review clauses, service evidence, risk review, and exit preparation before a restaurant supplier contract renews.
- Supplier switching checklist: how to change suppliers without breaking service
A switching checklist: parallel ordering, trial periods, operational checks, and a rollback plan if quality slips.
- Restaurant purchase approval matrix: define authority without losing evidence
A practical matrix for separating request, approval, ordering, receiving, and invoice review while setting value and risk bands locally.
Browse by category
Want to review your purchasing?
Submit the details and we will confirm which invoices are useful.
Review 3 invoices free