A Vendor Bank-Change Verification SOP for QuickBooks Firms
The fastest way to stop vendor-payment fraud is not a tool, it is a written procedure your whole team follows the same way every time. This is a standard operating procedure for handling a vendor bank-account-change request in a QuickBooks Online firm: when it triggers, the exact steps, a callback script you can read word for word, and what to keep. Adapt it to your firm and have everyone use it. It is informational, not legal or accounting advice.
When this SOP triggers
Any time anyone asks to change how a vendor gets paid: a new bank account, a new routing number, "send it to this account instead," a new remittance email, or a switch to a different payee. By email, by phone, through a portal, or as a note on an invoice. The trigger is the request itself, no matter how it arrives or how legitimate it looks.
Step 1: Stop, and tag it unverified
Do not edit the vendor record yet. Treat every change request as unverified until this SOP is complete, even from a vendor you have paid for years. That long relationship is exactly what the attacker is borrowing.
Step 2: Find your own prior contact
Pull the phone number you already had on file for this vendor, from a past invoice, a signed contract, or your records. Not the number or email in the change request. A compromised mailbox will happily supply its own "confirmation."
Step 3: Call and verify out-of-band
Call the known number, and use a script so it is consistent across your team:
"Hi, this is [name] at [firm]; we handle accounts payable for [client]. We got a request to change the bank account we pay you into, and I'm calling the number we already had on file to confirm it's genuine. Can you confirm two things: did you request a banking change, and can you read me the new account's last four digits so I can match them against what we received?"
Confirm both: that the change is real, and that the new details match what you were sent (read the last four back). If anything is off, or you cannot reach them on the known number, hold and escalate. Never confirm by replying inside the request's own email thread.
Step 4: Record what you checked, at the time
Before you touch QuickBooks, write down, in something more durable than a memo field: the original request and the channel it arrived on, the channel you verified through, the number you called, who you spoke to, the date and time, and what changed (the new account's last four is enough). This is the record you could actually produce if a payment is ever questioned.
Step 5: A second approval for material changes
Set a dollar threshold and write it down. For anything above it, a second person approves before the change is saved and before the next payment releases. The person who can edit a vendor's bank details should not be the only person who can send that vendor money.
Step 6: Only now update QuickBooks
Update the vendor record, save the verification record alongside it, and proceed. If you could not verify, the payment stays on hold, not "we'll sort it out later." A held payment is recoverable; a sent one usually is not.
Make it repeatable
An SOP only works if it is written down, easy to find, and followed the same way by everyone, including the founder on a busy day. Put it in your procedures doc, train new staff on it, and revisit it after any near-miss. The discipline is what protects you; the steps above cost nothing.
Where software fits
Steps 4 and 5, the record and the second look, are the ones that quietly slip on a busy day. That is the part I built BankChangeGuard to automate for QuickBooks Online firms: it logs the request, emails a one-time code to the contact you already had on file, captures the confirmation, and exports a tamper-evident PDF, so the record happens automatically instead of being a memo nobody can defend. It does not move money, approve payments, or make anyone "Nacha-compliant," and the decision to release a payment stays with you and your bank. The manual SOP above works on its own and is free.