Supplier bank account changes in Accounts Payable: controls before approval

A supplier bank account update is a master-data change, not a routine correction to one invoice. An error can send an otherwise valid payment to the wrong account. The operating model below must be aligned with the client’s system, banking permissions and procedure.

1. Separate the request from the master-data update

Log the request as a separate case with supplier ID, company, country, currency, scope and intended effective date. Retain the intake channel and the document on which the request is based.

Do not copy an account straight from an invoice or message into the supplier record. An invoice can reveal a discrepancy that needs investigation, but it does not replace the agreed master-data change process.

2. Verify identity and source through an independent channel

Confirmation should use a previously known channel independent of the message that contains the new account. Use an approved contact from the master record or contract, not a phone number supplied in the same request.

Record who confirmed the change, when, with whom and which data were checked. Do not place a full bank account number in broadly accessible notes; apply masking and role-based access under the client policy.

3. Compare values before and after the change

The reviewer should see current and proposed values, account holder, country, currency, bank, IBAN or local identifier, and the level at which the account applies. Oracle distinguishes supplier, address and site levels, which affects approval routing.

Clarify changes to the primary account, factor account and supporting document as well. Do not restrict review to the number alone: currency, country or status changes can alter payment behaviour.

4. Require approval before the account is available

Microsoft describes a workflow where protected fields remain proposed until approval and a new account is not available for use before authorisation. Agree which fields trigger workflow, including updates arriving through imports and interfaces.

The person entering the change should not approve it alone. The approver checks evidence, independent confirmation and before-and-after values; rejection should leave a clear status and a controlled route for correction.

5. Hold payment while uncertainty remains

If the change is pending, disputed or unverified, flag the case and apply the agreed control that prevents use of the new data. Do not solve the issue by making a manual payment outside the workflow.

Before the next payment proposal, compare the beneficiary account with the approved master record and recent-change list. Give extra attention to changes made just before the due date, urgent requests and differences between invoice and master data.

6. Retain the audit trail and review first use

SAP notes that change history can show time, user, previous value and bank details added or deleted. Keep the request, verification evidence, decision, system history and activation date with the case.

After approval, review the first payment to the changed account: supplier, amount, currency, beneficiary account and settlement evidence. First-use review does not replace approval, but it can reveal a configuration error or an incorrect account scope.

Sources and scope of this guide

• Microsoft Learn: Vendor bank account workflow
• Oracle: Internal Supplier Profile Bank Account Change
• Oracle: Use Procurement BU and Bank as Change Request Approval Attributes
• SAP Help: Displaying Changes to Supplier/Vendor Master Records

Microsoft, Oracle and SAP documentation was checked on 31 October 2026. Field names and workflow behaviour depend on the product and configuration. Bank-data verification, change approval and payment execution require the client’s procedures and permissions.

Need a clearer workflow for Accounts Payable documents and exceptions? Explore financial and accounting process support and agree client-side responsibilities and controls.