Oracle NetSuite and TaxJar integration

What moves between them

Sales orders and invoices from NetSuite are polled on a schedule aligned with your order entry cycle. Each transaction is extracted with customer address and line items, then posted to TaxJar for tax calculation. The calculated tax rates flow back into NetSuite custom fields on the invoice record. Customers in NetSuite are also synced to TaxJar to maintain exemption status across both systems. Nexus regions are read from TaxJar periodically to validate that NetSuite tax jurisdictions stay in sync.

How ml-connector handles it

ml-connector manages two credential sets: NetSuite's OAuth2 client certificate is presented on every API call, and tokens are refreshed every 55 minutes to stay within NetSuite's 60-minute window. TaxJar's API Key is sent in the Authorization header on each request. When posting transactions to TaxJar, ml-connector uses the POST-422-to-PUT idempotency pattern per TaxJar's constraints. NetSuite's Event Subscriptions are not used for this flow because they lack HMAC signature validation; polling via SuiteQL ensures every transaction is captured reliably. Tax calculation results are written back to NetSuite via the REST API using the same OAuth2 flow. Nexus regions are fetched from TaxJar weekly and validated against NetSuite's active locations to flag any gaps. Every record is logged with full audit trail, and failed postings can be retried by querying the audit log and re-submitting.

A real-world example

A mid-sized e-commerce and wholesale company sells into 12 US states and Canada through NetSuite. Before the integration, the finance team manually entered tax rates based on customer location and order type, then reconciled tax collected against tax reported to each state. With NetSuite and TaxJar connected, every invoice NetSuite creates immediately gets the correct tax calculation based on real-time rates, and the nexus tracking in TaxJar flags when the company expands to a new state so the tax team can register and file proactively. Tax reporting to each state is now driven directly from auditable NetSuite invoice records.

What you can do

• •Calculate sales tax in real time when NetSuite invoices are created, using TaxJar's current rates for the customer location.
• •Automatically sync NetSuite customers and exemption flags to TaxJar to maintain consistent tax exemption rules.
• •Track tax nexus regions from TaxJar and validate that NetSuite locations and tax jurisdictions stay aligned.
• •Manage NetSuite OAuth2 token refresh automatically, and handle TaxJar's POST-422-to-PUT idempotency constraint transparently.
• •Audit every transaction and tax calculation with a full replay trail, so failed postings can be corrected and resubmitted without data loss.

Questions

How does ml-connector handle NetSuite's 60-minute OAuth2 token window?

ml-connector refreshes the OAuth2 token every 55 minutes, staying safely within NetSuite's window and ensuring no request fails due to token expiry. The M2M flow does not include a refresh token, so each new credential call requests a fresh access token.

Why does ml-connector poll NetSuite instead of using Event Subscriptions?

NetSuite Event Subscriptions lack native HMAC signature validation, which increases the security burden for webhook endpoints. Polling via SuiteQL gives ml-connector full control over signature validation, retry logic, and audit trails without relying on NetSuite's webhook retry mechanism.

What happens if TaxJar returns a 422 when posting a transaction?

A 422 on POST means the transaction already exists in TaxJar. ml-connector automatically falls back to a PUT request to update the existing record. If the PUT returns 404, the record was deleted, and ml-connector falls back to POST to recreate it, ensuring idempotency without retry loops.