Does AvidXchange Verify Vendor Bank Account Changes?

AvidXchange is an AP automation platform with deep roots in real estate, property management, HOA, and nonprofit AP — verticals with high vendor turnover, where banking details change often and payments frequently leave a client's bank by ACH. Understanding who controls the banking data explains where verification really lives.

Much of the supplier banking sits on the supplier's side of the network. Suppliers enrolled in the AvidPay Network maintain their own payment details through the AvidXchange Supplier Hub, and the platform asks suppliers to promptly notify it of any change to their bank account information, typically via ACH authorization forms signed by an authorized representative. When a supplier updates their own banking inside the network, that's a self-service change managed between the supplier and AvidXchange — not something your firm keys in.

On your side, as the paying firm or the bookkeeper running a client's AP, you approve invoices and release payments; AvidXchange routes them across its network to the supplier's chosen method. AvidXchange also markets platform-level risk screening and a built-in audit trail to support compliance.

So the picture is: suppliers manage their own banking in the network, AvidXchange screens the payments it processes, and you approve what gets paid. What's missing from that chain is a step that proves the human who asked for a given change was the real vendor — confirmed through a channel the requester doesn't control, and recorded before the money moves.

It's easy to assume that because AvidXchange enrolls suppliers, collects signed ACH forms, and runs risk screening, the change-request problem is handled. It isn't, and the distinction is precise.

AvidXchange verifies things about the account and the network: that a bank account can receive ACH, that an enrolled supplier submitted the form, that a payment matches expected patterns. What no platform can verify for you is the origin of the request that started a change — the email or call that told a bookkeeper “our bank changed, here's the new account.” If that message came from an impersonator and the new account is a real, ACH-capable account the fraudster controls, every downstream step can still execute cleanly.

There's also a recurring point of confusion worth naming. Firms regularly ask whether AvidXchange itself reaches out to a vendor to confirm a payment-method change, or whether the vendor has to initiate it — the answer isn't always obvious from inside the product, and that ambiguity is exactly where a redirected payment slips through. If you assume the platform called the vendor and the platform assumed the supplier enrolled legitimately, nobody actually performed an independent check on the request.

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

Multi-client firms hit two recurring failure modes on AvidXchange specifically.

The first is the “the network handled it” assumption. Because suppliers self-enroll and AvidXchange screens payments, it's tempting to treat the platform as the verification layer. But your firm is the ACH originator on the client's payments, and the request to change a vendor's details often reaches you — by email, by a portal message, by an updated invoice — before it ever touches the supplier network. Whoever receives that request owns the obligation to confirm it.

The second is traceability mistaken for control. AvidXchange's audit trail is a strong record of what moved through the platform. But a complete record of a fraudulent change is still a fraudulent change. The trail tells you a payment went somewhere; it can't tell you whether the person who requested the new account was the genuine vendor. An auditor or insurer reviewing a loss won't ask whether the payment is logged — they'll ask how you confirmed the change was real before you released it.

For a firm running AP across many property-management or HOA clients, the additional problem is that any evidence inside AvidXchange lives inside that platform's view of those payments. It isn't a single, portable verification record spanning every client you serve — including the ones you pay by wire, by QuickBooks Bill Pay, or straight from the client's bank.

NACHA Phase 2 took effect June 22, 2026. It applies to every ACH-originating business with no volume floor — including small bookkeeping firms originating client payments through AvidXchange. 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.

AvidXchange's supplier enablement and audit trail are good evidence that a payment occurred; they aren't evidence that you verified the change request. 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.
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 AvidXchange's workflow. It runs alongside it as a gate: a change can flow through the supplier network and the audit trail, but you don't release the next payment to that vendor until the callback is logged.

For firms running multiple clients through AvidXchange, 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 — an emailed remittance update, a new-vendor setup, or a supplier “we changed banks” notice. Treat that vendor's payments as held, not released, regardless of what the platform shows.
2. Before approving the next payment to that vendor, the assigned bookkeeper calls them 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 the change stands only if 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, not just inside one platform's payment history.
5. Only then is the payment released in AvidXchange.

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 AvidXchange: 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 — a single, portable evidence trail that doesn't live inside any one platform.