Oracle E-Business Suite and Brex integration

What moves between them

The main flow runs from Brex into Oracle E-Business Suite. When a Brex accounting record reaches READY_FOR_EXPORT, ml-connector reads it, translates its gl_account_id and accounting_fields into an EBS GL code combination, and inserts the journal lines into GL_INTERFACE so the Journal Import concurrent program can post them. Once EBS confirms the journal, ml-connector calls Brex to mark the record EXPORTED so it is never posted twice. Supplier and vendor reference data is aligned the other direction so EBS suppliers can be created as Brex vendors for bill pay, and GL accounts and dimensions are matched so every line lands on a valid combination. Card and cash transactions in Brex are read-only, so ml-connector never writes spend back into Brex.

How ml-connector handles it

ml-connector stores both credential sets encrypted and attaches the Brex Bearer token to every Brex call, refreshing the OAuth access token before it expires and watching the User Token so 90 days of inactivity cannot silently kill it. On the EBS side it accepts the full per-customer base URL, logs in for a session token, re-authenticates on a 401 when the session times out, and includes ctx_orgid and the responsibility context on every request. GL accounts and Brex Fields are mapped first, so each posted line references a code combination that already exists in EBS. Because EBS sends no callbacks, ingestion is driven by the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook with a scheduled poll as backfill, and posting confirmation is verified by reading the base table since the GL_INTERFACE insert only queues the import, it does not post it. Brex merchant names rarely match EBS supplier names, so a fuzzy-match step links spend to the right vendor. Brex returns HTTP 429 over its request and transfer limits, so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A venture-backed software company of about 200 employees runs Oracle E-Business Suite R12.2 as its system of record and issues Brex cards to every team. Before the integration, an accountant exported the Brex monthly statement, sorted hundreds of card and expense lines by category, and hand-keyed a summary journal into Oracle, then chased coding questions during close. With Oracle E-Business Suite and Brex connected, each coded transaction posts into the EBS general ledger on the correct account and cost center as soon as Brex marks it ready, and the export status keeps every line posted exactly once. Close starts with card spend already in the ledger instead of sitting in a spreadsheet.

What you can do

• •Post coded Brex card and expense spend into the Oracle E-Business Suite general ledger through GL_INTERFACE and Journal Import.
• •Mark Brex accounting records EXPORTED only after EBS confirms the journal posted, so nothing posts twice.
• •Map Brex GL accounts and custom Fields onto EBS code combinations and operating-unit context.
• •Create and update Brex vendors from Oracle E-Business Suite suppliers for bill pay.
• •Drive ingestion from the Brex ready-for-export webhook with scheduled polling as backfill, plus retries and a full audit trail.

Questions

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

The main flow is Brex into Oracle E-Business Suite. Coded card and expense spend moves from Brex into the EBS general ledger as journal lines, while supplier and vendor data can be aligned the other way so EBS suppliers become Brex vendors. Brex card and cash transactions are read-only, so ml-connector never writes spend back into Brex.

How does ml-connector keep Brex spend from posting to Oracle twice?

Brex accounting records carry an export_status. ml-connector only posts a record once it reaches READY_FOR_EXPORT, and after Oracle confirms the journal it calls Brex to set the status to EXPORTED. Because the GL_INTERFACE insert just queues the Journal Import program, ml-connector reads the EBS base table to confirm the posting actually completed before marking the record done.

Does the integration use webhooks or polling?

It uses both. Brex can push a Svix-signed ACCOUNTING_RECORD_READY_FOR_EXPORT webhook the moment a transaction is coded, which triggers the post into Oracle. Oracle E-Business Suite sends no callbacks, so ml-connector also polls on a schedule to confirm journals posted and to backfill any event the webhook missed.