Oracle E-Business Suite and Avalara integration

What moves between them

The main flow runs from Oracle E-Business Suite into Avalara. ml-connector polls EBS AP and AR invoice lines as they post and sends each as an Avalara PurchaseInvoice or SalesInvoice transaction, with ship-from and ship-to addresses, line amounts, and tax codes, to get jurisdiction-accurate tax. EBS customers and items are pushed to Avalara as customer codes and tax-code assignments so determinations and exemptions are correct. The calculated tax returns to EBS and is written into the invoice interface where a write service is deployed; where it is not, the result is recorded for review. Avalara holds no GL or vendor master, so no accounting records flow back out of it.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Oracle E-Business Suite it accepts the full instance base URL per customer, logs in for a session token, and attaches the responsibility and operating unit org ID context to every call, re-authenticating when EBS returns 401 on session timeout. For Avalara it builds the Basic Auth header from the account ID and license key and selects the sandbox or production host by environment. EBS invoice lines map to AvaTax transaction lines, and the EBS invoice number becomes the AvaTax document code, so CreateOrAdjustTransaction updates an uncommitted transaction in place rather than duplicating. Because neither system pushes events, EBS is polled on LAST_UPDATE_DATE at a cadence you set, and AvaTax is queried only to reconcile. EBS has no rate limiter, so calls run at low concurrency on an off-peak window to protect the shared instance, while Avalara 429 responses get exponential backoff with jitter. Two gotchas are handled directly: an EBS invoice write is an asynchronous interface insert that a concurrent program must import, so a 200 is confirmed against the base table; and a committed AvaTax document code cannot be reused, so a correction is voided and re-created.

A real-world example

A mid-sized industrial distributor runs Oracle E-Business Suite R12.2 for purchasing, payables, and receivables across operating units in several US states. Before the integration, staff calculated use tax on supplier invoices by hand and applied sales tax to customer invoices from spreadsheets, which produced wrong rates as jurisdictions changed and left gaps that surfaced during audits. With Oracle E-Business Suite and Avalara connected, each AP and AR invoice line is sent to AvaTax as it posts, the right rate is returned for the exact ship-to address, and exempt customers are honored from their certificates. Tax is consistent across operating units, and audit support comes from AvaTax's transaction record instead of a binder of spreadsheets.

What you can do

• •Calculate jurisdiction-accurate sales and use tax on Oracle E-Business Suite AP and AR invoices as they post.
• •Send EBS invoice lines to Avalara as PurchaseInvoice and SalesInvoice transactions keyed on the EBS invoice number.
• •Sync EBS customers and items to Avalara customer codes and tax codes so exemptions and taxability are correct.
• •Bridge EBS Basic Auth with operating unit context to Avalara account-ID and license-key Basic Auth.
• •Poll EBS on a schedule, retry Avalara 429 responses with backoff, and keep a full audit trail per record.

Questions

Which direction does data move between Oracle E-Business Suite and Avalara?

The main flow is Oracle E-Business Suite into Avalara. AP and AR invoice lines, plus customer and item references, move from EBS into AvaTax for tax calculation. The calculated tax is written back into the EBS invoice interface where a write service is deployed; Avalara holds no GL or vendor data, so no accounting records flow out of it.

How does the integration handle tax without webhooks on either side?

Neither system pushes events, so ml-connector polls Oracle E-Business Suite open interface views on LAST_UPDATE_DATE at a cadence you set and sends each new invoice to AvaTax. AvaTax CreateTransaction is synchronous and returns the calculated tax inline, so there is no callback to wait for. AvaTax is queried only to reconcile what it has already processed.

How are duplicate transactions and EBS write delays avoided?

The EBS invoice number is used as the AvaTax document code, so CreateOrAdjustTransaction updates an uncommitted transaction in place instead of creating a duplicate, and a committed code is voided then re-created if it must change. On the EBS side, an invoice write inserts into an interface table that a concurrent program imports, so ml-connector confirms the row reached the base table rather than treating a 200 as a completed import.