IFS Cloud and Avalara integration

What moves between them

The flow runs from IFS Cloud into Avalara. When a customer order or sales invoice is posted in IFS Cloud, ml-connector reads the transaction (customer, address, line items, amounts) and submits it to Avalara for tax calculation. Avalara returns calculated tax by jurisdiction. ml-connector then creates a corresponding tax GL voucher in IFS Cloud, posting the tax amounts to the correct tax liability accounts by jurisdiction and company code. Line-item details and the original transaction reference are preserved so reconciliation is automatic.

How ml-connector handles it

ml-connector handles the two different authentication schemes: OAuth 2.0 Client Credentials on IFS Cloud (storing and rotating tokens every 60 minutes) and HTTP Basic Authentication on Avalara (using a stored Account ID and License Key that persist across password changes). On IFS Cloud, it queries customer orders and sales invoices using OData filters on created/modified timestamps, pages through results in batches under the 5000-element limit, and reads the If-Match ETag from each transaction before attempting mutations. When submitting to Avalara, it constructs the tax request with customer address, line items, and amounts, uses the IFS transaction number as the Avalara document code for idempotency, and handles Avalara's DocumentCodeConflict response by treating it as a successful prior submission (idempotent). After Avalara returns calculated tax, ml-connector uses the IFS OData projection for vouchers to create the corresponding GL entry, mapping tax totals by jurisdiction to the appropriate tax GL accounts in the customer's chart of accounts. Company code is always included per IFS requirements. Polling frequency is tunable per customer; reconciliation queries use $filter on posted date and reconciliation status to find unmatched transactions.

A real-world example

A mid-sized manufacturing and distribution company runs IFS Cloud for ERP and sells across three US states and one Canadian province. Before the integration, the finance team manually looked up tax rates for each order, sometimes using outdated jurisdiction tables, and re-entered calculated tax into IFS Cloud at month-end, creating reconciliation errors and month-end delays. With IFS Cloud and Avalara connected, each order posted to IFS Cloud is instantly submitted for tax calculation. Avalara returns the correct tax by state or province, and ml-connector writes it back to IFS Cloud's GL as a tax liability entry. The finance team no longer re-keys tax; the GL is always current, and month-end close is compressed by two days.

What you can do

• •Submit sales transactions from IFS Cloud to Avalara in real time and return calculated tax by jurisdiction.
• •Post tax GL vouchers back into IFS Cloud with amounts correctly allocated to tax liability accounts per company code.
• •Use IFS Cloud's OData API with proper ETag / If-Match handling and pagination within the 5000-element limit.
• •Authenticate IFS Cloud with OAuth 2.0 client credentials (token rotation every 60 minutes) and Avalara with HTTP Basic Auth.
• •Handle Avalara's document code idempotency so resubmitting a transaction for recalculation does not create duplicate GL entries.

Questions

How does ml-connector handle the two different authentication methods?

IFS Cloud uses OAuth 2.0 Client Credentials; ml-connector stores the client_id and client_secret encrypted, obtains a token at startup and every 60 minutes before expiry, and includes it as a Bearer token on every OData call. Avalara uses HTTP Basic Auth with Account ID and License Key; ml-connector stores these encrypted and Base64-encodes them on every request. The License Key does not expire on password change, so it is stable for connectors.

What happens if an IFS Cloud transaction is resubmitted to Avalara for recalculation?

ml-connector uses the IFS transaction number as the Avalara document code. If the same document code is resubmitted, Avalara returns a DocumentCodeConflict error, which ml-connector treats as a successful idempotent operation (the transaction was already calculated). This prevents duplicate GL entries in IFS Cloud even if a transaction is recalculated or manually retried.

How does ml-connector handle IFS Cloud's 5000-element result limit and ETag requirement for mutations?

When querying OData entities, ml-connector uses $filter on created/modified timestamps and $skip/$top pagination to keep result sets under 5000 elements per request. Before mutating any record (posting a tax GL voucher), it reads the If-Match ETag from the transaction, then includes that ETag in the PATCH or POST request to enforce optimistic concurrency and prevent write conflicts.