A controller sent us two invoices last month. Same customer, same SKU, same week. One had 8.25% tax. The other had zero.
Nothing obvious had changed on the customer or item. The difference was the ship-to on one order and the warehouse location on the other. SuiteTax took those inputs, picked a different nexus, and calculated accordingly.
If you only looked at the customer and the tax code, it looked random. It wasn't. Tax Details showed exactly what NetSuite had done.
What you're looking at
With SuiteTax enabled, sales and purchase transactions have a Tax Details subtab. Click Preview Tax, or save the transaction, and NetSuite fills in the nexus, subsidiary tax registration, and line-level tax detail: type, code, basis, rate, and amount.
The Items tab tells you the tax total. Tax Details tells you how NetSuite got there.
1 Nexus selected by NetSuite. 2 Tax Details Override is off. 3 Tax Point Date still matches the invoice date. TX-AUSTIN at 8.25% is 6.25% Texas + 1.0% City of Austin + 1.0% Austin MTA (Capital Metro). Travis County does not levy sales tax. That 8.25%
A few fields worth knowing by name:
· Nexus - the tax jurisdiction assigned to the transaction. In the U.S., that's usually a state.
· Subsidiary Tax Reg. Number - the registration tied to that nexus on the subsidiary. Change the nexus and the registration follows.
· Tax Point Date - the date SuiteTax uses for taxation. It does not always match the invoice date.
· Nexus Override and Tax Details Override - one changes the nexus NetSuite uses; the other lets you replace the calculated tax details manually.
You need Edit on the Tax Details Tab permission to change any of this. View-only roles can see the fields, but they cannot correct them. Oracle also advises against customizing the Tax Details sublist. If tax calculations start failing after a customization, this is one of the first places we'd check.
How the same customer taxes two ways
Legacy NetSuite tax was largely ship-to driven. SuiteTax looks at more than that. It can use ship-to, location, billing, and subsidiary address data, then match those inputs against the nexuses on the subsidiary's Tax Registrations subtab.
On a sales transaction, "ship from" is not always the warehouse you'd expect. NetSuite uses this order:
1. Line-level location, if it's enabled on the form
2. Shipping address, for drop-ship transactions
3. Header-level location
4. Subsidiary shipping address
5. Subsidiary main address
If Multiple Shipping Routes is on and Enable Item Line Shipping is checked, the line-level ship-to can affect the result too. SuiteTax still allows only one nexus per transaction. NetSuite sets the transaction nexus from the first item line and blocks any later line that resolves to a different one. The error tells you to create a separate transaction for that line.
Purchases skip the drop-ship bullet. Ship-to is built from line-level location, then header-level location, then subsidiary shipping address, then subsidiary main address. There is no shipping-address step. U.S. use tax, when it calculates automatically, keys off the address in Location. If Location is empty, the engine uses the subsidiary shipping address. If Location has no address, it uses the subsidiary main address. Lookup is ZIP+4-based, so no ZIP means no tax. If the Ship To state is not the transaction nexus, the engine always applies the non-liable tax code. That last one explains more $0 invoices than most tax-code hunts.
Invoice A shipped to Austin, so SuiteTax selected Texas. Invoice B was will-call from an Oregon 3PL, so Location drove the result and Oregon has no state sales tax. No tax code changed. The transaction inputs did.
When the same customer gets two different tax results, check for one of these first:
· One order shipped and the other was pickup, so Location changed the result
· Line-level location was enabled on one form but not the other
· A drop-ship transaction used a vendor address for ship-from
· The subsidiary has nexus in the state, but the tax registration dates do not cover the transaction date
One easy-to-miss issue: if Allow Free-Form States in Addresses is enabled, NetSuite expects the two-letter state abbreviation. "Texas" can fail the match. "TX" works. Oracle documents this, and it still shows up in real accounts.
If the countries or U.S. states on the transaction do not match any subsidiary tax registration, NetSuite throws the Ship From / Ship To / Subsidiary mismatch error. That's usually an address or registration setup issue, not a bad tax calculation.
Credit memos need extra attention. If the location changes, SuiteTax can select a different nexus from the original invoice. Oracle documents the sequence: Nexus Override back to the original nexus, run Preview Tax, then turn on Tax Details Override so the credit stays aligned while you finish editing it.
What Tax Details Override actually does
Tax Details Override makes the tax type, code, basis, rate, and amount editable. You can add tax lines, change them, or remove them. The box is unavailable when the determined nexus is marked tax-exempt. There is no engine on a tax-exempt nexus, so there is nothing to freeze.
Once you check it, Preview Tax is disabled. If you uncheck it later, the current tax amounts are cleared.
While the override is on, changing ship-to, location, items, or other transaction data will not recalculate the tax lines. NetSuite still sends the form data to the tax engine for reporting, but it leaves the tax details alone.
1 Preview Tax is disabled. 2 Tax Details Override is on. 3 The tax line is editable. In this example, TX-EXEMPT and 0.00 were entered manually. The invoice can still post, which is exactly why overrides need review.
Override is useful. It is also a very clean way to book the wrong tax amount without realizing it.
Good reasons to use it:
· A one-off the engine cannot model, such as a negotiated rate, an unsupported jurisdiction, or a credit that has to match the original invoice
· U.S. consumer's use tax entered manually on a vendor bill
· A migrated legacy transaction you need to preserve rather than recalculate
The red flag is simpler: the calculated number was not what someone expected, so they turned on Override and typed the number they wanted.
Nexus Override is a different tool. Use it when NetSuite selected the wrong nexus but you still want the engine to calculate the tax. Pick the correct nexus, confirm the subsidiary tax registration, then run Preview Tax.The field ID for Nexus Override is taxregoverride (Tax Registration Override in the Records Browser). Tax Details Override uses taxdetailsoverride.
If Tax Details is empty and you need to enter tax manually, NetSuite makes you choose a Nexus Override first. After that, you can turn on Tax Details Override and enter the tax lines.
One permission catch: once Tax Details Override is on, a user needs Edit on Tax Details Tab just to edit the transaction. A billing clerk without that permission can be locked out of an otherwise normal invoice.
The invoice date is not always the tax date
Tax Point Date can differ from the transaction date, but that distinction matters differently depending on the tax regime. The Tax Reporting Framework preference that uses Tax Point Date does not apply to U.S. SuiteTax reporting. It starts out equal to the transaction date. It can move in two ways:
1. On the nexus record, check Use fulfillment to modify tax point date. If a fulfillment is dated earlier than the transaction date, Tax Point Date moves to the earliest fulfillment date. Oracle's rationale is VAT-shaped: jurisdictions that treat fulfillment as a taxable supply. That is not a U.S. sales-tax filing rule.
2. On the transaction, check Override next to Tax Point Date and enter the date manually.
1 Invoice date is September 2, posting period Sep 2026. 2 Tax Point Date is August 28 because the goods had already shipped. The two dates can differ even though the transaction still posts to September.
The Use Tax Point Date preference in Tax Reporting Framework country-report preferences is on by default. The U.S. is not a supported TRF localization, so that preference has no U.S. application.
The U.S. purchase-side exception
Consumer's use tax is the tax you self-assess when a vendor does not charge tax on a taxable purchase. In SuiteTax, that calculation lives in Tax Details too.
On U.S. purchase transactions, NetSuite can show a Calculate Use Tax Automatically checkbox. The checkbox appears on taxable purchase transactions with a U.S. nexus when NetSuite’s SuiteTax Engine is assigned to the transaction subsidiary for that date.
That is NetSuite's own SuiteTax Engine SuiteApp. A nexus pointed at Avalara, Vertex, Sovos, or another engine does not get this box. The calculation uses the Ship To address stored in Location.
1 Location is Dallas, so Texas is the use-tax destination. 2 Calculate Use Tax Automatically is on. The vendor is still paid $3,400; the $280.50 posts to use-tax liability, not to the bill. If you skip the automatic calculation and enter use tax manu
If AP actually needs to accrue use tax, don't make "remember to override it" the process. Use the automatic calculation where it fits, and reserve manual overrides for exceptions.
A 10-minute check for this week
Open five recent invoices and click Tax Details. Confirm the Nexus matches the transaction you think you entered, then check that Tax Details Override is off unless someone can explain why it is on.
Then build a saved search. Transaction Type: Invoice, Cash Sale, Credit Memo, Vendor Bill. Date: this period. Tax Details Override: true. Main Line: true. You're looking for a pattern, not one legitimate exception. On a SuiteTax account, look for Tax Details Override on the Criteria tab. If the Filter list does not show it, use Formula (Text) {taxdetailsoverride} is T. The field will not appear in accounts still on legacy tax.
Field ID is taxdetailsoverride. Engine-calculated use tax will not show up in this search. It only catches transactions where Tax Details Override was turned on. If you see several real-dollar transactions sitting at $0 tax, open them and find out wh
While you're there, check one subsidiary record under Tax Registrations. Look at the effective dates. An expired registration will not appear in Nexus Override and will not be selected by the lookup.
If users type full state names into free-form address fields, either turn free-form states off or enforce the two-letter rule. This is one of those small setup choices that can create "random" untaxed invoices later.
For credit memos, compare the location to the original invoice before anyone edits the lines. If it changed, set Nexus Override back to the original invoice's nexus first.
Bottom line: Same customer does not mean same tax result in SuiteTax. Ship-to, location, registrations, and Tax Point Date can change the outcome before anyone touches a tax code. When something looks wrong, open Tax Details first. Then check whether the nexus was selected correctly and whether anyone overrode the result. The bigger risk is not that SuiteTax is random. It's that someone can freeze the wrong answer and keep moving.If the question is bigger than NetSuite
If Tax Details is showing you something you can’t explain, we can help trace what NetSuite is doing: nexus, registrations, transaction setup, forms, and overrides.
If the bigger question is whether you should be charging tax there in the first place, that’s where The Sales Tax People come in.
They handle the tax side of the equation: nexus reviews, state registrations, monthly filings, VDAs, audit defense, and the automation around all of it.
In other words, we can help make sure NetSuite is following the rules you’ve set up. They can help make sure those are the right rules to begin with.