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.
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
More Infor CloudSuite integrations
Other systems that connect to Avalara
Connect Infor CloudSuite and Avalara
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started