A vendor bank change affects where the next payment goes. Review who requested it, how it was independently verified, when it became effective and which payments used it. Matching today's master record is only part of that review.
Separate the request from its verification
A familiar supplier name and a plausible invoice do not establish that new payment instructions are authentic. Preserve the request and its source, then obtain verification through an independently established contact route. Do not let the change request supply both the new bank details and the only contact used to confirm them.
The FBI recommends independently obtaining a company's telephone number, verifying changes to payment instructions and treating pressure to act quickly with caution. These steps address business email compromise, where a message can appear to come from a trusted source. See the FBI's business email compromise guidance.
Document the verifier's identity, the contact source, the date and the conclusion. A field labeled “callback completed” should point to an actual verification record. The team also needs to know whether the person confirming the change was authorized to speak for the supplier.
Build a timeline around the change
Retain the previous account, the proposed replacement, the change request and the master-data update. Protect full account details in the approved system; use masked identifiers in general exception reports. Review the payment proposal, release and settlement records against the version in force at the relevant time.
| Event | Evidence to retain | Question for the reviewer |
|---|---|---|
| Change requested | Original request, requester and supplier identity. | Where did the instruction originate? |
| Change verified | Verifier, independently obtained contact route and confirmation record. | Was the verification independent and sufficiently supported? |
| Master record updated | Before-and-after values, actor and effective date. | Did the update match the verified instruction? |
| Payment prepared and released | Destination, preparer, releaser and approval history. | Which version of the account did the payment use? |
| Payment settled or returned | Bank status and relevant follow-up. | What happened to the funds, beyond the instruction to pay? |
Where the sequence occurs within one day, retain timestamps from the operational systems. Date-only extracts cannot establish whether a morning release preceded an afternoon verification. Do not claim a more precise sequence than the evidence supports.
Follow a fictional change through payment release
In this fictional example, Beacon Packaging requests a bank change on September 14. An accounts-payable clerk updates the supplier record. A $32,600 payment is released on September 16. A separate employee completes the documented supplier callback on September 17.
The new account may ultimately be confirmed as legitimate, but the timeline still shows that verification followed release. The investigation should identify how the release occurred, which account received the payment and whether the payment settled. A successful callback the next day does not establish that the earlier preventive control operated.
Suppose instead the callback occurred before release but the record shows only a number copied from the change email. The missing evidence concerns the independence of the contact route. Calling that number twice would not resolve the same weakness. Obtain verification through the established process and retain both the original and subsequent evidence.
Review incompatible roles and pending payments
Identify who can request, maintain, verify and release changes. Look at actual actors rather than job titles alone. A second approval adds little when both user accounts belong to the requester or when the review contains no evidence of what was checked.
Inspect pending payment batches when a supplier record changes. Establish whether a batch retained the old destination or will obtain the latest account at release. That behavior depends on the payment system. The review should record what the specific proposal contains, not assume that a master-data correction automatically updates every queued payment.
If evidence suggests a payment was misdirected, use the organization's incident process promptly. The FBI advises contacting the financial institution immediately in a suspected business email compromise. Preserve the original records and coordinate the response; a later data correction is not proof that funds were recovered.
Understand which conditions OpenAuditor evaluates
Within financial audit, a vendor-bank-change decision can be checked for a different verifier and a supported verification method. The current procedure rejects email-only verification and uses supplied payment records to look for payments between the change and its verification. It checks the recorded facts; it does not conduct the callback or authenticate its evidence.
A separate payment-release check looks for unverified changes in a configurable window, currently 14 days by default. That window is a rule setting, not a required waiting period or assurance that older changes are valid. The release check and the change-decision check cover different conditions and should not substitute for each other.
The payment procedure also compares the destination with the supplied account history, using a previous account when a later change requires it. Its date-level comparisons cannot resolve the order of events within a single day. Preserve the detailed operational timeline for that work.
Read the assertion and its evidence pointers before deciding how to resolve a finding. Record the conclusion and any corrective action alongside the original change. Our paired bank-change experiment shows why a callback by a second employee can still repeat the original unverified source.