NetSuite Three-Way Match: What the Platform Enforces vs. What SuiteScript Adds
Why standard NetSuite does not block unapproved or unmatched vendor bills, and what SuiteScript enforcement looks like for controllers who need hard controls.
Controller trying to enforce three-way match in NetSuite before bills can be approved? SuitePacific builds this for live accounts.
NetSuite-Certified · Post-go-live specialist · Sandbox-first development · Month-to-month
Quick answer
Three-way match refers to the process of verifying that a purchase order, an item receipt, and a vendor bill agree before payment is released. NetSuite links these records and makes the relationships visible, but does not block bills from being approved if a PO is missing, the billed amount exceeds the PO, or no item receipt exists. This is a controls gap auditors flag regularly. SuiteScript enforcement adds a User Event script that fires Before Submit on the vendor bill record, checks for a linked PO, validates quantity and amount within a configurable tolerance, and throws a hard error if the check fails. Vendor exception categories handle utilities, rent, and recurring services that legitimately have no PO. SuitePacific works with live NetSuite accounts to design, build, and test this enforcement in Sandbox before deploying to production. Month-to-month from $799.
What does NetSuite do natively for three-way match?
Links the records and shows the relationship
NetSuite links vendor bills to the purchase orders and item receipts they were created from. The link is visible on the bill record, and bills created directly from a PO automatically populate line items from the PO. The relationship is traceable in saved searches and reports.
Does not block bills without a linked PO
A user can create a vendor bill manually with no PO link. NetSuite will not stop this at any point in the approval process. The bill can be approved and paid without any purchase authorization check. This is by design in the standard platform and is the most common gap auditors identify.
Does not validate amount against PO
Even when a bill is linked to a PO, NetSuite does not prevent the billed amount from exceeding the PO amount. There may be a visual indicator in some contexts, but no hard validation or block. An over-billed invoice can proceed through the approval workflow and be paid.
Native NetSuite vs. SuiteScript enforcement: what each provides
The core difference is hard block versus soft warning. SuiteScript enforcement prevents the bill from saving; native NetSuite at best shows a visual cue.
| Control | Native NetSuite | With SuiteScript Enforcement |
|---|---|---|
| PO required before bill | No (soft warning at most) | Hard block if no linked PO |
| Quantity match check | No automatic validation | Billed qty vs. PO qty enforced |
| Amount within tolerance | No | Configurable tolerance (e.g. 5%) |
| Receipt before payment | No | Item receipt required to pass |
| No-PO exception handling | N/A (anything passes) | Vendor-level exception categories |
| Threshold alerts | None | Controller alert near tolerance limit |
| Audit trail | Transaction links only | Validation log per bill |
| Hard block vs. warning | Warning only | Hard block (Before Submit) |
What does SuiteScript three-way match enforcement include?
The enforcement script covers four layers: hard block, configurable tolerance, vendor exceptions, and controller alerts.
Hard block on Before Submit
The SuiteScript User Event script fires on the vendor bill record Before Submit, before the record can be saved or approved. If the validation fails, the script throws a SuiteScript error and the bill cannot be saved. This is a hard control, not a recommendation.
Configurable tolerance settings
Tolerance settings are configurable per account: for example, allow billed amount up to 5% over the PO amount to cover freight and miscellaneous charges. Tolerance values are stored in a custom configuration record and can be updated without touching the script.
Vendor-level exception categories
Certain vendor categories (utilities, rent, recurring services, one-time subscriptions) are flagged on the vendor record to bypass the PO requirement. The exception is logged in the audit trail. This avoids blocking legitimate bills that will never have a PO.
Near-tolerance alerts to the controller
Bills that pass matching but are within a configured percentage of the tolerance threshold are flagged for controller review before approval. The alert is a workflow notification, not a hard block, giving the controller visibility without stopping the bill.
How SuitePacific helps
SuitePacific designs and builds three-way match enforcement scripts for live NetSuite accounts, including tolerance configuration, vendor exception categories, and alert routing to the controller. The script is tested in Sandbox against the account's real vendor and PO data before deploying to production. This is typically a 4-6 week build within a Care plan. Month-to-month from $799.
Related reading
- NetSuite workflow automation covers SuiteFlow and SuiteScript automation for approval routing and process controls in live accounts.
- NetSuite SuiteScript development covers how custom scripts are built, tested, and maintained for controls and automation needs.
- NetSuite native AP vs. Tipalti covers when to add AP automation to complement the controls built in NetSuite.
- NetSuite post-go-live support covers the full scope of SuitePacific's ongoing support for live NetSuite accounts.
Frequently Asked Questions
What is three-way match and why does it matter?
Three-way match is the process of verifying that a purchase order, an item receipt, and a vendor bill all agree before allowing payment. The purpose is to ensure: (1) there is an approved PO authorizing the spend, (2) goods or services were received before payment, and (3) the billed amount matches the PO amount within an acceptable tolerance. Without three-way match enforcement, vendors can be paid for goods not received, amounts exceeding what was approved, or without any purchase authorization at all.
Does NetSuite enforce three-way match natively?
No. NetSuite links vendor bills to purchase orders and item receipts, and the relationship is visible on the bill record. But NetSuite does not block a bill from being approved if there is no linked PO, if the billed amount exceeds the PO amount, or if no item receipt exists. A user can create and approve a vendor bill with no PO and no receipt, and NetSuite will not stop it. This is a controls gap that auditors and internal audit teams flag regularly.
Can I configure NetSuite to block bills without a PO?
Not through standard configuration. NetSuite's approval workflows (SuiteFlow) can route bills for approval based on conditions, but they cannot add a hard validation that prevents saving a bill without a PO. A User Event SuiteScript running Before Submit is required to add a true hard block. SuitePacific builds this validation as part of a Care plan.
What happens to bills that don't have a PO?
With the SuiteScript enforcement in place, a bill without a linked PO (and without a vendor-level exception category) will throw a validation error on save. The AP team sees the error message immediately and must either link the correct PO or have the vendor record updated to include an exception flag before the bill can proceed. Without enforcement, non-PO bills pass through and are paid without any authorization check.
How do you handle exceptions to three-way match?
Vendor-level exception categories handle recurring exceptions cleanly. Common categories include utilities (monthly bills with no PO process), rent (lease payments), and subscription software (annual renewal invoices). These categories are flagged on the vendor record. When the validation script sees the flag, it logs the exception and allows the bill to proceed without a PO. New exception categories can be added by updating the vendor record without modifying the script.
Will this break my existing bill entry process?
It will require that existing bills created without POs either get a PO linked or have the vendor flagged as an exception. For most accounts, this is a one-time cleanup of the vendor record structure to identify which vendors legitimately never have POs. SuitePacific tests the script in Sandbox against the account's real vendor and PO data before deploying to production, which surfaces any edge cases before go-live.
Ready to get the right approach in place? SuitePacific works with live NetSuite accounts month-to-month.