New NetSuite Payment Runs: How AP Teams Should Redesign Approvals
NetSuite 2026.2 adds a real Payment Run transaction. It does not just batch your payments. It moves the approval decision from the individual bill to the whole proposal, and that changes what your controls need to catch.
The short version
Payment Runs is a new non-posting transaction type in NetSuite 2026.2 that groups payable transactions so you can select a paying account, choose eligible transactions, review the total, approve the run, and then create the resulting vendor payments. It is core Accounts Payable functionality, available once the A/P feature is enabled, and it does not require the AP Automation SuiteApp.
The approval applies to the whole proposal, not to each generated vendor payment. Most AP approval matrices were written for per-bill or per-payment review, so they do not fit cleanly. If you leave both layers switched on, you get double approval. If you switch the wrong one off, you lose a control. This post walks the five decisions that matter.
What this covers
- What actually changed in 2026.2
- Batch review: what a reviewer can and cannot see
- Approval routing: the double-approval trap
- International vendors: one subsidiary, many currencies
- Exchange-rate estimates: the rate is a moving, editable number
- Bank-fee adjustments: the gap NetSuite does not fill
- A redesigned approval model
- Before your 2026.2 window
- FAQ
What actually changed in 2026.2
AP teams have had batch payment tools in NetSuite for years. Pay Bills has always let you tick multiple bills and pay them together. The Electronic Bank Payments SuiteApp has long handled payment batches and bank file generation. So it would be easy to read Payment Runs as a cosmetic upgrade.
It is not. The difference is that a payment run is a saved transaction record. Pay Bills selects payables and creates payments immediately. A payment run creates a record you can customize, review, edit, approve, audit and process later. That single change is what pulls approvals into scope.
What a payment run can hold:
- Vendor bills
- Vendor credits
- Journal entries with qualifying A/P lines
- Expense reports
- Bill payments carrying a remaining negative amount
Multiple vendors in one run, multiple A/P accounts in one run, and multiple transaction currencies in one run, provided Multiple Currencies is enabled. When you click Create Payments, NetSuite splits the run into separate vendor payments grouped by payee, currency, A/P account, exchange rate and billing address. That grouping logic matters later, so hold on to it.
Payment Runs does not replace Pay Bills. The Pay Bills page remains available, and no existing manual vendor payment process has to be retired. Treat Payment Runs as an additional path you adopt where a saved proposal, an approval step, or bulk payment creation earns its keep. For a low-volume team paying twelve bills a month, Pay Bills is still the right tool.
Three things are optional add-ons rather than defaults: Multiple Currencies, Installments, and Payment Run Approval Routing. Only the A/P feature itself is required. Which of those three you enable is effectively your first design decision.
Batch review: what a reviewer can and cannot see
The pitch for batch review is obvious. Instead of a controller opening forty bills one at a time, they open one record showing the selected payables, payment amounts, discounts, totals and supporting transaction detail, then make a single decision.
The risk is equally obvious. A reviewer approving a single line that reads "Total: 1,284,000.00" is approving forty vendor relationships, several currencies and a set of discount assumptions in one keystroke. Batch review only works if the batch is scoped so that one person can meaningfully hold it in their head.
Design the run, do not just fill it
The most common mistake we expect to see in the first quarter after upgrade is teams creating one enormous weekly run because the system now allows it. Better patterns:
- Split by risk, not by convenience. Domestic recurring vendors in one run, international and one-off vendors in another. The first can be reviewed quickly. The second deserves line-by-line attention.
- Split by A/P account or payment method. Since vendor payments group by A/P account anyway, aligning the run to that boundary makes reconciliation cleaner.
- Cap the run. A soft internal rule such as "no more than 40 lines or 250,000 per run" keeps review honest. Payment runs support custom transaction body fields, so a field capturing the run's purpose and a saved search enforcing the cap is straightforward. Our NetSuite saved searches guide covers the formula work.
Two limits to design around
First, custom column fields are not supported on the Transactions sublist. You can add custom body fields to the payment run itself, but you cannot add a custom column to the line list, and custom line values from the selected bills are not carried through to the generated vendor payments. If your current review depends on a reviewer seeing a custom field on each bill line, such as a project code, a contract reference or a risk flag, that information will not appear in the run. Plan to surface it in a saved search the reviewer opens alongside the run, or to put a summary of it in a body field.
Second, a payable reserved by one payment run is not fully locked. It cannot be added to a second non-completed run, but other payment paths are not blocked. If someone pays that bill through Pay Bills while the run is sitting in Pending Approval, NetSuite shows a warning and lets them continue. The run then fails on that line at payment creation. That is a real duplicate-payment and process-confusion risk during the review window, and it is a policy problem rather than a technical one.
Control to add on day one: a saved search alerting on bills paid outside a payment run while they are reserved by an open run. Nothing in the feature prevents it, and the failure only surfaces after approval, when someone is expecting payments to go out.
Approval routing: the double-approval trap
Payment run approvals use your established SuiteFlow or SuiteApprovals configuration. With approval routing enabled, the payment run record carries Approval Status and Next Approver fields, with statuses of Pending Approval, Approved and Rejected. Nothing exotic, which is good news: your existing approval tooling and the skills to maintain it both carry over.
The important sentence in the documentation is this one. Approval applies to the complete payment run proposal, its selected payables and the total payment amount across all payees. It does not approve each generated vendor payment separately, and standard vendor payment approval preferences still apply to the payments the run creates.
Read that twice, because it means both approval layers can fire.
The three layers you now have
| Layer | What it approves | Keep it? |
|---|---|---|
| Vendor bill approval | The liability. Is this a valid obligation at the right amount and coding? | Always. This is a different question from "should we pay it now". |
| Payment run approval | The disbursement proposal. Should this set of payables be paid, from this account, on this date? | Yes, where the run is the real control point. |
| Vendor payment approval | Each generated payment individually. | Usually redundant once run approval exists. Review and narrow it. |
Leaving all three fully active means an approver signs the bill, signs the run, then signs each payment the run produces. That is not a stronger control. It is approval fatigue, which reliably produces faster and less careful clicking.
The cleaner design for most mid-market teams:
- Bill approval stays unchanged and remains the primary coding and validity control.
- Payment run approval becomes the cash control, with thresholds based on the run total and routing by paying account.
- Vendor payment approval is narrowed by exception, not removed entirely. Keep it firing for payments above a high threshold, for new or recently changed vendor bank details, and for anything outside the normal run cycle. That preserves the per-payment check where fraud risk actually sits, without applying it to every routine line.
Approval is not execution
One procedural point teams get wrong in testing. Approving a payment run does not create payments. After approval the run moves to Open status, and a user must click Create Payments to start processing. Creation is asynchronous and runs in the background through the Bulk Processing Framework.
That gap is actually a feature for segregation of duties. You can route approval to a controller and restrict the Create Payments action to treasury, so the person who authorizes is not the person who releases. If your current design has one person doing both, 2026.2 is a good moment to split it. Both sides are governed by the Pay Bills permission and the role restrictions layered on it, so this is a role design exercise. Our NetSuite administration services team handles this kind of permission work routinely.
Partial failures need an owner too. If some lines succeed and others fail, the run lands in Completed with Errors. If every line fails it lands in Failed. Failed lines carry a warning icon and an error message in the Transactions sublist. Decide now who monitors that status and on what cadence, because a run sitting in Completed with Errors means some vendors were paid and some were not, and nobody is automatically told.
International vendors: one subsidiary, many currencies
This is where the feature is more generous and more restrictive than people assume, in different directions.
Generous on currency. A single payment run can include transactions in several currencies, as long as Multiple Currencies is enabled and the transactions satisfy the account, subsidiary and currency eligibility rules. The run itself has one Account currency, set by the paying account you select, while individual lines can carry different transaction currencies. So a US account paying a euro vendor, a sterling vendor and three domestic vendors in one run is supported.
Restrictive on subsidiary. A payment run can only have one subsidiary, derived from the selected Account. There is no cross-subsidiary support. Every selected transaction must belong to that same subsidiary.
For OneWorld customers running shared service centres, this is the single biggest planning constraint. If your AP team currently pays on behalf of six subsidiaries from a consolidated view, Payment Runs will not collapse that into one approval. You will run at least one payment run per subsidiary per cycle, which means your approval matrix needs a subsidiary dimension and your approvers need to understand they are signing six proposals rather than one.
Practical consequence: a shared service centre paying six subsidiaries weekly goes from one batch to six payment runs, each needing its own review, approval and Create Payments action. That is more clicks, but it also produces a cleaner audit trail per legal entity. Budget for the extra cycle time in your first two closes after upgrade.
Vendor payments are also split out by billing address at creation. For international vendors with multiple remit-to addresses on file, confirm the right address is defaulting before the run, not after the payments exist.
Exchange-rate estimates: the rate is a moving, editable number
This section deserves the most attention from anyone paying foreign vendors, because the exchange rate in a payment run behaves in three ways that will surprise an AP clerk.
1. The rate is tied to the payment date, and it refreshes
Payment runs source the system exchange rate effective on the payment date. Change the payment date and NetSuite refreshes the applicable line exchange rates for the new date. Discounts recalculate too, since discount availability depends on the payment date and the terms.
So a run approved on Monday for a Wednesday payment date, then pushed to Friday because a bank cut-off was missed, is not the same proposal any more. The rates have moved, the discounts may have changed, and the total a controller approved is no longer the total that will be paid. Nothing in the feature forces re-approval when that happens.
Policy to write before go-live: define a materiality threshold at which a payment date change requires re-approval. Something like "any payment date change, or any total movement above 0.5 percent or a fixed currency amount, resets the run to Pending Approval." This needs a SuiteFlow rule to enforce. It is exactly the kind of condition workflows handle well, and we cover the build pattern in our guide to automating workflows with NetSuite.
2. The rate is editable
The line exchange rate is editable when currency conversion is required, and read-only when the transaction currency and the subsidiary currency match. An editable rate must be greater than zero. That is the only system-enforced constraint.
Think about what that means for control. A user with edit rights on a payment run can change the exchange rate on a line, which changes the converted line amount, which changes the run total and ultimately the vendor payment created. There is no approval-specific guard on the rate field itself.
The mitigation is already in the product: the Transactions sublist carries a History link for line-level changes, and changes to Payment amount, Exchange Rate and Discount Taken can be reviewed there. Payment runs also appear in System Notes. So the audit trail exists. What does not exist by default is anyone looking at it.
Build a saved search over payment run line history that flags any manually edited exchange rate, and route it to whoever owns FX policy. If your treasury team uses contracted forward rates rather than the system rate, that edit is legitimate and routine, and you want it visible rather than prohibited.
3. The converted total is an estimate, not a settlement
NetSuite converts each line's payment amount into the Account currency using that line's exchange rate, and uses the converted line amounts, discounts and credits to calculate the Payment Run Total. That total is what your approver sees and signs.
Your bank will apply its own rate at execution. The two will differ. The difference lands as realized FX gain or loss when the payment is reconciled, which is normal and expected, but it means the approved total is a forecast. Say so explicitly in your approval policy, and set the tolerance your controllers should treat as acceptable. Approvers who believe they signed an exact figure will raise exceptions on every run.
Bank-fee adjustments: the gap NetSuite does not fill
Here is the honest position, because it is the part most upgrade briefings skip.
A payment run has no bank-fee field. Nothing in the Payment Runs record set captures correspondent bank charges, wire fees, lifting fees or intermediary deductions. The only native bank-fee calculation in NetSuite vendor payments is the Japan Zengin bank fee, which is delivered through the Electronic Bank Payments SuiteApp, driven by a Zengin fee schedule and a Vendor Bank Fees preference on the vendor record. If you are not paying through a Zengin template in Japan, that mechanism does not apply to you.
So for a US business wiring 50,000 USD to a European vendor, the payment run will create a vendor payment for 50,000. The vendor may receive 49,955 after an intermediary deduction, leaving a 45 residual on an invoice everyone believed was settled. Payment Runs does not change that, and it does not solve it.
The three ways teams handle it
| Approach | How it works | Best when |
|---|---|---|
| Absorb and write off | Pay the full amount, then clear the small residual to a bank charges expense account during reconciliation. | Fees are small, frequent and predictable. Lowest friction, needs a standing write-off threshold and a named owner. |
| Gross up at the bill | Where the contract says the vendor receives a net amount, add an expense line to the bill for the expected fee so the payment covers it. | Contracts specify net receipt. Puts the decision at bill entry, before the run, which is where it belongs. |
| Separate fee journal | Post actual bank fees as a journal entry on the bank statement line at reconciliation, leaving the vendor payment clean. | Fees are charged in aggregate by the bank rather than per payment. Cleanest audit trail. |
Whichever you choose, the design rule is the same: resolve fee treatment before the payment run, not inside it. The run is a proposal built from existing payables. If the fee is not already reflected in the bill or in your reconciliation policy, the run cannot help you, and trying to adjust payment amounts inside the run to compensate for an estimated fee will just produce residuals on the wrong side.
One further note for 2026.2 specifically. Because the bank reconciliation side of NetSuite was substantially rebuilt in the same release, with changes to match suggestions and payment application, do not test Payment Runs in isolation. Test the full cycle from run to payment to bank match, because the residual handling lives at the far end of it.
If fee handling is currently undocumented at your organization, that is worth fixing before the upgrade rather than after. A NetSuite health check will surface how your existing payments and reconciliation actually behave, which is usually different from how the process document says they behave.
A redesigned approval model
Pulling the five sections together, here is a model that works for a mid-market OneWorld business paying domestic and international vendors. Adjust the thresholds to your own authority matrix.
| Stage | Who | What they check |
|---|---|---|
| Bill approval | Budget holder, then AP | Validity, coding, three-way match. Unchanged from today. |
| Run preparation | AP specialist | Builds the run scoped by subsidiary and risk band. Confirms payment date, remit-to addresses, discount capture. |
| FX review | AP specialist or treasury | Reviews line rates on foreign-currency lines. Documents any manual rate override and why. |
| Run approval | Controller, by run total threshold | Approves the proposal: this set of payables, this account, this date, this estimated total. |
| Release | Treasury, separate role | Clicks Create Payments. Confirms the payment date has not moved since approval. |
| Exception payment approval | Finance director | Narrowed vendor payment approval, firing only above a high threshold or on changed vendor bank details. |
| Status monitoring | AP lead | Checks for Completed with Errors and Failed runs on a defined cadence. Owns the rework. |
| Reconciliation | GL accountant | Matches bank activity, posts FX difference and bank fees per policy. |
Most of this is configuration and workflow rather than development. The pieces that usually need build work are the re-approval trigger on payment date change, the saved search alerting on edited exchange rates, and the exception rules that narrow vendor payment approval. Those are standard SuiteFlow and saved search work, with a light SuiteScript touch only if your thresholds need logic workflows cannot express. If you are unsure which side of that line your requirements fall on, our guide to NetSuite configuration vs customization sets out the test, and our NetSuite customization services team builds the escalated cases.
We rebuilt exactly this kind of approval and reporting layer for a B2B distributor whose sales order approvals needed constant manual intervention. The pattern is in our NetSuite approval workflow case study.
Before your 2026.2 window
2026.2 reaches accounts on Oracle's staggered schedule, and your date sits in the New Release portlet on your dashboard. Payment Runs arrives switched on as part of core A/P, so there is no opt-in moment where you get to decide whether to think about it.
- Confirm your upgrade date from the New Release portlet and book sandbox time before it.
- Decide whether you are enabling Payment Run Approval Routing at all, and whether Multiple Currencies and Installments are in scope.
- Map your current approval matrix against the three layers above. Identify where double approval would occur.
- Agree the re-approval rule for payment date changes, and the FX tolerance your approvers should accept.
- Document your bank-fee treatment and name the owner of residual write-offs.
- Count how many payment runs per cycle your subsidiary structure will require, and check your approvers have capacity.
- Build the saved searches for edited exchange rates, reserved-but-paid-elsewhere bills, and runs in Completed with Errors.
- Confirm which custom fields your reviewers rely on today will not appear on run lines, and plan the workaround.
- Test the full cycle in sandbox, including bank reconciliation, not just the run itself.
- Train AP on the Approve then Create Payments two-step. It is the step people miss.
If your team does not have sandbox capacity to work through that list before the release window, that is a reasonable thing to bring in help for. Release readiness and sandbox testing are part of our NetSuite Support Services, and ongoing release management across both annual releases sits within NetSuite managed services.
Frequently asked questions
What are Payment Runs in NetSuite 2026.2?
Payment Runs is a new non-posting transaction type in NetSuite 2026.2 that groups payable transactions so you can select a paying account, choose eligible transactions, review the total payment amount, approve the run, and create the resulting vendor payment records. It is part of core Accounts Payable and does not need to be separately enabled beyond the A/P feature.
Do Payment Runs replace the Pay Bills page?
No. Pay Bills remains available and existing manual vendor payment processes do not have to change. Payment Runs is an additional path for cases where a saved, reviewable, approvable proposal or bulk payment creation is useful.
Do I need the AP Automation SuiteApp to use Payment Runs?
No. Payment runs are a core NetSuite transaction available when the A/P feature is enabled. Multiple Currencies, Installments and Payment Run Approval Routing can be enabled separately if you need those capabilities.
What exactly does payment run approval approve?
The complete proposal: the selected payables and the total payment amount across all payees. It does not approve each generated vendor payment separately, and standard vendor payment approval preferences still apply to the payments the run creates. Review both layers so you do not end up approving the same disbursement twice.
Can one payment run cover multiple subsidiaries?
No. A payment run has one subsidiary, taken from the selected paying account, and every selected transaction must belong to it. Shared service centres paying several subsidiaries will need one run per subsidiary per cycle.
Can one payment run include multiple currencies?
Yes, when Multiple Currencies is enabled and the transactions meet the account, subsidiary and currency eligibility rules. The run has one Account currency, set by the paying account, while individual lines can carry different transaction currencies.
What exchange rate does a payment run use?
The system exchange rate effective on the payment date. Changing the payment date refreshes the applicable line exchange rates for the new date and recalculates discounts. The line rate is editable where currency conversion is required and read-only where the transaction and subsidiary currencies match, and it must be greater than zero.
Can exchange rate changes on a payment run be audited?
Yes. The Transactions sublist provides a History link for line-level changes, covering Payment amount, Exchange Rate and Discount Taken. Payment runs also appear in System Notes. The audit trail exists, but nothing reviews it for you, so build a saved search that flags manual rate edits.
Does a payment run handle bank fees on international payments?
No. Payment runs carry no bank-fee field. The only native bank-fee calculation in NetSuite vendor payments is the Japan Zengin fee delivered through the Electronic Bank Payments SuiteApp. Correspondent and wire fees must be handled by absorbing and writing off the residual, grossing up at the bill, or posting a separate fee journal at reconciliation.
What happens if some lines in a payment run fail?
Processing continues for the valid lines. Failed lines are marked with a warning icon and an error message in the Transactions sublist. If some succeed and some fail the run status is Completed with Errors, and if all fail the status is Failed. Assign an owner to monitor these statuses, since a partially completed run means some vendors were paid and some were not.
Does approving a payment run create the payments?
No. After approval the run moves to Open status and a user must click Create Payments. Creation is asynchronous and runs in the background through the Bulk Processing Framework. The gap between approval and release is useful for segregation of duties.
Can a bill in a payment run still be paid another way?
It cannot be added to a second non-completed payment run, but other payment paths are not blocked. NetSuite shows a warning and lets the user continue. If that external payment changes the amount due or makes the transaction unavailable, the payment run line fails at payment creation.
Feature behavior described here is drawn from the Oracle NetSuite Help Center documentation for Payment Runs, including the Payment Run Frequently Asked Questions and Approving Payment Runs topics, and the NetSuite 2026.2 release notes for Vendors, Purchasing and Receiving. Oracle can change product behavior and release timing. Verify against your own account before relying on any detail for a go-live decision.
Planning your 2026.2 upgrade?
We will review your AP approval matrix against the new Payment Run layers, test the full cycle in your sandbox, and flag what breaks before your release window opens.
Santosh Krishnamoorthy is a Principal ERP Consultant at EPIQ Infotech, with extensive experience in NetSuite and enterprise systems. He works with finance and operations teams to improve reporting accuracy, streamline workflows, and build ERP environments that support sustainable growth. His writing focuses on practical insights drawn from real implementation and support experience.
Free Consultation
Talk to a NetSuite Expert
Response within 1 hour
