Not in the way that protects you. When a vendor’s bank account is added or updated in BILL (Bill.com), the platform sends a small one-cent test deposit within one to two business days to confirm the account is real and can receive ACH. That’s account plumbing validation — it does not confirm the change request came from the real vendor. A fraudster’s account passes the test deposit just as easily as a legitimate one. BILL’s own help articles say so explicitly: they recommend verbally confirming any new bank account with the vendor before paying, because business email compromise is a rising threat.
That last line matters: BILL is telling you, in writing, that the test deposit is not the control that stops payment-diversion fraud. If you run accounts payable for clients in BILL, the job of confirming “did the real vendor actually ask me to send their money to this new account?” is still on you.
What BILL actually checks when you add or update a vendor
When you add a vendor bank account in BILL — or update one through a manual bank change — BILL initiates a one-cent (penny) test deposit to that account. The platform requires roughly two business days to complete the verification before the first ACH payment can be processed; until the test deposit clears, payments to that vendor fall back to check (BILL Help Center: Subscription-free basic account bank verification, BILL Help Center: Confirm manual vendor bank change). If the test deposit doesn’t post, BILL invalidates the bank account and emails you.
The test deposit answers a narrow question: does this account number plus this routing number exist, and can it accept an ACH credit? It is account validation. It is not identity verification on the person who emailed the change request, and it is not a check on whether the vendor authorized the update.
There is a second nuance worth knowing. The update flow itself isn’t an identity check — it’s a data-entry workflow. Anyone with the right access in your BILL instance can deactivate a vendor’s old bank account and add a new one based on whatever the inbound request says. BILL will then test-deposit the new account. That sequence runs the same way regardless of whether the source of the change request was the real vendor or a spoofed email — which is exactly the path attackers exploit.
Why a penny test doesn’t catch payment-diversion fraud
The most common way firms lose client money isn’t a hacked AP platform. It’s a believable email: “Our bank has changed — please update before the next invoice.” The attacker has often been reading a real mailbox for weeks, mirrors the vendor’s branding, and times the request around a real payment cycle. Sometimes the email even comes from the vendor’s actual address because the vendor itself has been compromised.
Walk it through BILL. You receive the email. You update the vendor’s ACH details inside BILL to the new (fraudulent) account. BILL fires the one-cent test deposit. It clears, because the fraudster’s bank account is a real account that can receive money. Everything in your BILL dashboard looks “verified.” The next ACH payment posts straight to the criminal.
The penny test did its job — the account was valid. The problem is validity was never the question. The FBI Internet Crime Complaint Center documented business email compromise losses in the billions of dollars in 2024 (2024 Internet Crime Report), and a large share trace back to exactly this swap.
The step BILL itself recommends — and where firms drop the ball
BILL’s own guidance for manual vendor bank changes is to verbally confirm the new account with the vendor on a number you already had, before the change is saved. That control has a name: an out-of-band callback. You call the vendor on a number from a prior invoice, a signed engagement letter, or your vendor file — not the number, link, or reply address attached to the change request — and you confirm the new account details verbally before you update BILL. Industry surveys show this is how the bulk of firms catch fraudulent change requests: roughly 55% verify bank changes in-house by phoning the vendor; only about 11% rely on penny verification alone.
Two more pieces make the control stick:
- Maker–checker (dual control). The person who entered the new bank details in BILL shouldn’t be the one who approves the change. Separating those duties is one of the most effective AP controls there is, and most cyber insurers will ask whether you do it after an incident.
- A documented audit trail. Record who you called, the number you dialed and where it came from, what you confirmed, who approved it, and when. Save the entry against the vendor so an auditor — or a cyber insurer reviewing a claim — can see the verification happened before the change.
None of those three pieces live inside BILL. The platform handles the payment plumbing. The verification-and-documentation layer is something you add on top of it.
Why this exposure is multiplied for firms running client AP
If you are a bookkeeping or accounting firm paying vendors for multiple clients through BILL, every client’s vendor list is a separate landing zone for “we changed banks” emails — and you’re the one who would have to prove the verification was done if a payment goes wrong. Relying on BILL’s test deposit as your control is the gap that gets firms — and their clients — burned.
Two practical patterns help:
- Treat every payment-detail change as unverified until someone has called the vendor back on a known number, gotten a second person’s approval, and logged it. Then — and only then — update BILL. No log, no change.
- Standardize the same procedure across every client. What auditors and insurers look for is consistency: the same verification step, the same documentation, across all vendors and all clients. Ad-hoc Slack messages, post-it notes, or “we usually call” don’t survive a claims review.
If you want a ready-made version of that procedure, our free vendor bank-change verification template lays out the independent-contact rule, a word-for-word callback script, a dual-approval step, and a one-page log sheet — no signup, nothing to buy. For the full mechanics see how to verify a vendor bank account change. If you carry cyber coverage, does your cyber insurance require a callback explains why many policies make that documented call a condition of paying a claim. And for the audit angle — exactly what an auditor will ask you to produce — read what auditors ask about vendor verification.
CallbackProof exists to make this routine across every one of your clients on BILL: it enforces the callback-and-approval sequence and keeps a tamper-evident, hash-chained log you can hand to an auditor or insurer. It’s a documentation and workflow tool — it doesn’t replace BILL and doesn’t move money; it records that the change was verified before it was made.
The bottom line
BILL’s test deposit confirms a vendor’s bank account is valid and can receive funds. It does not confirm a bank-change request is legitimate, and BILL itself recommends verbally confirming new bank details with the vendor before paying. The control that actually catches payment-diversion fraud is an out-of-band callback to a known number, with dual approval and a documented record, performed before you update the vendor inside BILL.
Frequently asked questions
Does BILL’s one-cent test deposit mean the new bank account is safe to pay?
No. The test deposit confirms the account is real and can receive ACH. It does not confirm the change request came from the real vendor. A fraudster’s account passes the test deposit too.
Does BILL recommend calling the vendor before saving a bank change?
Yes. BILL’s own help articles say to verbally confirm new bank account details with the vendor before paying, because business email compromise is a rising threat. The platform is explicit that the test deposit alone is not the control.
What’s the correct order of operations when a vendor sends a bank-change request?
Call the vendor on a number you already had (not one from the request), confirm the new account details verbally, get a second person to approve, log all of it, and then update the bank account in BILL. The change in BILL is the last step, not the first.
Does BILL re-verify a vendor’s bank account if the details change later?
BILL runs a fresh test deposit on the new account, but a test deposit only verifies the account itself, not the identity of the requester. The verification of who asked for the change has to happen out-of-band, before you update BILL.
What records will an auditor or cyber insurer ask for after a vendor-payment incident?
At minimum: who initiated the change, who verified it, the number called and where that number came from, what was confirmed on the call, who approved it, when it was approved, and when the change was made in BILL — with timestamps and an unbroken chain showing the verification happened before the payment.