Does Stampli Verify Vendor Bank Account Changes?

Stampli's vendor management story centers on its vendor portal. Vendors are invited to a secure self-service workspace where they enter and maintain their own banking details, W-9, insurance, and remittance preferences. When a vendor updates a bank account, Stampli doesn't have your bookkeeper rekeying numbers from an email — the vendor types them in.

Once those details land, the platform applies the controls it markets under Advanced Vendor Management:

• Pre-payment data checks. Stampli validates the routing/account format and runs the vendor record against your ERP master data before a payment can be released.
• Configurable approval routing. Bank-detail changes — like invoices — can be routed through sequential approval chains by vendor, GL, department, or amount.
• Re-authentication on high-risk events. Approvers can be required to re-verify their identity before authorizing payments to a brand-new account or an unusually large transfer.
• Payment blocking on incomplete or expired records. If documentation is missing or stale, Stampli will hold or reroute the payment instead of sending it.
• Immutable audit trails. Every edit — who changed what, when, from what value to what value — is captured for review.

In a normal “we hired a new vendor and they want to be paid by ACH” workflow, that stack does what NACHA, your insurer, and your auditor want to see. It's a meaningful upgrade over emailed PDFs and a shared spreadsheet.

The verification Stampli runs is on the data (does this routing number exist, are the W-9 fields populated, is this vendor allowed to be paid at all). The verification it can't run is on the identity of the person who typed the data into the portal.

If a vendor's email is compromised, an attacker can use the legitimate Stampli portal invite — or impersonate the vendor on a “we lost the link, can you re-send” pretense — and submit the new account themselves. From the platform's perspective, the right account has the right format, the W-9 is on file, and an authorized portal user updated it. The change passes every machine check.

This isn't a Stampli problem; it's a problem common to every self-service portal in the AP category. 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 payee-redirect schemes where the attacker simply changes where an otherwise legitimate invoice gets paid. The bookkeeper running the platform did everything inside the tool; the verification it couldn't perform was the one that lived outside the tool.

That's the gap the callback closes. Stampli proves the account exists, that approvers signed off, and that you have a clean audit log. The callback proves the request came from the real vendor.

NACHA Phase 2 takes effect Monday, June 22, 2026. It applies to every ACH-originating business with no volume floor — including small bookkeeping firms running client AP through Stampli. The rule asks originators to use “commercially reasonable” methods to verify the legitimacy of vendor banking-detail changes, and to be able to produce evidence of that verification on request.

Stampli's internal controls satisfy parts of that expectation: segregation of duties, approval routing, audit trail. What you still need to layer on top:

1. An out-of-band confirmation — a callback to a phone number you already had for the vendor, sourced from a signed engagement, an old invoice, or your vendor master file. Never from the portal change or the email that referenced it.
2. A short verbal script so the vendor reads the new account number and routing number back to you, not the other way around. (We wrote the exact callback script you can use verbatim.)
3. A dated log entry that records who called, who answered at the vendor, the source of the number that was called, what was confirmed, and who on your side approved the change after the callback.
4. A second approver for changes above a threshold (many cyber and funds-transfer-fraud endorsements require this — see does your cyber insurance require a callback?).

None of that contradicts Stampli's workflow. It runs alongside it, ideally as a hard gate: the new account is entered in the portal and queued, but it doesn't become payable until the callback is logged.

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

• The portal makes the callback feel redundant. Because vendors self-serve and approvers sign off inside the app, it's easy to think the verification has already happened. It hasn't — it's been recorded, which is different from verified by an independent channel.
• The audit log is internal to Stampli, not your callback evidence. Stampli's audit trail is excellent for internal change history, but it doesn't capture the phone call. If an auditor or an insurer asks “show me how you confirmed this change request was real,” the Stampli log shows the change, not the confirmation. The callback has to be logged somewhere designed to record verifications.

Both are easy to fix with a routine that takes about three minutes per change. The hard part is making sure it runs every time, across every client, with no quiet exceptions.

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

1. Vendor enters the new account in the Stampli portal. Stampli routes the change for internal approval and flags the payment as pending.
2. Before any approver inside Stampli clicks approve, the assigned bookkeeper places an outbound call to the vendor on a number from prior records — not from the portal invite, not from the change request, not from the latest email.
3. The vendor reads the new routing and account numbers back to the bookkeeper. The bookkeeper compares them to what's in the Stampli record.
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 does the Stampli approver release the change for payment.

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 callback 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 itself is the cross-client documentation layer that sits next to Stampli: 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.