Oracle E-Business Suite and Airbase integration

What moves between them

The main flow runs from Airbase into Oracle E-Business Suite. As bills, expense reimbursements, and card transactions clear their Airbase approval chains, ml-connector reads them and inserts AP invoice rows into AP_INVOICES_INTERFACE, or GL journal lines into GL_INTERFACE, against the matching operating unit and account code combination, then runs the import program so the documents post. Reference data runs the other direction: the EBS supplier master and the GL_CODE_COMBINATIONS chart of accounts feed Airbase so spend is coded against valid suppliers and accounts. EBS payments and posted journals are read for status only, so ml-connector 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 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. For EBS it logs in for a session token, attaches the operating-unit org id and responsibility context to every call, accepts the customer's full instance URL and service aliases as credential fields, and re-authenticates when a call returns 401 because the session expires. 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. Suppliers and GL code combinations are mapped first, so every interface row references an EBS supplier and account that already exists. Because an EBS write is two-step, a successful POST only means the row landed in the interface table, so ml-connector triggers the import program and polls the base tables to confirm the invoice or journal actually posted, and surfaces interface rejections. EBS has no idempotency key, so each interface row is stamped with a unique SOURCE plus the Airbase id and deduplicated before insert, and bulk loads run at low concurrency since EBS has no rate limiter and is shared by interactive users. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A roughly 600-person manufacturer runs Oracle E-Business Suite R12.2 for payables and general ledger 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 invoices and journal entries into EBS, then chased interface and import errors and reconciled card and reimbursement totals during month-end close. With the two connected, approved bills, reimbursements, and card transactions load into the EBS interface tables and post through the standard import programs automatically, coded to the correct operating unit and account, while the EBS supplier list and chart of accounts keep Airbase coding accurate. The weekly re-keying disappears and close starts with spend already reconciled.

What you can do

• •Load approved Airbase bills, reimbursements, and card transactions into Oracle E-Business Suite as AP invoices and GL journals through the open interface tables.
• •Trigger Payables Open Interface Import and Journal Import, then confirm posting against the EBS base tables and surface any rejections.
• •Feed the EBS supplier master and GL_CODE_COMBINATIONS chart of accounts back to Airbase so spend is coded to valid suppliers and accounts.
• •Bridge Airbase's portal-generated bearer token and the EBS username, password, session token, and operating-unit context each instance requires.
• •Poll Airbase on a schedule and check approval status so only cleared spend loads, with deduplication, audit trail, and replay on every record.

Questions

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

The main flow is Airbase into Oracle E-Business Suite. Approved bills, expense reimbursements, and card transactions move from Airbase into EBS as AP invoices and GL journals, while the supplier master and chart of accounts flow back to Airbase. EBS payments and posted journals are read for status only, so ml-connector never writes financial entries back into Airbase.

How does the integration bridge the two different auth methods?

Airbase uses a long-lived bearer token generated in its portal, while Oracle E-Business Suite uses HTTP Basic Auth or a session token cookie plus operating-unit context on every call, with no OAuth. ml-connector stores both encrypted, sends the Airbase token against the tenant base URL, and obtains an EBS session token that it refreshes on a 401 since the session expires. It also tracks the Airbase token so a manual rotation is handled before it can break the sync.

How does the integration handle EBS two-step writes and the lack of webhooks?

An EBS write inserts rows into an open interface table such as AP_INVOICES_INTERFACE, then a concurrent program like Payables Open Interface Import posts them, so a successful POST is not a posted invoice. ml-connector triggers the import program, polls the base tables to confirm the document posted, and surfaces interface rejections. Because EBS has no webhooks for connectors, it reads EBS on a polling schedule rather than waiting for a push.