Odoo and TaxJar integration

What moves between them

Sales transactions flow from Odoo to TaxJar. ml-connector polls Odoo sales orders and invoices on a schedule, submitting each to TaxJar's /v2/transactions endpoint for real-time tax calculation based on customer location and nexus rules. TaxJar returns the computed tax amount per jurisdiction, which ml-connector writes back into Odoo's account.move.line records as sales tax payable. Tax rates are also polled from TaxJar to validate addresses and verify tax exposure across customer locations. Reference data such as customer exemption types flows into TaxJar's customer endpoint. No data moves from TaxJar back to Odoo except tax calculations and nexus summaries.

How ml-connector handles it

ml-connector stores both the Odoo API key and TaxJar token encrypted and uses Odoo's high-water-mark filtering (write_date greater than last sync timestamp) to identify new and modified transactions. Each Odoo sales order or invoice is mapped to a TaxJar /v2/transactions POST with line items, ship_to address, customer location, and exemption_type if present. TaxJar returns tax rates and amounts per jurisdiction; ml-connector records these in Odoo's account.move.line table against the appropriate sales tax liability accounts. Because TaxJar uses an idempotency workaround (422 on duplicate means retry as PUT), ml-connector includes order IDs in the external_id field and implements the retry logic per TaxJar's documented pattern. Tax rate lookups use TaxJar's /v2/rates endpoint to validate addresses before submission. ml-connector respects Odoo's record-level access rules and applies the transaction API's default transaction categorization so tax is calculated according to nexus and exemption status.

A real-world example

A mid-sized B2B wholesale distributor runs Odoo for order management and accounting across three regional warehouses and multiple sales channels. Previously, the finance team exported invoice data from Odoo twice a month, manually ran each transaction through TaxJar to calculate resale tax and nexus liability, and re-entered the amounts into the general ledger. With Odoo and TaxJar connected, each sales order syncs to TaxJar automatically as it ships, tax is calculated in real-time based on customer location and exemption status, and the liability amounts post directly into Odoo's tax accounts. The company now submits filing-ready data to TaxJar continuously, eliminating the monthly export-recalculate-reenter cycle and reducing month-end close time for the tax reconciliation step.

What you can do

• •Read Odoo sales orders and invoices via polling, submit each to TaxJar for real-time tax calculation based on customer location and nexus rules.
• •Write computed tax amounts from TaxJar back into Odoo's account.move.line records against the correct sales tax payable accounts.
• •Validate customer exemption types in TaxJar and sync exemption status back into Odoo customer records for future orders.
• •Authenticate Odoo with API key auth and Odoo's multi-tenant base URLs, and TaxJar with Bearer token authentication, managing both credential sets encrypted.
• •Poll on a regular schedule with high-water-mark filtering to capture only changed transactions, implement idempotency retries per TaxJar's documented pattern, and maintain a full audit trail of every submission and response.

Questions

Which direction does data move between Odoo and TaxJar?

The main flow is Odoo to TaxJar. Sales orders, invoices, and customer records move from Odoo to TaxJar for tax calculation and nexus tracking. Tax amounts, rates, and exemption status flow back from TaxJar into Odoo's accounting records. TaxJar is read-mostly for reference data such as rates and nexus regions, which ml-connector polls periodically to keep customer location data validated.

How does ml-connector handle Odoo's multiple deployment options (Online, .sh, self-hosted)?

ml-connector accepts each Odoo customer's base URL during setup, since Odoo Online, Odoo.sh, and self-hosted editions each publish different base URLs. The API key and username are stored encrypted per customer, and the API calls are routed to the appropriate instance. This allows ml-connector to support any Odoo deployment flavor in the same integration flow.

What happens if a transaction fails to submit to TaxJar or TaxJar returns an error?

ml-connector uses a high-water-mark timestamp to track the last successful poll, so failed transactions are retried in the next sync cycle without reprocessing older data. If TaxJar returns a 422 conflict (transaction exists), ml-connector follows TaxJar's documented idempotency pattern by falling back to a PUT request. All submissions and errors are logged in the audit trail so you can replay failed records once the issue is resolved.