Does Sage Verify Vendor Bank Account Changes?

Sage is a family of products — Sage 50, Sage Accounting (Business Cloud), Sage Intacct, and the 200/300/X3 line — and the details differ, but the verification posture is the same across all of them. Here's what the supplier-banking workflow gives you.

First, the vendor record. Each supplier holds bank details — routing and account number for US ACH and direct-deposit vendor payments, or sort code and account number in the UK editions. When you edit those fields, Sage saves the new value and uses it for the next payment run. Nothing in the save step asks you to prove the change request was legitimate; it's a straightforward field edit.

Second, the audit log. This is Sage's genuine strength. You can review every change made to a supplier's bank details, with the event marked as an amendment and both the old value and new value recorded — account number, sort code or routing number, account name, payment reference, and the rest. So after the fact, you can reconstruct exactly which field changed and when.

Third, on products that support it, change notifications. Sage can automatically email people whenever a supplier's bank details are amended — typically everyone with access to the audit log — so the change doesn't happen silently. That's a useful tripwire.

So Sage gives you: stored details, a complete amendment history, and an alert when something changes. What it doesn't give you is a gate that confirms the request was real before the new account becomes payable.

The verification Sage performs is on the record — what changed, when, and by which user. The verification Sage does not perform is on the identity of the person who asked you to change it. And the order matters: the audit-log entry and the notification email both fire after you've already saved the new account number. By the time the alert lands in an inbox, the redirected account is sitting in the vendor record, ready for the next payment run.

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 edits the Sage vendor record, the audit log dutifully captures the old and new numbers, the notification email goes out, and on the next run the payment leaves for the fraudster's account. Every Sage feature worked exactly as designed. The money is still 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.

There's a Sage-specific trap worth naming. Because the audit log is so good, it's easy to mistake traceability for control. A complete record of a fraudulent change is still a fraudulent change. The log tells you a number moved; it can't tell you whether the human behind the request was the real vendor or someone impersonating them. And a notification email that goes to several people often means it gets actioned by no one — each assumes someone else checked.

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 Sage. 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.

Sage's audit log and change alerts are good evidence that a change occurred, but they aren't evidence the change was verified. 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 Sage's workflow. It runs alongside it as a gate: the new account can be edited into the vendor record and captured by the audit log, but it isn't paid until the callback is logged.

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

• The audit log feels like the control. Because Sage records every amendment so cleanly, it's tempting to treat “it's in the log” as “it's been checked.” It hasn't — the log proves a change was made; it says nothing about whether the request behind it was legitimate. An auditor or insurer isn't asking whether the number changed — they're asking how you confirmed it was real.
• The notification gets diffused. When the change email lands in five inboxes, responsibility blurs. Without a named owner who must complete and record a callback before the account is payable, the alert becomes background noise — seen, not acted on.

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 Sage, 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 edited but not payable — even once it's in the Sage vendor record.
2. Before releasing any 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 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, not just in the Sage audit trail for one company file.
5. Only then is the payment 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 Sage: 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 client's Sage file.