How to Verify a Vendor Bank-Change Request in QuickBooks Online (2026)
A vendor you have paid for two years emails to say they switched banks and asks you to update the account before the next bill run. The email looks normal. The invoice number is real. You have done this dozens of times. This post is the practical part: what to actually do inside QuickBooks Online when that request lands, in what order, and how to decide whether to release or hold. It is written for the bookkeeper or CPA doing the work, not for a compliance committee. It is informational, not legal, accounting, or Nacha advice.
The single most important habit, stated up front: do not edit the vendor record in QuickBooks until the change is verified through a channel the requester does not control. Everything below follows from that one rule.
Why the vendor record is the wrong first move
The instinct when a request comes in is to open the vendor, paste in the new account and routing numbers, and move on so the bill run is not held up. That instinct is exactly what vendor-impersonation fraud is built around.
QuickBooks Online stores vendor banking details in two places depending on how you pay:
- The vendor profile itself, under Expenses > Vendors > [vendor] > Edit, which holds the address, billing rate, and (for some setups) ACH or direct-deposit fields.
- The QuickBooks Bill Pay / direct-deposit bank details attached to the vendor, which is what an actual ACH credit pulls from when you schedule a payment.
The moment you save new numbers into either place, two things happen. The old, known-good details are overwritten, often with no visible history of what they were. And the next payment you schedule will route to whatever you just typed. If the request was fraudulent, the money leaves on settlement and is very hard to claw back. Credit-push fraud is hard to reverse precisely because you authorized the payment yourself.
So the vendor record edit is not step one. It is the last step, and it only happens after verification clears.
The step-by-step in QuickBooks Online
Here is the sequence to run every time, including for vendors you trust completely. Trust in the relationship is the thing the attack exploits.
1. Park the request, do not action it
Before touching anything, treat the request as unverified. If a bill for that vendor is already scheduled, open Expenses > Bills (or Bill Pay), find the scheduled or pending payment, and put it on hold or unschedule it so nothing goes out on the old timeline while you verify. A held payment is recoverable. A sent one usually is not.
Do not reply to the email to confirm. If the requester's mailbox is compromised or the address is spoofed, you are asking the fraudster to confirm their own request.
2. Capture what was requested, without saving it to the vendor
Write down, somewhere outside the live vendor record, the specifics: which vendor, the last four digits of the new account, the routing number, the date the request arrived, and the channel it came on (email, portal message, phone). Keep the new numbers out of QuickBooks for now. You want a record of what was asked before anything changes, and you do not want the live vendor profile to carry unverified details.
A note in the QuickBooks vendor memo or attachments area is fine as a working scratchpad, but understand its limit: the memo field is free text in a live record. Anyone with access can edit or overwrite it later, and it carries no tamper-evident history. It is a reminder, not an audit trail. More on that below.
3. Find your previously verified contact in QBO
Open the vendor in QuickBooks and look at the contact details you had before this request arrived: the email and phone already on the vendor profile, and any contact in your prior correspondence or onboarding documents. This is the contact you will reach out to.
Do not use the phone number in the new email's signature. Do not call a number included in the change request. Those travel with the request and can be controlled by whoever sent it.
4. Verify out-of-band, to that prior contact
Reach the previously verified contact through a channel independent of the one the request arrived on. If the change came by email, confirm by phone to the number already on file. Confirm two things: that the bank change is genuinely theirs, and the new account details exactly as you received them, digit for digit. People sometimes confirm "yes we changed banks" without checking the numbers, and a transposed or substituted account number is the whole game.
If you cannot reach the prior contact, the request stays unverified and the payment stays held. Silence is not confirmation.
5. Escalate anything high-value or unusual
For large payments, a brand-new contact name, urgency ("the old account is closed, please pay today"), or a request to pay ahead of the normal cycle, add a second layer: a call to a second known number, and a second person at your firm approving the release. Dual approval means an attacker has to defeat two independent people, not one.
6. Only now, edit the vendor record and release
Once the change is confirmed out-of-band, open Expenses > Vendors > [vendor] > Edit, update the banking fields (and the Bill Pay / direct-deposit details if you use them), save, and then re-schedule or release the held payment. If verification did not clear, leave the vendor record as it was, keep the payment held, and escalate internally. The decision to release, hold, or escalate is yours; QuickBooks does not make it for you, and neither does any tool.
What to record, and why a memo line is not enough
Running the workflow is half the job. Being able to show, later, that you ran it is the other half.
A memo field entry like "called Maria 6/14, confirmed new bank, OK to pay" is far better than nothing. But it is editable free text with no record of who wrote it or when, and it does not link to the underlying evidence in a way that proves it was not altered after the fact. If a payment is disputed eighteen months from now, that line will not, on its own, demonstrate what you checked and when.
A defensible record captures the facts as discrete, time-stamped items at the moment they happen:
- The vendor and the specific change (for example, the new account's last four digits).
- The channel the request arrived on, and the separate channel used to verify it.
- Timestamps for each step.
- The attestation: who confirmed the change, and in what words.
- A cryptographic hash (SHA-256) of the record, so later alteration is detectable.
The test is simple. Could you produce, on request, a record of exactly what you verified, when, and through which channel, in a form that could not have been quietly edited afterward? A memo field fails that test. A structured, timestamped, hashed record passes it.
Why this matters more in 2026
This used to be good practice that few firms had to document. Under the 2024 Nacha Risk Management rules, the expectation to have a documented fraud control reaches every non-consumer originator.
Nacha's 2024 rules add fraud-monitoring obligations aimed at credit-push fraud, including payments "authorized under false pretenses," which is exactly what vendor-impersonation business email compromise is. The rollout has two phases. Phase 1 (March 20, 2026) applied to ODFIs and larger originators with 2023 ACH volume of 6 million entries or more (Nacha, Phase 1). Phase 2 (effective Monday, June 22, 2026, since June 19 is the Juneteenth federal holiday) removes that volume threshold entirely: all non-consumer Originators, Third-Party Service Providers, and Third-Party Senders must have risk-based fraud-monitoring processes, regardless of size (Nacha, Phase 2; new rules now in effect).
June 22 is the date the obligation turns on for everyone and stays on. It is not a deadline that expires. The obligation sits on the originator side, the business sending the ACH credit and its bank, so if your firm originates payments for clients in QBO Bill Pay, it reaches you. The rules are technology-neutral: Nacha does not mandate a specific method and does not certify any tool (credit-push fraud resource center).
The scale is the reason this scenario is the priority. The FBI's IC3 2024 report put reported BEC losses at $2.77 billion across 21,442 complaints, roughly $129,000 per reported incident. The vendor bank-change request is one of the most common ways those losses enter accounts payable.
Where BankChangeGuard fits
You can run every step above by hand, and if you do it consistently you are ahead of most firms. The cost is consistency: doing it the same way for every change across every client, and keeping defensible evidence each time, is tedious, and tedium is where controls quietly lapse.
BankChangeGuard makes the routine version of this control easy to run inside QuickBooks Online. It connects to QBO with read-only access on the vendor and bill scopes. It does not touch bank credentials, does not originate ACH, and does not move money. When a request comes in, you log it against the synced QBO vendor and enter the new account's last four. BankChangeGuard emails a one-time code to the previously verified contact on file, not the channel that asked for the change, and the recipient types the code back to attest. You then export a structured audit PDF: timestamps, channels, attestation text, and a SHA-256 evidence hash, the kind of documented control and retained evidence an auditor or insurer would expect to see.
To be clear about scope: the email callback is a workflow control, not independent verification that the new bank account belongs to the vendor. It confirms that someone at the contact you already trusted attests to the change; it does not prove account ownership. For high-value or suspicious changes you should still add a known-number phone call and dual approval. BankChangeGuard supports your Nacha Phase 2 fraud-monitoring efforts; it does not make you "Nacha-compliant," does not certify anything, does not verify bank-account ownership, and does not replace your bank's own Nacha obligations. The decision to release, hold, or escalate, and the ACH origination itself, stay with you and your bank. It is $99 per month, flat: single seat, one QBO company. If you already run the callback by hand, this is the same control, made routine and documented.
FAQ
Should I update the vendor's bank details in QuickBooks as soon as they send the new account? No. Update the vendor record only after you have confirmed the change out-of-band, through a channel the requester does not control. Saving the new numbers first overwrites the known-good details and routes the next payment to an unverified account.
Does QuickBooks Online verify a vendor bank-change for me? No. QuickBooks stores the banking details you enter and uses them to schedule payments. It does not confirm that a change request is genuine or that the new account belongs to the vendor. That verification is a process you run.
What is the safest way to confirm a vendor bank change? Call the contact you already had on file before the request arrived, using a phone number from your own records, never the number in the new email. Confirm both that the change is real and the new account details digit for digit. For large or unusual changes, add a second known-number call and a second approver.
Is a note in the QBO memo field enough to show I verified the change? It is better than nothing, but it is editable free text with no tamper-evident history, so it is not an audit trail on its own. A defensible record captures the request, the verification channel, timestamps, the attestation, and a hash that makes later alteration detectable.
Does using a verification tool make me Nacha-compliant? No. Nacha is technology-neutral and does not certify, validate, or endorse tools, and no software makes you compliant on its own. A tool can help you operate and document a control and retain the evidence. Whether your overall process meets your obligations is a question for your bank and your CPA.
This article is informational and does not constitute legal, accounting, insurance, or Nacha compliance advice. Confirm current requirements against the Nacha rulebook and consult your bank, CPA, and counsel for your specific situation.