NetSuite ships with a credit hold mechanism. You can set a credit limit on a customer, configure whether the system enforces it automatically or requires manual approval, and mark overdue accounts for review. For a small business with a handful of orders a day, that is often enough.
For a wholesale distributor processing hundreds of orders across a customer base with varied credit arrangements, payment histories, and fulfilment requirements, it is not. The native controls are binary and coarse — an order either passes or it does not, based on a single credit limit comparison. There is no margin gate, no ship date awareness, no inventory commitment check, and no meaningful visibility on the order form about why a particular order is being held.
This article describes the automated order release system we built for a UK wholesale distributor. We will cover the business logic — the six factors the system evaluates before releasing an order to the warehouse — and how those factors are implemented in SuiteScript.
Why NetSuite's Built-In Controls Fall Short
NetSuite's native credit management offers three controls:
- A credit limit on the customer record, with an option to auto-hold or auto-warn when the limit is exceeded
- A credit hold override field that allows manual hold or manual release, bypassing the automatic check
- A days overdue trigger that can be configured to flag accounts with overdue invoices
These are reasonable primitives, but they have significant gaps in a wholesale distribution context:
They treat all overdue situations the same. A customer who is 16 days overdue on a £200 invoice and a customer who is 45 days overdue on £80,000 receive the same treatment — a flag on the account that holds all orders. There is no threshold configuration without custom development.
They do not account for margin. A sales order that has been discounted to zero profit — whether by mistake or by an unusual deal — ships the same as a full-margin order. Nothing in the standard system flags it.
They have no ship date awareness. An order placed today for delivery in three weeks will appear in the pending fulfilment queue immediately, consuming planner attention and obscuring genuinely urgent orders. The system has no concept of a future release date.
They cannot enforce ship-complete before release. If a customer requires their order shipped in a single consignment, NetSuite has no mechanism to hold the order until all lines are fully committed to inventory. A partial shipment will go if the warehouse processes it.
They offer no visibility on the order form. When a sales representative opens an order that is on hold, the native system tells them very little about why. They typically need to navigate to the customer record and piece together the credit picture manually.
They do not handle the return authorisation effect correctly. NetSuite's consolidated open order value includes open Return Authorisations as a negative. If a customer has £10,000 of open sales orders and a £2,000 pending return, the consolidated figure shows £8,000 — understating the true sales order exposure when calculating credit headroom.
None of these gaps are insurmountable with standard configuration. They require custom development.
The Six Checks That Actually Matter
The system we built evaluates six factors before releasing an order to the warehouse. An order passes only if all applicable checks pass — or if a specific override has been applied by an authorised user.
1. Net Credit Exposure vs Credit Limit
The headline check, but calculated properly.
Net exposure is: outstanding balance + open sales order value − deposits on account
Open sales order value is taken from NetSuite's consolidated unbilled orders field, but corrected for the Return Authorisation effect. The system runs a search for open RAs for the customer and its sub-customers, sums the outstanding amount, and adds it back to the consolidated figure. Without this correction, a customer with significant pending returns appears to have more credit headroom than they actually do on the sales side.
For multi-currency customers, the system selects the appropriate currency fields — NetSuite's fxconsolbalance and fxconsolunbilledorders for foreign currency accounts, the standard consolidated fields for GBP accounts. The credit limit itself is always stored in the customer's currency, so the comparison is always like-for-like.
An order is held if the customer has no credit limit set and any positive net exposure, if net exposure exceeds the credit limit, or if a manual credit hold is active on the customer record.
2. Days Overdue Threshold
This check runs independently of the credit limit. A customer can be within their credit limit but consistently paying late — that payment behaviour matters, and it should affect whether orders are released.
The system checks NetSuite's consolidated days overdue figure and holds any order where the customer is more than 15 days overdue. The hold reason is recorded separately from the credit limit hold, so overrides can be applied independently. A customer who is 20 days overdue but has significant credit headroom presents a different risk profile from a customer who is 20 days overdue and at their limit — the system records both pieces of information.
3. Gross Margin Threshold
Every order is evaluated against a minimum gross margin requirement — 10% in this implementation. The margin is calculated from NetSuite's estimated gross profit percentage field, with fallback calculations from estimated gross profit and estimated cost where that field is not populated.
Low-margin orders are held with a clear reason: the specific margin percentage and the threshold it fell below. This catches discounting errors before they reach the warehouse, and it creates a visible audit point — if the sales team wants to release the order, they need to explicitly override the margin hold, which is recorded. A large volume order at thin margin may be intentional; the override mechanism exists for exactly this reason.
4. Ship Date Gate
If a sales order has a ship date set to a future date, the system holds it until that date arrives. This is a relatively simple check but has a significant operational impact. Without it, orders placed with forward ship dates accumulate in the pending fulfilment queue, making it difficult for the warehouse to prioritise genuinely urgent work.
The check parses the ship date using NetSuite's format module to handle locale-specific date formatting correctly, compares it to midnight on the current date, and applies a hold with the specific ship date recorded in the reason. The scheduled Map/Reduce script re-evaluates orders regularly, so an order held on ship date grounds is automatically released when the date arrives — no manual intervention required.
5. Ship Complete and Inventory Commitment
Some customers require orders shipped in a single consignment — either because of their receiving process, invoicing requirements, or contracted terms. For orders marked as ship-complete, the system checks that every line has sufficient inventory committed before releasing the order. The check is: quantitycommitted + quantityshiprecv ≥ quantity ordered for each line, excluding discount, markup, and non-inventory line types.
If any line is under-committed, the order is held with a specific count: how many lines are fully committed and how many are not. This gives the warehouse and planning teams precise information — they know immediately how many lines need attention before the order can be released. When the remaining stock is committed, the scheduled job automatically re-evaluates and releases the order.
6. Manual Holds and the Risk-Free Override
The system supports two types of exception that sit outside the automated evaluation logic.
Manual holds are applied via a custom credit hold field on the customer record, distinct from NetSuite's native credit hold override. The custom field applies regardless of any other status — a customer on manual hold stays on hold even if every other check passes. Manual holds are used by the credit control team for situations that do not fit the automated rules: a disputed invoice, a customer in a payment plan, or a known issue not yet reflected in the financial data.
Risk-free customers are accounts where credit checks are not appropriate — typically major retail chains or public sector bodies where credit risk is effectively zero. Risk-free status is read from the parent company record for customers in a hierarchy, so a branch or trading entity inherits the designation from its parent automatically. Risk-free customers bypass the credit limit check, the days overdue check, and the exposure calculation. They do not bypass the margin check, the ship date gate, the inventory commitment check, or a manual credit hold.
The Override Model
Every hold reason has its own override. A user with appropriate permissions can set an override flag on the order that releases a specific hold while leaving others in place. A credit hold override releases the credit limit and days overdue checks. A margin hold override releases the margin check. These are separate fields, applied to the order, and both are visible in the evaluation result displayed on the order form.
The override model matters because it is more useful than an all-or-nothing release. A sales manager might be confident in overriding a margin hold on a specific order without being willing to override a credit hold. Conflating the two forces an unnecessary choice. And overrides are recorded in the evaluation output — when someone views the order, they can see that an override is active and which check it applies to. This is the audit trail.
The Architecture: Four Scripts
The system is built from four SuiteScript 2.1 files with clearly separated responsibilities.
The evaluation library contains all the business logic. It takes a sales order ID, runs the checks, and returns a structured result object: approved or not, the reasons for any holds, and the detailed data for each check. It also generates an HTML summary and embeds a JSON representation of the data in an HTML comment within the same string. One field on the sales order stores both the human-readable status and the structured data that other scripts can parse.
The Map/Reduce script runs on a schedule and evaluates all sales orders in Pending Fulfilment or Partially Fulfilled status that have not yet been approved. The Map/Reduce framework handles governance limits automatically, making the script scalable to order volumes that would exceed the limits of a simpler scheduled script.
The User Event script handles the sales order form in view mode — displaying a colour-coded banner at the top of the form and triggering a re-evaluation whenever an order is saved, so changes to the order are immediately reflected without waiting for the next scheduled run.
The Client script handles the form in edit and create mode, providing the same banner in contexts where the User Event approach cannot be used for UI messages.
The separation between the evaluation library and the scripts that call it means the business logic can be modified and tested independently. Adding a new check — a minimum order value threshold, or a check against a custom credit rating field — requires a change to the library only.
A Note on Replacing Standard Functionality
Implementing custom order release logic requires disabling NetSuite's native credit hold where it overlaps with the custom checks. The native hold is an account-level setting; the custom system operates at the order level. Running both in parallel produces confusing and sometimes contradictory results.
The practical approach is to set all customer accounts to manual credit hold override mode — effectively disabling automatic native holds — and rely entirely on the custom system for release decisions. This gives you full control over the logic and the user experience, at the cost of owning the maintenance of that logic as NetSuite evolves.
For any wholesale distributor with a meaningful order volume and a varied customer base, that trade-off is usually straightforward. The native controls are too coarse to meet the operational requirements, and a custom system that you understand and maintain is more reliable than a native system that does not do what you need.
Fowlers Consulting Services Ltd are an AI-first NetSuite consultancy based in the UK. If you are implementing NetSuite for wholesale distribution and need help with order management automation, get in touch.