The quick answer
Create a SuiteFlow workflow on Transaction > Bill Payment with four states: Entry, Pending Approval, Approved and Rejected. Put Add Button actions for Approve and Reject on Pending Approval. From Entry, add a transition to Pending Approval with the condition Total > 5,000.00 and one to Approved with Total <= 5,000.00. Then add transitions from Pending Approval to Approved and Rejected that run on the Approve and Reject buttons.
Know what you're building before you start. This workflow does not hold the payment. The bill payment still saves, posts and applies to the bill, and sitting in Pending Approval doesn't stop any of that. What you get is a visible approval step and a Workflow History of each state the payment went through and when. If the rule is that cash must not go out until someone approves, use native Vendor Payments approval routing with the In-Transit Payments feature instead, or control the step that releases the money.
The screenshots show sample data. Person and company names are fictional. Use your own threshold, payments and names when following the steps.
Before you start
In this example, Alex Morgan is the administrator at Example Supply Co. The controller wants a second person to sign off on every bill payment over 5,000.00. There are four September payments from 1020 Operating Checking, and two of them get opened in this guide: check 20418 to Coastline Steel Supply for 7,480.00, and check 20419 to Ridgeway Office Products for 1,265.00.
First, pick the right tool. NetSuite's native approval for vendor payments is the Vendor Payments option under Setup > Accounting > Accounting Preferences > Approval Routing, and it's built around in-transit payments. With the In-Transit Payments feature on, a payment can wait for approval before it posts. Use that when unapproved cash must not leave. In this account In-Transit Payments is off, so bill payments have no Approval Status field. A threshold rule or a multi-level sign-off on ordinary bill payments then needs a custom workflow, which is what this guide builds.
You need the Workflow feature turned on under Setup > Company > Enable Features and a role that can create workflows, such as Administrator. The workflow adds buttons, states and history. It doesn't send emails, build an approval queue, ask for a rejection reason or handle resubmission; those are separate pieces you'd add. Build it in Testing. A Testing workflow only runs for its owner, so nobody else sees the buttons while you're working on it.
01. Look at a large payment first
Go to Transactions > Payables > Pay Single Vendor > List. The Bill Payments list shows check 20418 to Coastline Steel Supply and check 20419 to Ridgeway Office Products. The list shows payment amounts as negatives, -7,480.00 and -1,265.00, because the money is going out.
Open check 20418. The buttons are Edit, Back and Void. Nothing on the page asks anyone to approve 7,480.00.
Open the System Information subtab, then Active Workflows. It says No records to show, so no workflow is running on this payment yet.
02. Create the workflow
Go to Customization > Workflow > Workflows > New. Enter these values:
- Name: Bill Payment Approval
- Record Type: Transaction
- Sub Types: Bill Payment
- Release Status: leave it at Testing
- Initiation: Event Based
- Event Definition: check On Create and On View Or Update
On Create starts the workflow when a new payment is saved. On View Or Update also starts it when someone opens or edits an existing payment, which is how the two payments already in the list enter the workflow in this guide. It also makes every view an evaluation point, so once testing is done, use On Create alone if only new payments should route.
Click Save. The workflow opens in the designer with one state, State 1, marked START. The Workflow panel on the right shows Transaction (Bill Payment), Testing and both events.
03. Add the states
Double-click State 1. In Workflow State, change Name to Entry and click Save. Entry stays the start state.
Click + New State. The new state appears at the top left of the workspace. Double-click it, name it Pending Approval, click Save, and drag it below Entry.
Add two more states the same way, Approved and Rejected. On both, check Do Not Exit Workflow before you save. Neither state has a transition out, so Do Not Exit keeps the workflow active there and Active Workflows keeps showing Approved or Rejected. Without it, the workflow ends in that state, and a workflow that also runs On View Or Update can start again the next time someone opens the payment.
Drag Approved to the right of Pending Approval and Rejected below it. Approved and Rejected now show the Do Not Exit icon in their bottom left corner.
04. Add Approve and Reject buttons
Select Pending Approval and click + New Action at the bottom of the State panel. Choose Add Button. In Workflow Action, keep Trigger On at Before Record Load, enter Approve in Label, and click Save.
Click + New Action again, choose Add Button, enter Reject in Label and click Save. The State panel for Pending Approval now lists Record Load > Before Record Load with Add Button Label: Approve and Add Button Label: Reject. Before Record Load means the buttons are added as the payment loads while it's in this state.
05. Route payments by amount
Double-click Entry, open the Transitions subtab and click New Transition. Set To to Pending Approval. Click the icon beside Condition to open the condition builder, then set:
- Field: Total
- Compare Type: greater than
- Value: 5,000.00
Click Add, then Save.
Use Total here, not the field labelled Amount. On a bill payment, the Amount you see on the form showed up as Total in the condition builder. In testing, a condition on Amount couldn't be evaluated: the workflow log reported the field as not found, both transitions came out false, and the payment sat in Entry. If your account lists the fields differently, check the result in the workflow log.
Back on the Workflow Transition dialog, the Condition box reads Total > 5,000.00. Save the transition.
Click New Transition again. Set To to Approved and build the condition Total, less than or equal, 5,000.00. The Condition box reads Total <= 5,000.00. Save the transition. Entry's Transitions subtab now has both rows. Save Entry.
A payment of exactly 5,000.00 matches the second condition, so it's approved automatically. If that's not what you want, use greater than or equal on the first transition and less than on the second.
On the diagram, select the arrow from Entry to Pending Approval. The Transition panel shows Condition Total > 5,000.00.
06. Connect the buttons to their states
Double-click Pending Approval, open Transitions and click New Transition. Set To to Approved and Execute On Button to Approve, then save the transition. Click New Transition again, set To to Rejected and Execute On Button to Reject, and save it. Save Pending Approval.
Execute On Button lists the Add Button labels on the state you're transitioning from. If the button label and the Execute On Button value don't match, clicking the button does nothing.
The diagram is finished. Entry leads to Pending Approval and to Approved, and Pending Approval leads to Approved and to Rejected.
07. Open the payments again
Go back to Transactions > Payables > Pay Single Vendor > List and open check 20418. Approve and Reject now appear next to the standard Void button. Opening the payment started the workflow, because On View Or Update is checked, and 7,480.00 is more than 5,000.00.
Open System Information > Active Workflows. Bill Payment Approval shows Current State Pending Approval and Status Active.
Click Back and open check 20419 for 1,265.00. It has no Approve or Reject buttons. Active Workflows shows Current State Approved, because 1,265.00 is 5,000.00 or less.
08. Approve the large payment
Click Back, open check 20418 again, and click Approve. The page reloads and the Approve and Reject buttons are gone. Amount is still 7,480.00, the account is still 1020 Operating Checking, and the Apply subtab still shows the bill it paid.
Open System Information > Workflow History. It lists newest first: Approved, then Pending Approval, then Entry. Active Workflows now shows Current State Approved.
Check the result
- Check 20418 for 7,480.00 showed Approve and Reject, and Active Workflows read Pending Approval before anyone clicked.
- Check 20419 for 1,265.00 had no buttons, and Active Workflows read Approved.
- After Approve, check 20418's Workflow History has rows for Entry, Pending Approval and Approved, and Active Workflows reads Approved with Status Active.
- Neither payment's amount, account or applied bill changed. The workflow recorded the decision and nothing else.
Before you set Release Status to Released, lock down who sees the buttons. Anyone who can view the payment sees Approve and Reject unless you add a condition to both Add Button actions, for example on the user's role or a named approver. Test it as the owner, as an approver and as someone who shouldn't approve. Hiding a button isn't a full security control, so also restrict who can edit, void or process payments. Then pair the approval with the step that actually releases the cash, such as who can print checks or create the payment file.
If a payment stays in Entry, open the Log link on its Workflow History row and show the rejected transitions. A condition on the wrong field shows up there. Turn on Enable Logging on the workflow if the log is empty.
Common questions
Should I use native vendor payment approval routing or a workflow?
Use native Vendor Payments approval routing when an unapproved payment must not go out. It works with the In-Transit Payments feature, where a payment waits for approval before it posts. Use a SuiteFlow workflow when you want a custom rule, like routing payments over 5,000.00 to Pending Approval, and you're fine with it recording the decision rather than holding the money.
Does a workflow approval stop the bill payment from posting?
No. The bill payment still saves, posts and applies to the bill while it sits in Pending Approval. The workflow adds the Approve and Reject buttons and tracks the state. If the cash has to wait, use native approval routing with In-Transit Payments, or control who can print checks and create payment files.
Why don't my bill payments have an Approval Status field?
The native Approval Status on vendor payments comes with approval routing for in-transit payments. In this example In-Transit Payments is off, so bill payments have no Approval Status field. The workflow doesn't add one either. It tracks its own states, which you see under System Information.
Which field do I use for the bill payment amount in a workflow condition?
Use Total. In testing, a condition on the field labelled Amount failed with Field 'amount' Not Found in the workflow log, and the payment stayed in Entry. Total, the amount you see on the form, routed the payments correctly.
Why does my workflow stay in the first state on a bill payment?
Open the Log link on the payment's Workflow History row and look at the rejected transitions. The usual cause is a condition that can't be evaluated, like one on Amount instead of Total. Also check that the workflow is on the Bill Payment sub type and that its events match how the payment was created or opened.
What happens to a payment of exactly 5,000.00?
It goes straight to Approved. The conditions are Total > 5,000.00 and Total <= 5,000.00, so only payments over 5,000.00 stop in Pending Approval. Use greater than or equal to on the first transition if 5,000.00 should need approval too.
What does Do Not Exit Workflow do?
It keeps the workflow active in Approved or Rejected, so Active Workflows keeps showing that state. It doesn't hold the payment or send it back for approval. Without it, the workflow ends there, and a workflow that runs On View Or Update can start again the next time someone opens the payment.
How do I limit who can approve a bill payment?
Add a condition to both Add Button actions, for example on the user's role or a named approver. Without one, anyone who can view the payment sees Approve and Reject. Hiding a button isn't a full security control, so also restrict who can edit, void or process payments.
What is the difference between Testing and Released for a workflow?
A Testing workflow runs only for its owner, so nobody else sees the buttons while you build it. Released runs it for everyone the workflow applies to. Switch to Released after the routing and the approver conditions work.