Oracle PeopleSoft and Brex integration

What moves between them

The main flow runs from Brex into Oracle PeopleSoft. Once Brex codes a card transaction, ml-connector reads the accounting record and posts a labor or expense journal into the PeopleSoft general ledger through JOURNAL_ENTRY_CI, mapped to the matching ChartFields, then calls Brex to mark the record exported. Vendor data flows the same direction so Brex payees reflect the PeopleSoft supplier master, and account and dimension reference data is aligned in both directions so every journal line uses a code that exists in PeopleSoft. Cadence is event-driven from the Brex webhook where it is enabled, with a scheduled poll of Brex accounting records as the reliable fallback. Settled transactions and statements stay read-only in Brex, so ml-connector never writes financial entries back to spend.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the Brex bearer token on every Brex call and an Authorization Basic header built from the PeopleSoft OPRID and password on every PeopleSoft call. It accepts the full PeopleSoft base URL, port, and Integration Broker node name per customer, since PeopleSoft publishes no shared address and the node name is part of the path. The Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook is verified with the Svix scheme over the webhook-id, webhook-timestamp, and raw body, after which the coded record is fetched, mapped, and posted; a scheduled poll of the accounting records endpoint backs up any missed event. Brex GL accounts and custom fields map to PeopleSoft Account, Department, and other ChartFields, and the mapping is established before any journal posts so no line lands on a missing code. Brex rate limits return HTTP 429 and PeopleSoft returns 401 on a bad OPRID or 500 on a busy Tuxedo queue, so ml-connector backs off with jitter and retries. PeopleSoft has no idempotency key, so the connector uses the Brex record id and journal key to avoid posting the same journal twice, and every record carries a full audit trail and can be replayed if a downstream call fails. The customer must whitelist the connector egress IPs and activate each Integration Broker service operation it calls.

A real-world example

A growing software company of about 250 staff runs Oracle PeopleSoft Financials for its general ledger and accounts payable, and issues Brex corporate cards to engineering, sales, and operations teams. Before the integration, an accountant exported a Brex transaction report at month-end, sorted purchases into GL accounts and departments by hand in a spreadsheet, and keyed the summary journals into PeopleSoft, which left close waiting on the spreadsheet and created errors when a card category did not match a ChartField. With Oracle PeopleSoft and Brex connected, each coded Brex record posts to the PeopleSoft ledger against the right account and department as it is finalized, vendors stay aligned, and the manual export and re-keying step is gone. Close starts with card spend already booked.

What you can do

• •Post coded Brex accounting records into the Oracle PeopleSoft general ledger as journal lines through the JOURNAL_ENTRY_CI SOAP service.
• •Map Brex GL accounts and custom dimensions to PeopleSoft Account, Department, and other ChartFields so each line uses a valid code.
• •Keep Brex vendors aligned with the PeopleSoft supplier master so payees match the ledger.
• •Bridge the Brex bearer token and PeopleSoft Basic Auth, accepting each customer's base URL and Integration Broker node name.
• •Run on the Brex export webhook with a scheduled poll fallback, retrying on 429 and 401 with a full audit trail on every record.

Questions

Which direction does data move between Oracle PeopleSoft and Brex?

The main flow is Brex into Oracle PeopleSoft. Coded accounting records and vendor data move from Brex into PeopleSoft, while GL accounts and dimensions are aligned in both directions. Brex settled transactions and statements are read-only, so ml-connector does not write financial entries back into Brex.

Does ml-connector use Brex webhooks or polling for Oracle PeopleSoft sync?

It uses both. ml-connector subscribes to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, verifies its Svix signature, and posts the record as it is coded. Because a webhook can be missed, a scheduled poll of the Brex accounting records endpoint runs as a reliable fallback, since Oracle PeopleSoft itself offers no conventional webhook to trigger from.

How does ml-connector post a journal into Oracle PeopleSoft when no REST write endpoint exists?

PeopleSoft delivered REST endpoints are read-only inquiries, so ml-connector writes GL journals through the JOURNAL_ENTRY_CI Component Interface exposed as a SOAP service on the customer's Integration Broker. It authenticates with the OPRID and password over Basic Auth, and because PeopleSoft has no idempotency key it tracks the Brex record id and journal key to avoid posting the same journal twice.