ml-connector
Oracle JD EdwardsBrex

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.

How Oracle JD Edwards works

Oracle JD Edwards EnterpriseOne is on-premises, so each customer runs their own AIS Server with no shared public URL; the connector accepts the full AIS host and port plus a JDE environment and role. Authentication posts a username and password to the token request endpoint and returns an opaque session token passed in the jde-AIS-Auth header on every call. The data service reads tables such as F0411 (AP ledger), F0401 (supplier master), F0901 (account master), and F0911 (account ledger), but it is read-only. Writes go through named orchestrations such as JDE_ORCH_04_Add_Supplier_Invoice or the form service. JD Edwards has no native outbound webhooks, so the connector polls on the UPMJ updated date.

How Brex works

Brex is a corporate spend platform, not an ERP, so it has no AP vouchers, purchase orders, or chart-of-accounts ownership. It exposes settled card transactions and cash transactions as read-only, while vendors, transfers, expenses, accounting records, and custom accounting fields are read and write. Calls use a bearer token, either a single-tenant API token or an OAuth2 access token that refreshes about hourly. Lists use cursor pagination, transfers require an Idempotency-Key header, and Brex pushes Svix-signed webhooks. The most relevant event is ACCOUNTING_RECORD_READY_FOR_EXPORT, which fires once Brex has coded a transaction with its GL account and dimension values.

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

Connect Oracle JD Edwards and Brex

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started