Oracle JD Edwards and Airbase integration

What moves between them

The main flow runs from Airbase into Oracle JD Edwards. As bills, expense reimbursements, and card transactions clear their Airbase approval chains, ml-connector reads them and writes AP vouchers and journal entries into JD Edwards through the configured orchestrations, against the matching object accounts and business units. Reference data runs the other direction: the JD Edwards account master, business units, and supplier records feed Airbase so spend is coded against valid GL accounts. Account ledger data is read-only over the data service, so ml-connector creates postings only through orchestrations and never writes financial entries back into Airbase.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents the right one per side. For JD Edwards it accepts the full AIS host, port, and environment as credential fields since there is no shared base URL, posts JDE credentials for a session token, sends that token in the jde-AIS-Auth header, and re-authenticates automatically on an invalid-token response, which JDE returns after an AIS Server restart. For Airbase it sends the portal-generated bearer token against the tenant base URL and tracks the token so a manual rotation does not become an outage. Airbase approval chains mean a created bill is not yet payable, so ml-connector reads on a polling schedule and checks status fields rather than acting on the first event, and it can consume Airbase webhooks where they are enabled. Account and business unit mappings are set first, so every voucher and journal line references a JD Edwards object account and cost center that already exists. Writes depend on the customer importing the pre-built orchestrations or naming a custom one, so the orchestration name is a config field, and because JDE has no idempotency header the connector deduplicates before each write to avoid duplicate vouchers. JDE returns a forbidden response if the integration user license is locked and a separate code if the connector IP is not on the AIS allowlist, so ml-connector surfaces those plainly, backs off on server errors, and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A roughly 600-person industrial distributor runs Oracle JD Edwards EnterpriseOne for finance and procurement and uses Airbase for corporate cards, employee reimbursements, and vendor bill payments. Before the integration, the accounting team exported spend from Airbase each week and hand-keyed vouchers and journal entries into JD Edwards, then reconciled card and reimbursement totals against the account ledger during month-end close. With the two connected, approved bills, reimbursements, and card transactions post into JD Edwards automatically through orchestrations, coded to the correct object account and business unit, while the JD Edwards account master and supplier list keep Airbase coding accurate. The weekly re-keying disappears and close starts with spend already reconciled.

What you can do

• •Post approved Airbase bills, reimbursements, and card transactions into Oracle JD Edwards as AP vouchers and journal entries through orchestrations.
• •Feed the JD Edwards account master, business units, and supplier list back to Airbase so spend is coded to valid accounts.
• •Bridge Airbase's portal-generated bearer token and the JD Edwards AIS session token, with automatic re-authentication on token expiry.
• •Poll Airbase on a schedule and check approval status so only cleared spend posts to the ledger.
• •Deduplicate orchestration writes since JD Edwards has no idempotency header, with a full audit trail and replay on every record.

Questions

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

The main flow is Airbase into JD Edwards. Approved bills, expense reimbursements, and card transactions move from Airbase into JD Edwards as AP vouchers and journal entries, while the account master, business units, and supplier list flow back to Airbase. JD Edwards account ledger data is read-only over the data service, so ml-connector writes only through orchestrations and never posts financial entries into Airbase.

How does the integration bridge the two different auth methods?

JD Edwards uses an AIS session token obtained by posting credentials to the token request endpoint and sent in the jde-AIS-Auth header, while Airbase uses a long-lived bearer token generated in its portal. ml-connector stores both encrypted, accepts the customer AIS host and environment since there is no shared base URL, and re-authenticates to JD Edwards automatically when the token is invalidated, which happens after an AIS Server restart. It also tracks the Airbase token so a manual rotation is handled before it can break the sync.

How does it write to JD Edwards when direct table writes are not supported?

The data service can only read JD Edwards tables, so all writes go through named orchestrations such as JDE_ORCH_04_Add_Supplier_Invoice that the customer imports into Orchestrator Studio, or a custom orchestration whose name is a config field. Because JD Edwards has no idempotency header, ml-connector deduplicates before each write to prevent duplicate vouchers. Failed calls are retried and can be replayed from the audit trail.