Oracle JD Edwards and Brex integration
Oracle JD Edwards EnterpriseOne runs finance and procurement on-premises. Brex runs corporate cards, expenses, and bill pay. Connecting the two brings coded card spend into the general ledger without re-keying. Once Brex finishes coding a card transaction with its GL account and accounting dimensions, ml-connector posts the matching supplier voucher or journal entry into JD Edwards, and keeps Brex vendors aligned with the JD Edwards supplier master. ml-connector handles the very different authentication on each side and moves the data as soon as Brex marks a record ready.
What moves between them
The main flow runs from Brex into Oracle JD Edwards EnterpriseOne. When Brex finishes coding a card transaction, ml-connector reads the accounting record with its GL account and accounting fields and posts it into JD Edwards as a supplier voucher through the Add Supplier Invoice orchestration, or as a journal entry through a batch orchestration, against the matching JDE business unit and object account. Brex vendors used for bill pay are aligned with the JD Edwards supplier master so each posting references a supplier that already exists. Brex card and cash transactions are read-only, so ml-connector treats Brex as the spend source and never writes ledger entries back into Brex.
How ml-connector handles it
ml-connector stores both credential sets encrypted. On the Brex side it sends the bearer token and refreshes the OAuth2 access token when a call returns 401. On the JD Edwards side it logs in with the username and password to get the AIS session token, sends it in the jde-AIS-Auth header, and re-authenticates automatically on HTTP 444 (invalid token), which also covers AIS Server restarts. Because JD Edwards has no outbound webhooks, ml-connector subscribes to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook to drive the work in near real time, verifies the Svix signature, and runs a scheduled poll of Brex records as a backstop. Each Brex GL account and accounting field is mapped to a JDE business unit and object account before posting, and Brex merchant names rarely match JDE supplier names exactly, so a fuzzy match and cache resolves the right supplier address number. Brex transfers carry an Idempotency-Key on create, and once JD Edwards accepts a posting ml-connector calls Brex to set the record export status to EXPORTED so it is not posted twice. The connector also expects the customer to add its egress IP to the JDE allowedHosts list, since the AIS Server returns HTTP 405 to callers that are not allowlisted.
A real-world example
A growing services firm of about 300 people runs Oracle JD Edwards EnterpriseOne on Oracle Cloud Infrastructure for finance and uses Brex for corporate cards and bill pay across several departments. Before the integration, the accounting team exported card spend from Brex each month and keyed the vouchers and journal entries into JD Edwards by hand, then reconciled merchant names against the supplier master line by line. With Oracle JD Edwards EnterpriseOne and Brex connected, each coded Brex transaction posts into the ERP as it becomes ready, allocated to the correct business unit and object account, and the supplier match is resolved automatically. The monthly re-keying step is gone and the spend accounts are reconciled as the period closes.
What you can do
- Post coded Brex card transactions into Oracle JD Edwards EnterpriseOne as supplier vouchers or journal entries through named orchestrations.
- Keep the JD Edwards supplier master aligned with Brex vendors used for bill pay.
- Map Brex GL accounts and accounting fields to JD Edwards business units and object accounts so postings land on valid dimensions.
- Bridge the Brex bearer token and the JD Edwards AIS session token, re-authenticating on expiry and HTTP 444.
- React to the Brex accounting-record-ready webhook in near real time, with a scheduled poll as a backstop and export status marked once JD Edwards accepts the record.
Questions
- Which direction does data move between Oracle JD Edwards EnterpriseOne and Brex?
- The main flow is Brex into JD Edwards. Coded accounting records and vendor data move from Brex into JD Edwards, posted as supplier vouchers or journal entries. Brex card and cash transactions are read-only, so ml-connector treats Brex as the spend source and does not write ledger entries back into Brex.
- How does the integration handle the different authentication on each side?
- ml-connector stores both credential sets encrypted. It sends the Brex bearer token and refreshes the OAuth2 access token on a 401, and it logs in to the JD Edwards AIS Server with the username and password to obtain a session token sent in the jde-AIS-Auth header. When JD Edwards returns HTTP 444 for an invalid or restarted token, the connector re-authenticates automatically.
- How are changes detected if JD Edwards has no webhooks?
- Detection is driven from the Brex side. ml-connector subscribes to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, which fires once a transaction is coded, and verifies its Svix signature. A scheduled poll of Brex accounting records runs as a backstop so nothing is missed if a webhook is dropped, and the JD Edwards side is written to through orchestrations rather than polled for the posting itself.
Related integrations
More Oracle JD Edwards integrations
Other systems that connect to Brex
Connect Oracle JD Edwards and Brex
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started