Microsoft Dynamics GP and Avalara integration

What moves between them

The main flow runs from Microsoft Dynamics GP into Avalara. ml-connector polls GP receivables and payables invoices by ModifiedDate, sends each as an AvaTax SalesInvoice or PurchaseInvoice transaction keyed by the GP document number, and writes the returned tax amount back onto the GP document. GP customers and items are pushed to AvaTax as customer and item records, with GP tax schedule and exemption data mapped to AvaTax customer codes, item codes, and tax codes so taxability resolves correctly. The cadence follows your GP posting schedule. AvaTax holds no GL or vendor data, so ml-connector never writes accounting entries back into AvaTax.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the GP side it presents Windows credentials over Negotiate or NTLM to the customer-supplied SBA or SOAP URL, since GP publishes no shared base address and must be reachable through the firewall or a local agent; the companyName it uses is the SQL database name, not the display name. On the AvaTax side it sends the Account ID and License Key as HTTP Basic auth on every call. Because GP has no webhooks, it polls invoices, customers, and items on a schedule rather than waiting for a push. Each GP document number becomes the AvaTax transaction code, and ml-connector uses CreateOrAdjustTransaction so a re-sent invoice updates in place instead of duplicating. Tax only writes back to unposted GP documents, since posted records are read-only through the API. AvaTax returns HTTP 429 when rate limited and publishes no Retry-After header, so ml-connector backs off with jitter and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized building-products distributor running Microsoft Dynamics GP sells into a dozen states and self-assesses use tax on equipment purchases. Before the integration, accounting kept GP tax schedules current by hand, missed rate changes in newer jurisdictions, and re-keyed exemption certificate status from a spreadsheet, which produced both over- and under-charged tax and slow, error-prone month-end reconciliation. With Microsoft Dynamics GP connected to Avalara, every sales and purchase invoice is priced for tax at the correct rate the moment it is entered, exemptions resolve from the synced customer records, and the calculated tax lands back on the GP document automatically. The team stops maintaining tax tables and closes the period with tax already reconciled.

What you can do

• •Calculate jurisdiction-accurate sales and use tax on Microsoft Dynamics GP invoices through Avalara and write the result back onto the GP document.
• •Send GP receivables and payables invoices to Avalara as SalesInvoice and PurchaseInvoice transactions keyed by the GP document number.
• •Keep GP customers and items aligned with Avalara customer, item, and tax code records so exemptions and taxability resolve correctly.
• •Bridge GP Windows authentication and the Avalara Account ID and License Key, including the customer-specific GP server URL.
• •Poll GP on your posting schedule, with idempotent transaction codes, backoff on rate limits, and a full audit trail and replay on every record.

Questions

Which direction does data move between Microsoft Dynamics GP and Avalara?

The main flow is GP into Avalara. Invoices, customers, and items move from GP to AvaTax, and the calculated tax is written back onto the GP document. AvaTax has no GL or vendor objects, so ml-connector does not post accounting entries into AvaTax.

How does the integration connect on-premises GP to cloud AvaTax?

GP runs on the customer's own server with no shared cloud endpoint, so ml-connector calls a customer-supplied SBA or SOAP URL that is reachable through the firewall or a local agent, using Windows credentials. AvaTax is reached at its fixed REST v2 URL with HTTP Basic auth from the Account ID and License Key. ml-connector stores both credential sets encrypted and bridges them on each sync.

Will sending the same invoice twice create a duplicate tax transaction?

No. ml-connector uses the GP document number as the AvaTax transaction code and submits through CreateOrAdjustTransaction, so a re-sent invoice updates the existing transaction instead of creating a second one. Tax is only written back to unposted GP documents, because posted records are read-only through the GP API.