Vendor Bank Account Changes: How AP Verifies New Remit-To Details Before the Payment Run
An invoice arrives from a supplier you have paid for years. The amount is right, the PO matches, and at the bottom is a short line: please note our new banking details. If AP updates the account and pays, the money may go to someone who is not the supplier. This post covers where bank detail changes come from, how to catch the ones that skip the request process, and how to verify them before the payment run.
In brief
- A request to change a vendor's bank account is the single most valuable instruction AP receives, because one approved change redirects every future payment to that vendor.
- Changes arrive by more routes than the formal request form: a new account printed on an invoice, a remit-to address in an e-mail footer, or a letter attached to a statement.
- Comparing the bank details printed on every incoming invoice against the vendor master catches changes that never came through the request process.
- Verification means calling the vendor on a number already on file, never one supplied with the request, and holding payments to the new account until a second person approves.
Why one field matters more than the rest
Most invoice errors cost the amount of one invoice. A wrong quantity, a duplicate, a missed credit memo: each is found and recovered one document at a time. A vendor's bank account is different. Once a new account is saved in the vendor master, every payment to that vendor follows it, so one bad change can redirect a month or more of payments before anyone notices.
That is why payment fraud aimed at businesses so often targets this field. The pattern is well known: someone gains access to a real vendor's e-mail account, or registers a lookalike domain, watches the conversation for a while, and then sends a polite message asking AP to update the bank details. The invoices that follow are real, with real PO numbers and expected amounts. Every check that looks at the invoice passes. Only the destination of the money has changed.
The vendor usually finds out first, when it chases an overdue invoice that AP shows as paid. By then the funds have often moved on, and recovery depends on how quickly the bank is told. A verification step that takes ten minutes before the change is saved is far cheaper than that conversation.
5
routes a bank detail change can arrive by, in the chart below
4
checks run on every invoice against the vendor master
7
steps in the change control routine at the end of this post
Where bank detail changes come from
Most AP teams have a change request form, and most of their controls are built around it. The trouble is that changes do not only arrive through the form. A vendor that switched banks may simply print the new account on its next invoice. A remittance address can change in an e-mail signature. A letter announcing new details may be stapled to a statement. Each of these is a change request in practice, even if nobody filed one.
Formal change request form
E-mail from vendor contact
New details printed on an invoice
Letter or notice with a statement
Vendor portal update
The highlighted routes are where fraud attempts tend to arrive, because they look like ordinary correspondence. They are also where honest changes slip through: a clerk keying an invoice sees a new account number, assumes the vendor master is out of date, and updates it. The control has to cover every route, not only the form.
Catching changes the form never sees
The reliable way to see every change is to compare what each invoice says against what the vendor master holds, every time. Most invoices print the remit-to details: bank name, routing number, account number or its last digits, and a remittance address. If those fields are read from each invoice, four checks catch almost every unannounced change.
Vendor identity
Match the invoice to the vendor by tax ID and name, not by the e-mail address it came from. A lookalike domain will not change the tax ID printed on a convincing copy of a real invoice, so the identity match confirms which vendor master record to compare against.
Bank details
Compare routing and account numbers with the record on file. A mismatch is the signal. It is not a reason to update the record; it is a reason to start verification. Some vendors print several accounts for different currencies, so the comparison should be against all the accounts on file for that vendor.
Remittance address
A changed remit-to address matters for check payments and is often the first sign that a vendor's details have been tampered with. A move from a street address to a PO box in another city is worth a question even when the bank details look unchanged.
Change language
Phrases such as new banking details, updated remittance information or please pay to the account below are a flag in their own right, even if the printed details happen to match. They often signal that a request is coming by another route.
Never update the vendor master from an invoice
What the comparison looks like
In the example below, a long-standing supplier's invoice prints a different routing number, a different account and a PO box in place of the street address on file. The tax ID matches, so this is the right vendor record, and the notes ask AP to use the new details immediately. The bank details on file were last changed more than three years ago.
{ "invoice": { "vendor_name": "Example Industrial Supply LLC", "vendor_tax_id": "12-3456789", "invoice_number": "84417", "invoice_date": "2026-10-14", "invoice_total": 18650.00, "remit_to": { "bank_name": "Example Community Bank", "routing_number_last4": "4412", "account_number_last4": "7731", "address": "PO Box 5521, Dallas, TX 75201" }, "notes": "Please note our new banking details effective immediately." }, "vendor_master": { "vendor_id": "V-01882", "tax_id": "12-3456789", "routing_number_last4": "9058", "account_number_last4": "0418", "remit_address": "1400 Commerce St, Dallas, TX 75201", "bank_details_last_changed": "2023-03-02" }, "check": { "tax_id_match": true, "bank_details_match": false, "remit_address_match": false, "change_language_in_notes": true, "action": "pay to account on file or hold; open verification" }}Every condition for a hold is here. The invoice itself may be entirely genuine, and the supplier may really have changed banks. Either way, the next step is the same: pay to the account on file if the invoice is due and otherwise approved, or hold it, and open a verification case for the new details. The urgency in the note is not a reason to skip that. Pressure to act immediately is one of the most common features of a fraudulent request.
Verifying the change
Verification is about the channel, not the content. A request that arrives by e-mail cannot be confirmed by replying to the same e-mail, or by calling a number printed in it, because whoever sent it controls both. The call goes to a number already in the vendor master, on a signed contract or on the vendor's past correspondence, and to a contact you have dealt with before.
On the call, ask the vendor to confirm the new details rather than reading them out yourself. Record who made the call, who answered, the date and time, and what was confirmed. Then a second person, not the one who took the request, approves the change in the vendor master. That separation is what stops one compromised inbox or one hurried clerk from redirecting payments alone.
The first payment after a change deserves its own attention. There is no history on the new account, so many teams hold it for an extra approval and confirm with the vendor once it has been received. The same applies to a brand-new vendor's first payment. Notify the vendor's known contact when the change takes effect, too: if they never asked for it, that message is how you find out quickly.
A change control routine for AP
- Read the remit-to bank name, routing number, account digits and remittance address from every incoming invoice as separate fields.
- Match each invoice to its vendor record by tax ID and name, and compare its remit-to details with every account on file.
- Flag mismatches and change language in the invoice or e-mail; never update the vendor master from them.
- Pay to the account on file or hold the invoice, and open a verification case for the new details.
- Call the vendor on a number already on file, ask them to state the new details, and record the call.
- Have a second person approve the vendor master change, and notify the vendor's known contact that it took effect.
- Hold the first payment to the new account for an extra approval and confirm receipt with the vendor.
The routine fits next to the controls AP already runs. The same identity match by tax ID and bank account is what makes duplicate invoice detection work across vendor records. A vendor's statement is another place new details appear, so the monthly statement reconciliation should read its remit-to block too. And because extraction pipelines that read e-mail can themselves be targeted, it is worth reading how prompt injection affects document extraction before automating any of this.
Where extraction fits
The comparison only works if the remit-to block is read on every invoice, including the ones that arrive as attachments in a busy inbox. Done by hand, that is the first check skipped when the month gets heavy. Parser extracts each invoice into structured JSON against the fields you define in a template, including the vendor tax ID, the remit-to bank details and address, and any free-text notes, through upload, e-mail or the API. Your ERP or a short rule then compares those fields with the vendor master and routes every mismatch to verification. The decision to change where money goes stays with people, on a channel they trust.