SYSPRO and TaxJar integration

What moves between them

The main flow moves from SYSPRO into TaxJar. ml-connector polls SYSPRO OData on a schedule (typically every 5 to 15 minutes) for new or updated sales orders and invoices, extracts customer address, order lines, and totals, and submits them to TaxJar as transactions for tax calculation and state reporting. TaxJar does not push data back into SYSPRO, so the flow is one-way. Nexus regions and tax rates are retrieved from TaxJar on demand when needed for reference. Customer exemption data and tax category mappings are stored in ml-connector and applied during transformation.

How ml-connector handles it

ml-connector stores both the SYSPRO OData credentials and the TaxJar API token encrypted and presents the token on every TaxJar request using the Authorization Bearer header. It polls SYSPRO OData tables (ArInvoice, PorMasterHdr, ArCustomer) with $filter on timestamp fields such as InvoiceDate and PostDate, extracts line items and shipping addresses, and batches them into transaction payloads. Before posting to TaxJar, ml-connector looks up the transaction ID in the audit log to avoid duplicate tax calculations (idempotency fallback: if POST returns 422 exists, it falls back to PUT). Rate limits and token expiry are handled with exponential backoff and retry. Each transaction is audited with a record of what was sent, what TaxJar returned, and when, so failed calls can be replayed without re-entering data into SYSPRO.

A real-world example

A mid-sized maker and distributor runs SYSPRO for manufacturing, procurement, and order fulfillment across multiple regional warehouses, and uses TaxJar to manage sales tax across 15 states and multiple local jurisdictions. Before the integration, order fulfillment sent invoices to the finance team, who manually looked up tax rates by customer state and jurisdiction, calculated tax by hand, and entered the totals into TaxJar for state reporting. With SYSPRO and TaxJar connected, each new order from SYSPRO automatically flows to TaxJar, tax is calculated in real time, and state reporting feeds are generated automatically. The manual tax lookup step disappears, and the company stays current with every state and local rate change without re-entering data.

What you can do

• •Poll sales orders and invoices from SYSPRO OData and post them to TaxJar for tax calculation and state reporting.
• •Transform SYSPRO order data (customer address, line items, totals) into transaction format that TaxJar accepts.
• •Authenticate SYSPRO with HTTP Basic Auth on OData and TaxJar with API token authentication on every call.
• •Deduplicate tax calculations by transaction ID so the same order is never sent to TaxJar twice, with automatic retry on transient failures.
• •Track every transaction posted to TaxJar in an audit log with timestamps and response details for compliance and replay.

Questions

Which direction does data move between SYSPRO and TaxJar?

The flow is one-way, from SYSPRO into TaxJar. Sales orders and invoices move from SYSPRO to TaxJar so tax is calculated and state reporting feeds are populated. TaxJar does not push data back into SYSPRO, though nexus regions and rates can be retrieved from TaxJar on demand for reference.

How does ml-connector handle SYSPRO's polling requirement and OData read-only constraint?

ml-connector polls SYSPRO OData tables on a schedule (typically every 5 to 15 minutes) for new or updated orders and invoices using filters on timestamp fields. Because OData is read-only, ml-connector never writes back to SYSPRO; all data flows in one direction to TaxJar.

How does the integration prevent duplicate tax calculations in TaxJar?

ml-connector uses transaction IDs from SYSPRO invoices as idempotency keys, and checks the audit log before posting to TaxJar. If the same transaction is seen again, it is skipped. If TaxJar returns a 422 (exists) error, ml-connector falls back to PUT to update the transaction instead of creating a duplicate.