SuiteTax Now Enforces Single Nexus Per Transaction with Line-Level Locations or Shipping

What changed

SuiteTax now performs a single nexus validation on transactions whenever either of the following is true:

• The Multiple Shipping Routes feature is enabled and the Enable Item Line Shipping checkbox is checked on the transaction.
• The transaction form includes the Location field at the line level.

When either condition applies, NetSuite determines the nexus from the first item line on the transaction. This becomes the transaction nexus. Every subsequent item line is validated against it. If any line resolves to a different nexus, the system blocks you from adding that line. You must move the mismatched line to a separate transaction.

Nexus resolution order

The source documentation does not spell out every fallback step, but the examples reveal the priority for nexus determination on each line:

1. Line-level location — if populated, the nexus of the location's country/jurisdiction is used.
2. Ship-to address (header or line level) — if no line-level location is set, the ship-to jurisdiction drives the nexus (for sales transactions).
3. Header location — used as a fallback when neither line-level location nor ship-to is present (visible in the purchase-transaction examples).

Importantly, only the first item line sets the transaction nexus. The order in which you add lines matters: if line 1 resolves to UK, every later line must also resolve to UK.

Sales transaction behavior

With line-level location enabled and MSR/item-line shipping disabled:

• Line-level location takes precedence over the header location for nexus calculation.
• If no line-level location is specified, the header ship-to address determines the nexus.
• Adding a line whose nexus differs from the first line's nexus triggers the validation error and the line is rejected.

Purchase transaction behavior

The same single-nexus rule applies. Line-level locations override the header location for nexus determination. Mixed-nexus lines are blocked.

What to do

1. Audit existing customizations — If you have SuiteScript (client scripts, user event scripts, or workflow action scripts) that programmatically add item lines to transactions, verify that all lines resolve to the same nexus. Scripts that add lines with mixed locations or ship-to addresses will now fail validation. Look for calls to currentRecord.selectNewLine() / currentRecord.commitLine() on sales and purchase transactions where you set location or shipaddress at the line level.
2. Review CSV imports and integrations — Any bulk import (CSV, SuiteTalk, REST) that creates transactions with line-level locations spanning multiple nexuses will be rejected. Split these into one transaction per nexus before import.
3. Update user training and transaction workflows — Users entering transactions manually need to understand that the first line locks the nexus for the entire transaction. Provide guidance on when to create separate transactions for multi-nexus fulfillment scenarios.
4. Check SuiteFlow / SuiteApprovals workflows — Workflows that modify line-level locations on existing transactions could trigger the validation. Test these in Sandbox.
5. Verify nexus configuration — Confirm that your subsidiary's nexus assignments and location-to-nexus mappings are correct. Mismatched or missing nexus assignments on locations could cause unexpected validation failures. Review under Setup > Company > Subsidiaries > [subsidiary] > Tax Nexuses and Setup > Company > Locations.
6. Test in Sandbox first — The release notes do not specify the exact release version. Before this reaches your production account, test multi-location transactions in Sandbox to identify any scripts or workflows that break under the new validation.

Open questions

The source documentation is light on several technical details:

• Release version — The page does not state which NetSuite release introduces this validation. Monitor your account's release notes and Sandbox refresh schedule.
• Error codes — No specific error code or exception type is documented for the validation failure. SuiteScript try/catch blocks around commitLine() should be tested to confirm what is thrown.
• SuiteTalk / REST API behavior — It is not stated whether the validation fires during REST or SOAP record creation, or only in the UI. Assume it applies globally until confirmed otherwise.
• Existing transactions — It is unclear whether previously saved transactions with mixed nexuses are grandfathered or will fail on edit. Test by opening and re-saving existing mixed-nexus transactions in Sandbox.