Sage 100 and Avalara integration

What moves between them

The main flow runs from Sage 100 into Avalara. As sales orders and AR invoices are created or updated in Sage 100, ml-connector reads them through the agent and posts each one to AvaTax as a transaction to calculate tax, then writes the returned tax amount back onto the Sage 100 document. AP invoices can be sent as PurchaseInvoice transactions so AvaTax self-assesses use tax. Customers and inventory items move the same direction so AvaTax has the customer codes for exemption certificates and the tax codes for each product. Committed sales stay recorded in AvaTax for return filing, and AvaTax is treated as the system of record for tax, so ml-connector does not write accounting entries back from it.

How ml-connector handles it

ml-connector stores both credential sets encrypted, calls the Sage 100 agent with its API key, and sends the AvaTax account ID and license key as a Basic auth header on every request, switching the sandbox base URL for production once live credentials are in place. Because Sage 100 has no webhooks, it polls the agent on a schedule using DateLastUpdated and document dates, scoped to the company code, rather than waiting for a push. Each Sage 100 document number becomes the AvaTax transaction code, and ml-connector uses createOrAdjust so an uncommitted transaction is updated in place and a retry never records tax twice. Customers map to AvaTax customer codes and Sage 100 items map to AvaTax tax codes so each line is classified correctly, and segmented Sage 100 GL accounts are parsed defensively. AvaTax rate limits return HTTP 429 with no Retry-After header, so ml-connector backs off with jitter and retries, and a committed AvaTax code cannot be reused, so a change to a posted document is handled by void and re-create rather than overwrite. Every record carries a full audit trail and can be replayed if a call fails.

A real-world example

A regional building-materials distributor with about 120 staff runs Sage 100 on a server at its main warehouse and ships to contractors across several states. Before the integration, the AR clerk looked up tax rates by hand and kept rate tables in a spreadsheet, which drifted out of date and produced under- and over-charges that surfaced during state audits, while exemption certificates for tax-exempt contractors were tracked in a filing cabinet. With Sage 100 and Avalara connected, every sales order is priced with the exact rate for the ship-to address the moment it is entered, exempt customers are matched to their AvaTax certificates automatically, and committed invoices are already recorded in Avalara when returns come due. The spreadsheet is gone and audit exposure drops.

What you can do

• •Calculate live sales tax on Sage 100 sales orders and AR invoices using the ship-to address, and write the result back onto the document.
• •Send Sage 100 AP invoices to AvaTax as purchase transactions so use tax is self-assessed.
• •Map Sage 100 customers to AvaTax customer codes and items to AvaTax tax codes so every line is classified correctly.
• •Bridge the Sage 100 local-agent API key and AvaTax HTTP Basic auth, using each document number as the AvaTax code for safe retries.
• •Poll Sage 100 on a schedule, because it has no webhooks, with backoff on AvaTax rate limits and a full audit trail on every record.

Questions

Which direction does data move between Sage 100 and Avalara?

The main flow is Sage 100 into Avalara. Sales orders, AR invoices, AP invoices, customers, and items move from Sage 100 to AvaTax, and the calculated tax is written back onto the Sage 100 document. AvaTax is the system of record for tax, so ml-connector does not push accounting entries back into Sage 100 from it.

How does the integration reach Sage 100 if it has no cloud API?

Sage 100 is on-premises and its full accounting model is only reachable through the Business Object Interface, which runs as COM on the server. A local Windows agent on the customer server wraps that interface and exposes an HTTPS endpoint, and ml-connector calls the agent with an API key. The narrow SOAP surface covers only Sales Orders and Customers, so the agent is required for AP and GL data.

How are duplicate tax records avoided when a document is retried?

ml-connector uses each Sage 100 document number as the AvaTax transaction code and submits through createOrAdjust, so an uncommitted transaction is updated in place rather than duplicated. Because Sage 100 has no webhooks, records are read by polling, and a committed AvaTax code cannot be reused, so a change to a posted document is handled by void and re-create.