Does Xero Verify Vendor Bank Account Changes?

Xero handles vendor banking in two places, and it helps to keep them separate.

First, the contact record. Each supplier contact can store a bank account number. When you enter a bill to pay, Xero surfaces the stored account details so you can compare them against what's on the invoice in front of you. That visual prompt is genuinely useful — it's the moment a sharp bookkeeper notices “this account number doesn't match what we paid last month.” But it's a prompt, not a control: Xero shows you the number, it doesn't confirm the change request behind it was legitimate, and it doesn't force you to do anything before saving the new value.

Second, online bill payments. In the US, Xero's bill-pay rail is powered by Melio. The first time you pay a supplier this way, you enter their bank details into the payment flow; Melio validates and saves them for future payments. To update them later, you re-enter the details during the payment process and they overwrite what's on file. Melio's checks confirm the account is real and can receive funds — a useful data check, but again, not a verification of who requested the change. (If a supplier is on the Melio Supplier Network, the payment method is locked to what the supplier set, and you can't change it in Xero at all.)

So Xero gives you: stored details, a side-by-side prompt at payment time, and destination-account validation on the pay rail. What it doesn't give you is independent confirmation of the request's origin.

The verification Xero (and Melio) performs is on the data — does this account exist, can it receive ACH, does it match the format. The verification neither tool performs is on the identity of the person who asked you to change it.

Picture the common attack. A bookkeeper receives an emailed invoice or a “please update our remittance details” message that looks like it's from a known vendor. The new account is real and ACH-capable — it belongs to the fraudster. The bookkeeper updates the contact record (or re-enters details in the pay flow), Xero shows the new number, Melio confirms it can receive money, the payment goes out. Every machine check passed. The money is gone.

The FBI's 2024 Internet Crime Report attributed $2.77 billion in losses to business email compromise, and a large share of those losses came from exactly this pattern: payee-redirect schemes where the attacker changes where an otherwise legitimate invoice gets paid. The tooling did its job. The verification that would have caught it lived outside the tool — a phone call to a number the fraudster didn't control.

Two Xero-specific wrinkles make the gap easy to miss. Batch payments mean a single altered contact record can quietly redirect a payment inside a larger run, where it's harder to spot. And Xero does not natively produce a clean “supplier bank account changed” audit report — it's a long-standing request in Xero's own community forum — so reconstructing when a number changed and who verified it after the fact is harder than firms assume.

NACHA Phase 2 is in effect as of June 22, 2026. It applies to every ACH-originating business with no volume floor — including small bookkeeping firms running client AP through Xero. The rule asks originators to use commercially reasonable methods to confirm the legitimacy of vendor banking-detail changes, and to be able to produce evidence of that verification when asked.

Xero's stored details and bill-entry prompt don't meet that bar on their own. Here's what to layer on top:

1. An out-of-band callback to a phone number you already had for the vendor — from a signed engagement, an old invoice, or your vendor master file. Never the number on the change request or in the email that referenced it.
2. A read-back script so the vendor states the new account and routing numbers to you, rather than you reading them out for confirmation. (We wrote the exact callback script you can use word for word.)
3. A dated log entry capturing who called, who answered at the vendor, the source of the number dialed, what was confirmed, and who on your side approved the change afterward.
4. A second approver for changes above a threshold — many cyber and funds-transfer-fraud endorsements require it (see does your cyber insurance require a callback?).

None of this fights Xero's workflow. It runs alongside it as a gate: the new account can be entered in the contact record or pay flow, but it isn't paid until the callback is logged.

Multi-client firms hit two recurring failure modes on Xero specifically:

• The bill-entry prompt feels like verification. Because Xero shows the stored account next to the invoice, it's easy to treat a quick visual match as “checked.” It isn't — matching the number you were given against the number you stored proves consistency, not legitimacy. If both came from the fraudster, they'll agree perfectly.
• The change history is hard to reconstruct. Without a native bank-change report, the evidence that you verified a specific change on a specific date for a specific client tends to live in scattered emails, if it exists at all. When an auditor or insurer asks “show me how you confirmed this was real,” that's the artifact most firms can't produce on demand.

Both are fixable with a routine that takes about three minutes per change. The hard part is making it run every time, across every client, with no quiet exceptions.

For firms running multiple clients on Xero, this is the routine that holds up under a NACHA Phase 2 review or a social-engineering insurance claim:

1. A bank-change request arrives (emailed invoice, remittance update, or new vendor setup). Treat the account as entered but not payable.
2. Before updating the contact record or releasing the payment, the assigned bookkeeper calls the vendor on a number from prior records — not from the request or the latest email.
3. The vendor reads the new routing and account numbers back. The bookkeeper compares them to the request and updates the Xero contact only after they match.
4. The bookkeeper logs the callback — date, time, who they spoke with, the source of the number — somewhere tamper-evident and reviewable across all clients.
5. Only then is the bill scheduled or the batch run released.

If you want a ready-made version of steps 2–4, our free vendor bank-change verification template lays out the independent-contact rule, the read-back script, the dual-approval step, and a one-page log sheet — no signup. For the underlying mechanics, the step-by-step procedure walks through every checkpoint.

CallbackProof is the cross-client documentation layer that sits next to Xero: it enforces that callback-and-log sequence on every change, across every client you serve, and hashes each entry into a SHA-256 chain so the verification record is provable months later when an auditor or insurer asks for it.