ml-connector
Infor CloudSuiteAvalara

Infor CloudSuite and Avalara integration

Infor CloudSuite runs ERP and finance. Avalara AvaTax calculates sales and use tax across jurisdictions. Connecting the two means every sales invoice and AP purchase document gets the right tax without anyone looking up rates by hand. ml-connector reads the document from Infor, sends its addresses and line items to AvaTax for calculation, and writes the returned tax back onto the Infor record. Customer and item data is kept aligned so exemption certificates and tax codes resolve the way Avalara expects.

How Infor CloudSuite works

Infor CloudSuite exposes suppliers, supplier invoices, purchase orders, customers, items, and GL accounts through the Infor ION API Gateway. M3 sites use m3api-rest transaction programs such as CRS610MI for customers, MMS200MI for items, and APS100MI for supplier invoices; SyteLine uses IDO REST; LN and FSM use a mix of REST and BOD messages. Every customer has a unique gateway URL, tenant ID, and OAuth2 token endpoint supplied in a .ionapi file, and access tokens expire in one to twenty-four hours. Infor has no self-service webhooks for cloud connectors, so records are read by polling the REST programs or by an admin-configured ION Desk document flow.

How Avalara works

Avalara AvaTax REST v2 is a tax calculation service, not an ERP, so it holds no vendors, purchase orders, payments, or GL accounts. Its central object is the Transaction, created with POST /api/v2/transactions, where the document type, customer code, addresses, and line items are sent and the full calculated tax is returned inline in the same synchronous response. It also stores Companies, Customers, Items, TaxCodes, and exemption Certificates, and validates addresses through /addresses/resolve. Authentication is HTTP Basic with an account ID and license key, and AvaTax never pushes events, so any reconciliation is done by polling ListTransactionsByCompany.

What moves between them

The main flow runs from Infor CloudSuite into Avalara and back. When a sales invoice or AP purchase document is read from Infor, ml-connector posts it to AvaTax as a SalesInvoice or PurchaseInvoice, then writes the calculated tax amount back onto the Infor document. Customer records and item catalogs move from Infor into Avalara so each transaction line references a customer code, item code, and tax code that Avalara recognizes, which is also where exemption certificates attach. Calculation is synchronous, so tax comes back on the same call, and a scheduled poll of ListTransactionsByCompany reconciles what Avalara has recorded against the Infor ledger. Avalara holds no GL accounts or vendors, so ml-connector never writes accounting structure into AvaTax.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It authenticates to Infor with the OAuth2 password grant built from the .ionapi file fields, accepts the full tenant gateway URL per customer since Infor publishes no shared base address, and refreshes the bearer token before its one to twenty-four hour lifetime expires rather than reacting to a 401. To Avalara it sends the HTTP Basic header built from the account ID and license key on every call. Infor sales and purchase documents are read by polling because Infor has no self-service webhook, and AvaTax has no webhook either, so neither side pushes. Each document maps to an AvaTax transaction: the customer becomes customerCode, the line item becomes itemCode with a taxCode, and ship-from and ship-to addresses are validated through /addresses/resolve first, since an invalid address fails calculation. The Infor document number is used as the AvaTax document code for idempotency, and ml-connector uses CreateOrAdjustTransaction so a safe retry updates the transaction in place instead of creating a duplicate; Infor itself has no idempotency key, so a query-before-write check guards the tax write-back. A committed AvaTax transaction cannot be overwritten, so a corrected Infor invoice triggers a void and re-create. Avalara rate limits return HTTP 429, and ml-connector backs off and retries.

A real-world example

A mid-sized distributor running Infor CloudSuite Distribution ships products to customers across many states and also self-assesses use tax on equipment it buys. Before the integration, the AP and billing team looked up tax rates by jurisdiction and typed them onto invoices by hand, which meant wrong rates on out-of-state orders and missed exemptions for resale customers. With Infor CloudSuite and Avalara connected, each invoice is sent to AvaTax the moment it is read, the correct jurisdiction tax comes back and is written onto the Infor document, and resale customers are matched to their exemption certificates automatically. The team stops looking up rates, and the numbers that feed the tax return are calculated consistently.

What you can do

  • Calculate jurisdiction sales tax on Infor CloudSuite sales invoices through AvaTax and write the result back onto the Infor document.
  • Self-assess use tax on Infor AP purchase documents by posting them to AvaTax as PurchaseInvoice transactions.
  • Sync Infor customers and items into Avalara so tax codes and exemption certificates resolve on every transaction line.
  • Validate ship-from and ship-to addresses through AvaTax before calculation so bad addresses do not break tax.
  • Authenticate Infor with its tenant-specific OAuth2 token and Avalara with its account ID and license key, with retries on every call.

Questions

Which direction does data move between Infor CloudSuite and Avalara?
Sales and purchase documents move from Infor CloudSuite into Avalara for tax calculation, and the calculated tax is written back onto the matching Infor document. Customers and items also move from Infor into Avalara so transaction lines resolve correctly. Avalara holds no GL accounts or vendor master, so ml-connector never writes accounting structure back into AvaTax.
Does Avalara store the invoices and customers, or just calculate tax?
AvaTax is a tax calculation service, not an ERP. It records the transaction it calculated and keeps Companies, Customers, Items, TaxCodes, and exemption Certificates, but it has no vendors, purchase orders, payments, or general ledger. Your invoices and accounting stay in Infor CloudSuite, and AvaTax receives the addresses and line items it needs to return the tax.
How does the integration handle retries and corrections without duplicating tax?
ml-connector uses the Infor document number as the AvaTax document code and calls CreateOrAdjustTransaction, so re-sending the same document updates it in place rather than creating a duplicate. Once an AvaTax transaction is committed its code is locked, so a corrected Infor invoice triggers a void and re-create. On the Infor side there is no idempotency key, so a query-before-write check prevents posting the tax twice, and a 429 from Avalara is retried with backoff.

Related integrations

Connect Infor CloudSuite and Avalara

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started