---
title: "NetSuite Vendor Bank Change Controls (7-Step Framework)"
description: "NetSuite vendor bank change controls: who can edit entity bank details, Payment Automation approval routing, system notes, saved search alerts, segregation of duties and an independent callback."
url: https://realpayee.com/guides/netsuite-vendor-bank-change-controls
canonical: https://realpayee.com/guides/netsuite-vendor-bank-change-controls
date_published: 2026-10-06
date_modified: 2026-10-06
updated: 2026-10-06
author: "RealPayee"
site: RealPayee
---

# NetSuite vendor bank change controls: a 7-step framework

> **NetSuite can enforce most of a bank-change control natively**: limit bank-detail access by role, route changes for approval (Payment Automation blocks payments while a vendor is Pending Approval and stops the editor approving their own change), audit with uneditable system notes and alert reviewers with saved search email alerts. What NetSuite cannot do is prove the real vendor asked for the change. Add an out-of-band callback or person verification before approval.

_Updated 2026-10-06 · 7 min read_

## Key takeaways

- Restrict edit access to entity bank details (Electronic Bank Payments) or Payment Manager-level access (Intelligent Payment Automation) to a small named group.
- In **Payment Automation**, a bank-detail change puts the vendor in **Pending Approval**: no payments can be submitted and the **editor cannot approve** their own change.
- **System notes** log who changed which field, old and new value, and **cannot be edited** by any user, script or app.
- A saved search with **Send on Update** alerts reviewers. None of this proves the real vendor asked: verify out-of-band first.

## The short version

Configured well, NetSuite handles the **who can change it**, **who approves it** and **what changed** parts of the control. It cannot tell you whether the email that triggered the change came from the real vendor. That gap is where business email compromise lives: the FBI advises using secondary channels to verify requests for changes in account information.

## NetSuite vendor bank change control framework (7 steps)

