Tax compliance is the integration requirement that teams underscope in design, overengineer in implementation, and then get wrong in subtle ways that create audit risk. The mistakes are consistent across implementations and almost all of them are preventable with the right decisions made before coding starts.
The Two Tax Calculation Architectures
There are two approaches to tax calculation in a WooCommerce + NetSuite integration:
- Calculate in WooCommerce, pass to NetSuite: WooCommerce (or a WooCommerce tax plugin) calculates tax at checkout. The tax amount is passed to NetSuite as a line item. NetSuite stores the amount but does not recalculate it.
- Calculate in NetSuite: WooCommerce passes the taxable amount and location. NetSuite applies its tax schedule and calculates the tax amount on the sales order.
Each architecture has a different failure mode. Calculate-in-WooCommerce fails when the WooCommerce tax tables are out of date or when a tax jurisdiction change is applied to WooCommerce but not reflected in the amounts passed to NetSuite. Calculate-in-NetSuite fails when the NetSuite tax schedules do not match the tax treatment applied at checkout, producing an order where the customer paid one amount and the sales order reflects a different amount.
The architecturally cleaner approach for audit purposes is a single source of truth for tax calculation. Which system that is depends on where your tax compliance tooling (Avalara, TaxJar, or native NetSuite tax) is licensed and maintained.
Destination-Based vs Origin-Based Sourcing
US sales tax sourcing rules vary by state: some states require destination-based sourcing (tax rate of the buyer’s location), others use origin-based sourcing (tax rate of the seller’s location). WooCommerce and NetSuite both support both models, but they must be configured consistently. An integration that passes a destination address to a NetSuite account configured for origin-based sourcing will calculate the wrong tax on every out-of-state order.
International VAT: The Threshold Problem
EU VAT OSS (One-Stop Shop) thresholds, UK VAT registration thresholds, and similar regimes in other markets mean that tax treatment may change mid-year as a merchant crosses a threshold. Integrations that hard-code tax treatment for a market — always charge VAT to UK customers, or never charge VAT — will be wrong in at least one direction.
The correct integration architecture makes tax treatment a configuration value, not a code constant. When the tax position changes, the configuration changes — not the code. This is a design decision that needs to be made before implementation, because retrofitting configurable tax treatment into an integration built with hard-coded rules is a significant rework.