If your firm pays vendors for multiple clients, vendor verification is the single control that decides whether a “we changed banks” email becomes a routine update or a wire to a fraudster’s account. The routine that actually works for a multi-client bookkeeping firm is small and boring: an independent-contact callback before any bank-detail change, a second person who approves it, and a per-client log you can show an auditor or a cyber insurer six months later.
That sounds like every checklist you’ve already read. What makes it harder for firms running client AP — versus an in-house controller working at one company — is volume, attack surface, and the documentation burden of proving the verification happened on the right day, for the right vendor, in the right client’s books. This page is the playbook for that specific reality.
Why bookkeeping firms are the easier target
A single client paying its own vendors has one AP inbox, one approver, one set of vendor relationships. A bookkeeping firm running AP for ten clients has ten of each — and ten times the “our bank account changed, please update” emails to triage. Three patterns make the firm itself the higher-value target.
You’re a trusted intermediary. The fraudster doesn’t have to compromise a single Fortune 500 controller — they compromise one of your clients’ vendor mailboxes, send a believable change request to your firm’s AP inbox, and your firm dutifully updates the record. The money leaves the client’s bank, but the verification record (or its absence) is yours.
The volume normalizes the request. When a vendor change email is one of fifty things in your inbox that morning, the temptation to fold it into “I’ll process this with the next batch” is real. Attackers know that and time their requests for end of month, end of quarter, and the day before a payroll funding run.
The platforms don’t close the loop. BILL, QuickBooks Bill Pay, Melio, and Ramp will all run a penny test on the new account, which confirms the account exists and can receive ACH — but it does not confirm the change request is genuine. Their own help articles tell you to verbally confirm any new bank details with the vendor first. The Association for Financial Professionals’ annual fraud survey has reported that around three quarters of organizations were targets of attempted or actual payments fraud in recent years (AFP Payments Fraud Survey) — and the FBI Internet Crime Complaint Center documented business email compromise losses of $2.77 billion in 2024 (2024 Internet Crime Report), with vendor-payment swaps a large share of the total.
The control set is well known. The discipline of running it the same way across every client, and proving it ran, is what most firms haven’t built.
The four-step routine, adapted for multi-client work
The classic AP control is “independent-contact callback + dual approval + documented record.” Here is how each step has to bend to work inside a firm that touches more than one client per day.
1. The independent-contact rule, per client. When a change request arrives, the vendor phone number you call has to come from your own records — a prior signed engagement letter, a prior invoice, the W-9 on file, or a number on the vendor’s main website. Not the number in the email. Not the number in the email’s signature block. Because you’re operating across clients, the rule has to be: the source of truth is this client’s vendor file, not your firm’s contact list and not last week’s call to a different client’s same-named vendor. Same vendor name does not mean same account.
2. The callback script, kept short on purpose. The call has to confirm three things and only three things: that the person on the other end is the vendor (use the vendor’s known contact name, not the one in the email), that they did request the change, and that the new account details match what they actually sent. The full word-for-word version is in our how to verify a vendor bank account change guide. The shorter the call, the more reliably it gets done.
3. Dual approval, even if your firm is small. The person who entered the new bank details should not be the person who marks the change approved. In a two-person firm that means the owner approves what the bookkeeper enters, or vice versa. In a solo firm it usually means an explicit timestamped self-check the next morning — imperfect, but still better than entry-and-payment-by-the-same-person in a single session. Auditors and most cyber insurers will ask after the fact whether this separation exists; “we don’t, we’re small” is the answer that gets a claim denied or a finding written up. For exactly what an auditor will ask you to show, see what auditors ask about vendor verification.
4. The log entry, scoped to the client. Per change, you want a record that names the client, the vendor, who called and who approved, the number that was dialed, where that number came from (invoice date, engagement letter, site URL), what was confirmed on the call, the last four digits of the new account, and the timestamp of each step. Crucially, the log entry has to exist before the change goes into BILL/QuickBooks/Melio/Ramp — not retroactively. That ordering is what holds up under a claims review.
Where firms get burned on cyber-insurance claims
Most small bookkeeping firms either carry their own cyber/professional-liability policy or their clients carry one that names the firm as a service provider. Both routes share the same condition: social-engineering and funds-transfer fraud coverage typically requires an out-of-band verification of any payment-detail change, documented in advance, before the payment goes out. When the callback wasn’t made, or was made but only mentioned in a Slack message that nobody can locate, the insurer denies the claim or limits it severely. We cover the underwriting and claims-review side in detail in does your cyber insurance require a callback.
The pattern of denial is consistent: the firm did the right thing in spirit, did most of it in practice, and could not produce the record after the fact. The control without the record is half a control.
What “verified” actually has to mean in your file
When the verification is done well, the artifact set for any one change looks like this. The change request itself (the email or portal message that prompted the update). The vendor file entry from before the change, showing the old account on record. A timestamped log line naming the person who made the call, the number dialed, and the source of that number. A second timestamped line naming the approver. The corresponding change in BILL/QuickBooks/Melio/Ramp, time-stamped after the approval. And, ideally, a cryptographic or system-enforced indication that the log hasn’t been edited since.
For the change-request triage itself — the part where you decide a request is plausibly real before you even pick up the phone — work through a vendor emailed new bank details — is it fraud.
A note on the platforms you already use
Each major small-firm AP platform handles one slice of this. BILL runs a penny verification on the new account (does Bill.com verify vendor bank account changes). QuickBooks Bill Pay does the same (does QuickBooks Bill Pay verify vendor bank changes). None of them confirm the requester’s identity or the request’s authenticity, and that’s not a bug — that part is supposed to happen out-of-band, on your side, before the change is saved.
Treat the platform’s penny test as a sanity check on the routing, not as the verification.
What CallbackProof does, scoped to this use case
CallbackProof is a documentation and workflow tool built for exactly this routine across multiple clients. It enforces the independent-contact callback, separates entry from approval, and writes every action to a SHA-256 hash-chained, tamper-evident log — per client, per vendor, per change. It does not move money and it does not replace BILL or QuickBooks. It records that the verification happened, in the order it had to happen, and produces a clean export the day an auditor or insurer asks.
If you’re not ready for a tool, the manual version is real and works: our free vendor bank-change verification template is an ungated procedure with the callback script, the dual-approval step, and a one-page log sheet. Adopt it client by client.
Frequently asked questions
Do I need a separate verification log per client, or one for the whole firm?
Per client. The artifact that matters in a claim or audit is “show me, for this client, the verification record for this change.” A combined log makes that harder to produce and conflates clients in a way auditors flag.
Our firm is two people. Can we do dual approval at all?
Yes — owner approves what the bookkeeper enters, or the reverse. The cleaner the separation, the better, but a documented second pair of eyes by a different login on a different day is still a real control. Document the workflow as your firm’s standing procedure so it’s defensible.
Is a penny test (BILL or QuickBooks Bill Pay) enough?
No. The penny test confirms the account exists; it does not confirm the change request is genuine. Both platforms’ own guidance is to verbally confirm new bank details with the vendor before saving the change.
What’s the single biggest mistake firms make on this?
Logging the verification after the change went through. The order of operations — verify, approve, log, then change — is what holds up under a claims review or an auditor’s vendor-master sample.
Where do I start tomorrow?
Adopt the free template as a written firm procedure, run it manually for two weeks across every client, then decide whether you want a tool that enforces the routine and keeps the log for you.