Oracle JD Edwards and Avalara integration

What moves between them

The flow runs from Oracle JD Edwards into Avalara. ml-connector polls posted sales and purchase documents from JD Edwards through the AIS data service and posts each one to AvaTax as a SalesInvoice or PurchaseInvoice transaction for tax calculation and recording. Customer records move the same direction to support exemption tracking, and item records carry their tax codes so each line is classified correctly. Cadence follows a schedule you set, typically aligned to your posting cycle, because neither system pushes events. Avalara holds no vendor, GL, or payment data, so ml-connector never writes financial entries back into JD Edwards.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the JD Edwards side it accepts the full AIS Server URL, JDE username and password, environment, and role per customer, requests a session token, and renews it when AIS returns HTTP 444 for an invalid token, which happens whenever the AIS Server restarts. On the Avalara side it sends the account ID and license key as HTTP Basic auth and selects the sandbox or production host by environment. Because neither side has webhooks, it polls JD Edwards tables on a date filter and tracks the last-polled timestamp between runs. Each JDE document number becomes the Avalara transaction code, so a retried post uses createOrAdjust to update the same uncommitted transaction rather than create a duplicate; once a transaction is committed its code is reserved. Item tax codes and customer codes are mapped first so every line carries a valid tax code and addresses are resolved before calculation. AIS uses an IP allowlist, so the connector's egress addresses must be added or calls return HTTP 405, and Avalara returns HTTP 429 when rate limited, so the connector backs off and retries. Every record carries a full audit trail and can be replayed if a post fails.

A real-world example

A mid-sized industrial distributor runs Oracle JD Edwards EnterpriseOne for procurement, inventory, and finance, and sells into a dozen states with mixed taxability. Before the integration, staff looked up tax rates by hand and keyed them onto sales invoices, and the use tax on inbound purchases was estimated at month-end, which drew questions in every audit. With Oracle JD Edwards and Avalara connected, each posted sales document is sent to AvaTax for an exact rate by jurisdiction, purchase invoices are sent as PurchaseInvoice transactions so use tax is self-assessed automatically, and exemption certificates tie to the right customers. The manual rate lookups stop and the tax position is consistent and defensible.

What you can do

• •Send posted Oracle JD Edwards sales documents to Avalara as SalesInvoice transactions for exact tax by jurisdiction.
• •Send JD Edwards purchase documents as PurchaseInvoice transactions so use tax is self-assessed automatically.
• •Sync JD Edwards customers and items so exemption status and Avalara tax codes line up with your ledger.
• •Bridge the JD Edwards AIS session token, renewed on an invalid-token response, and Avalara HTTP Basic account ID and license key.
• •Use each JDE document number as the Avalara transaction code so a retry updates the same record instead of duplicating it.

Questions

Which direction does data move between Oracle JD Edwards and Avalara?

The flow runs from Oracle JD Edwards into Avalara. Posted sales and purchase documents, customers, and items move from JD Edwards into AvaTax for tax calculation and recording. Avalara holds no vendor, GL, or payment objects, so ml-connector does not write financial entries back into JD Edwards.

How does the integration handle JD Edwards having no webhooks?

JD Edwards EnterpriseOne does not push events to an external endpoint, so ml-connector polls the AIS data-service tables on a date filter and tracks the last-polled timestamp between runs. Avalara is also pull-only, which fits this design since the ERP is the trigger. Polling runs on a schedule you set, typically aligned to your posting cycle.

What stops a retried document from creating a duplicate tax record?

ml-connector uses each JD Edwards document number as the Avalara transaction code, which AvaTax treats as the idempotency key. A retry on an uncommitted transaction uses createOrAdjust to update the same record in place rather than create a new one. Once a transaction is committed its code is reserved, so the connector adjusts or voids instead of reposting.