Vendor bank-change log: fields, controls, and review

Assign one change ID and record the vendor ID, legal or trading name, paying entity, request received date and channel, requester name and email address, stated reason, requested effective date, and link to the original message or form. Capture the old and requested new values for bank name, routing code, account number, account holder, payment method, and remittance contact. Display only masked bank values in a broadly visible log; keep the full source document in restricted storage.

Add separate fields for verification status, known contact used, source of that contact, callback date and time, verifier, person reached, result, approver and approval time, master-record updater, system change timestamp, actual effective date, and related payment hold. Preserve old values rather than overwriting them.

The verifier should use contact data that the business already trusted before the change request - for example, a number in the previously verified vendor master or executed contract. A phone number, link, or contact person supplied only in the change request is not independent. The evidence note should identify the trusted source, the masked number or channel used, the vendor representative reached, what details were confirmed, and the outcome. A voicemail, bounced message, or unanswered call is an attempt, not a successful verification.

For example, if an emailed request changes both the account and the remittance contact, calling the new number in that email proves little. Record the attempt as blocked, use the prior contact path, and leave payments on hold until the result meets policy.

A bookkeeper may register the request, compare old and new values, attach evidence, and prepare an update after approval. The independent verifier confirms vendor intent. An authorized finance owner approves or rejects the change. The person releasing payment should check that the approved change ID is effective before using the new destination. Where staffing permits, those roles should not be concentrated in one person; at minimum, no requester or updater should approve their own change.

Urgency does not change the boundary. Same-day payment requests, instructions to keep the change confidential, conflicting vendor names, and requests from a new domain should remain on hold and be escalated through a known internal route.

Review open changes before each payment run and examine completed changes as part of the business's control schedule. Check that each completed row has old and new values, successful verification evidence, distinct approval, an effective date, and a matching system audit event. Also look for a payment created before approval, repeated failed callbacks, duplicate requests, inactive vendors reactivated with new banking, or changes followed by a reversal.

The reviewer decides whether evidence meets policy and whether a payment may proceed. The bookkeeper reports missing fields and factual conflicts but does not infer vendor intent, waive the control, or release funds. Retain the log and linked evidence under the company's access and record-retention policy; NIST's Audit and Accountability controls are a useful reference when defining what an audit record should capture.