1. **Restrict who can edit vendor bank details.** With the Electronic Bank Payments SuiteApp, vendor bank accounts are stored as entity bank details on the vendor's Bank Payment Details subtab, and access is controlled through role permissions. With the Intelligent Payment Automation SuiteApp, the Payment Manager role has full access to bank account information and the Payment Clerk role can manage vendor ACH details. Give edit access to as few named people as possible and view access to everyone else who needs it.
2. **Route every bank-detail change for approval.** In NetSuite Payment Automation, modifying Vendor Bank Details (and billing address, preferred or accepted modes of payment, or remittance email) requires a vendor approval. While a vendor is Pending Approval you cannot submit payments for processing, and the user who modified the vendor cannot approve it. Approvers need the Vendor Master Approver role, the Administrator role or a custom role with access to the vendor record. If you pay through Electronic Bank Payments without Payment Automation, build an equivalent approval workflow.
3. **Verify the change out-of-band before approving.** The approver does not approve on the strength of the email. Someone calls the vendor on a number from records that existed before the request (never one in the request), reaches an authorized person and has them state the new details. Record the evidence against the vendor. See [is a callback enough?](https://realpayee.com/answers/is-a-callback-enough-to-stop-vendor-fraud) for where callbacks fail.
4. **Use system notes as the audit trail.** NetSuite system notes record the date and time of a change, who made it, the interface it came from, the type of change, the field changed and the old and new values, and Oracle states that system notes can't be edited by any user, script or app. Build a saved search over system notes for vendor and bank-detail fields so reviewers see every change in one list.
5. **Alert people other than the editor.** Turn that saved search into an email alert: on the saved search's Email subtab, enable Send Email Alerts When Records are Created/Updated and Send on Update, and filter the alert to the bank-detail fields. Send it to the controller and the AP manager, not only the person who made the edit.
6. **Keep editing, approving and paying apart.** The person who edits bank details should not approve the change or release payments to that vendor. In Intelligent Payment Automation, a payment approver cannot be the same person who created the payment. Review role assignments quarterly and remove access that is no longer needed. More on [segregation of duties in AP](https://realpayee.com/blog/segregation-of-duties-accounts-payable).
7. **Review the payment run and hold first payments.** Before each payment run is released, check it against the list of vendors whose bank details changed recently. Apply a cooling-off period (for example 24 to 72 hours) before the first payment to new details, and hold or limit that first payment until the vendor confirms receipt.

## What NetSuite does natively, and what it leaves to you

| Control | Native in NetSuite? | How |
| --- | --- | --- |
| Restrict who edits bank details | Yes | Role permissions on entity bank details (EBP) or Payment Manager / Payment Clerk roles (Intelligent Payment Automation) |
| Approval before a change is usable | Yes, in Payment Automation | Vendor goes to Pending Approval; payments can't be submitted; editor can't approve |
| Tamper-resistant audit trail | Yes | System notes: who, when, field, old and new value |
| Alert someone other than the editor | Yes, with setup | Saved search email alert with Send on Update, filtered to bank fields |
| Segregation of duties | Partly | Separate roles; payment approver can't be the payment creator (Payment Automation) |
| Confirm the real vendor asked | No | Out-of-band callback to a known contact, or person verification such as RealPayee |
| Cooling-off period and first-payment hold | No standard setting | Policy plus payment-run review |

> [!WARNING]
> **Approval is not verification**
> An approver who clicks approve because the request "looks right" adds little against a compromised vendor mailbox. Require the approver to see callback evidence (number dialed, its source, who stated the details) before approving.

## Where RealPayee fits

[RealPayee](https://realpayee.com/demo) sits on top of these NetSuite controls. It watches for vendor bank-detail changes and payments above your threshold, holds them, and asks the vendor's **known contact** (enrolled before the request) or the real executive to confirm out-of-band by SMS, Slack or Microsoft Teams, with phone-bound approval or government ID plus live selfie. The evidence (who confirmed, how, when) is attached automatically. It does not move money, does not validate account ownership against bank data, and does not replace the permission and segregation-of-duties steps above.

Write the rules down with our free [callback verification policy template](https://realpayee.com/templates/vendor-bank-change-policy), and see the general procedure in [how to verify a vendor bank account change](https://realpayee.com/how-to-verify-a-vendor-bank-account-change). Using another ERP? See the [QuickBooks Online](https://realpayee.com/guides/quickbooks-online-vendor-bank-change-controls) and [Xero](https://realpayee.com/guides/xero-vendor-bank-change-controls) guides.

## NetSuite vendor bank change controls

1. **Restrict who can edit vendor bank details** - With the Electronic Bank Payments SuiteApp, vendor bank accounts are stored as entity bank details on the vendor's Bank Payment Details subtab, and access is controlled through role permissions. With the Intelligent Payment Automation SuiteApp, the Payment Manager role has full access to bank account information and the Payment Clerk role can manage vendor ACH details. Give edit access to as few named people as possible and view access to everyone else who needs it.
2. **Route every bank-detail change for approval** - In NetSuite Payment Automation, modifying Vendor Bank Details (and billing address, preferred or accepted modes of payment, or remittance email) requires a vendor approval. While a vendor is Pending Approval you cannot submit payments for processing, and the user who modified the vendor cannot approve it. Approvers need the Vendor Master Approver role, the Administrator role or a custom role with access to the vendor record. If you pay through Electronic Bank Payments without Payment Automation, build an equivalent approval workflow.
3. **Verify the change out-of-band before approving** - The approver does not approve on the strength of the email. Someone calls the vendor on a number from records that existed before the request (never one in the request), reaches an authorized person and has them state the new details. Record the evidence against the vendor. See [is a callback enough?](https://realpayee.com/answers/is-a-callback-enough-to-stop-vendor-fraud) for where callbacks fail.
4. **Use system notes as the audit trail** - NetSuite system notes record the date and time of a change, who made it, the interface it came from, the type of change, the field changed and the old and new values, and Oracle states that system notes can't be edited by any user, script or app. Build a saved search over system notes for vendor and bank-detail fields so reviewers see every change in one list.
5. **Alert people other than the editor** - Turn that saved search into an email alert: on the saved search's Email subtab, enable Send Email Alerts When Records are Created/Updated and Send on Update, and filter the alert to the bank-detail fields. Send it to the controller and the AP manager, not only the person who made the edit.
6. **Keep editing, approving and paying apart** - The person who edits bank details should not approve the change or release payments to that vendor. In Intelligent Payment Automation, a payment approver cannot be the same person who created the payment. Review role assignments quarterly and remove access that is no longer needed. More on [segregation of duties in AP](https://realpayee.com/blog/segregation-of-duties-accounts-payable).
7. **Review the payment run and hold first payments** - Before each payment run is released, check it against the list of vendors whose bank details changed recently. Apply a cooling-off period (for example 24 to 72 hours) before the first payment to new details, and hold or limit that first payment until the vendor confirms receipt.

## Frequently asked questions

### Does NetSuite require approval for vendor bank detail changes?

In NetSuite Payment Automation, yes: modifying vendor bank details requires a vendor approval, payments can't be submitted while the vendor is Pending Approval, and the user who modified the vendor can't approve it. Outside Payment Automation you need to build an approval workflow yourself.

### Where can I see who changed a vendor's bank details in NetSuite?

In system notes, which record who changed which field, when, from which interface, and the old and new values. A saved search over system notes gives reviewers one list of all bank-detail changes.

### Can NetSuite alert me when vendor bank details change?

Yes, with setup. Create a saved search for the bank-detail fields and enable email alerts with Send on Update, sent to reviewers other than the editor.

### Is NetSuite's approval workflow enough to stop vendor fraud?

No. It stops unapproved changes from being used, but an approver can still approve a change requested from a hacked vendor mailbox. Verify with the vendor's known contact out-of-band before approving.

### How long should the cooling-off period be?

Common practice is 24 to 72 hours between approving new bank details and the first payment, long enough for a notice to the vendor's known contact to be seen and objected to. Set it in policy so nobody shortens it under pressure.

## Sources

- [Oracle NetSuite help: Vendors (Payment Automation vendor approval)](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_1006112830.html)
- [Oracle NetSuite help: Setting Up Intelligent Payment Automation Roles and Permissions](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_0531124014.html)
- [Oracle NetSuite help: Setting up primary bank for customer and vendor accounts (Bank Payment Details subtab)](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_157974753932.html)
- [Oracle NetSuite help: System Notes Overview](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/chapter_158644279544.html)
- [Oracle NetSuite help: Saved Search Email Alerts](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_0903092130.html)
- [FBI IC3 PSA: Business Email Compromise: The $55 Billion Scam (Sep 11, 2024)](https://www.ic3.gov/PSA/2024/PSA240911)
- [J.P. Morgan: When callbacks go wrong (Feb 27, 2026)](https://www.jpmorgan.com/insights/cybersecurity/business-email-compromise/when-callbacks-go-wrong)

## Related

- [How to Verify a Vendor Bank Account Change (7 Steps)](https://realpayee.com/how-to-verify-a-vendor-bank-account-change) - How to verify a vendor bank account change, step by step: 7 rules, an evidence checklist, red flags, and where to lock down bank details in NetSuite, QuickBooks Online and Xero. (markdown: https://realpayee.com/how-to-verify-a-vendor-bank-account-change.md)
- [Callback Verification Policy Template (Free SOP for Vendor Bank Changes)](https://realpayee.com/templates/vendor-bank-change-policy) - Free callback verification policy template for vendor bank account changes: a full SOP with RACI, independent contact rule, callback script, evidence log and checklist. Download as Markdown or text. (markdown: https://realpayee.com/templates/vendor-bank-change-policy.md)
- [QuickBooks Online Vendor Bank Change Controls (7-Step Framework)](https://realpayee.com/guides/quickbooks-online-vendor-bank-change-controls) - QuickBooks Online vendor bank change controls: custom roles, Bill Pay roles, approval workflows, the audit log, payment review and an independent callback to the vendor. (markdown: https://realpayee.com/guides/quickbooks-online-vendor-bank-change-controls.md)
- [Xero Vendor Bank Change Controls and the Notification Gap](https://realpayee.com/guides/xero-vendor-bank-change-controls) - Xero supplier bank change controls: the bank account admin permission, the notification gap (only the editor is emailed), the Assurance dashboard, alert apps, payment review and callbacks. (markdown: https://realpayee.com/guides/xero-vendor-bank-change-controls.md)
- [Book a RealPayee demo](https://realpayee.com/demo) - Book a demo of RealPayee: see vendor bank-change and high-value wire verification on your NetSuite, QuickBooks or Xero payment flow. (markdown: https://realpayee.com/demo.md)

---

**Further reading**
- [Vendor verification guide](https://realpayee.com/vendor-verification.md)
- [Free vendor bank-change policy template](https://realpayee.com/templates/vendor-bank-change-policy.md)
- [Compare: callbacks vs bank-account validation vs RealPayee](https://realpayee.com/compare.md)
- [Pricing](https://realpayee.com/pricing.md)

Canonical HTML: https://realpayee.com/guides/netsuite-vendor-bank-change-controls · Site index for AI agents: https://realpayee.com/llms.txt?src=md-footer · Pricing: https://realpayee.com/pricing.md · Book a demo: https://realpayee.com/demo