Microsoft Dynamics GP and TaxJar integration

What moves between them

The main flow is from Microsoft Dynamics GP into TaxJar. ml-connector polls GP at a configurable interval (typically once per business day or per invoice batch) for receivables invoices in Open or Historical status. For each invoice, it extracts the customer, invoice date, line items with amounts, shipping, and delivery address. It posts each transaction to TaxJar's /transactions/orders endpoint to calculate sales tax and register the transaction for state reporting. If a transaction already exists (422 conflict), the integration falls back to PUT to update it. Customer exemption status in TaxJar takes precedence over order-level exemptions, allowing merchants to manage blanket exemptions from the TaxJar dashboard. Nexus regions are polled periodically (monthly or per subscription change) to validate that tax calculation reflects the merchant's current filing obligations.

How ml-connector handles it

ml-connector stores the GP user's Windows domain credentials encrypted and presents them on each SBA or SOAP call, validating the tenant name and company database name per customer. TaxJar API tokens are stored separately and presented as bearer tokens. Because GP does not publish ModifiedDate fields uniformly, the adapter polls based on invoice status (transitioning from Work to Open) and fetches the full invoice record including line items and GL account mappings. The integration runs on a schedule aligned with invoice posting cycles in GP, not real-time, since GP offers no push mechanism. Tax rates are calculated in real time on TaxJar's side; the integration does not cache or estimate. For sandbox testing, separate sandbox credentials and tokens are used on both sides, allowing merchants to validate the integration end-to-end before sending live transactions to tax authorities. If a TaxJar request fails or times out, the integration logs the failure with the invoice key and retries the next polling cycle. All transaction records carry a full audit trail including the original invoice, the calculated tax, the state reporting status, and any exemptions applied.

A real-world example

A mid-market distributor with offices in California, Texas, and New York uses Dynamics GP to manage receivables and invoices across all three locations. Previously, the accounting team exported invoices from GP, manually looked up tax rates for each state and shipping destination, entered the tax in a spreadsheet, and uploaded the completed list to the TaxJar dashboard weekly. This process was slow, error-prone, and created a lag between invoice posting and tax reporting. With Dynamics GP and TaxJar connected, each invoice posted to GP automatically flows to TaxJar, the correct tax is calculated based on the ship-to address, the transaction is registered immediately for state filing, and the team has visibility into nexus and filing obligations in real time. Month-end tax reconciliation is now automated.

What you can do

• •Poll Dynamics GP receivables invoices and post completed transactions to TaxJar for sales tax calculation and nexus tracking.
• •Calculate accurate sales tax rates based on customer ship-to address, handling multi-state filing obligations.
• •Manage customer-level tax exemptions in TaxJar, with exemption status applying across all transactions for that customer.
• •Validate addresses before posting transactions and use TaxJar's address validation to prevent incorrect tax calculations.
• •Maintain a full audit trail of every invoice, calculated tax, and state filing status, with retry and replay on failure.

Questions

Which direction does data move between Dynamics GP and TaxJar?

The main flow is from Dynamics GP into TaxJar. ml-connector polls receivables invoices from GP and posts completed transactions to TaxJar for tax calculation and state reporting. Nexus regions are polled periodically from TaxJar so merchants can validate their filing obligations. Tax rates are read-only in TaxJar; the integration does not write rates back to GP.

How does the integration handle Dynamics GP's Windows domain authentication and lack of webhooks?

ml-connector stores the GP user's domain credentials encrypted and presents them on each REST or SOAP call. Because GP offers no webhooks or push notifications, the integration polls for invoices on a schedule aligned with your invoice posting cycle, using invoice status transitions and ModifiedDate filters where available. Sandbox testing uses separate test credentials and invoices on both sides.

What happens if a transaction already exists in TaxJar when the integration tries to post it?

TaxJar returns a 422 conflict error if the transaction key already exists. ml-connector automatically falls back to a PUT request to update the transaction with any changed details. If the PUT returns a 404 (transaction was deleted), the integration retries the POST. This idempotency pattern prevents duplicate reporting to tax authorities.