IFS Cloud and Brex integration

What moves between them

Brex accounting records and approved expenses flow into IFS Cloud as posting proposal headers. The primary trigger is the ACCOUNTING_RECORD_READY_FOR_EXPORT webhook event from Brex, supplemented by polling when webhooks are not enabled. Direction is Brex-to-IFS, keeping IFS Cloud's general ledger synchronized with approved spend. Reference data such as GL accounts and company codes are pre-aligned so each Brex transaction maps to a valid IFS posting proposal without re-keying.

How ml-connector handles it

ml-connector stores encrypted OAuth 2.0 credentials for both systems. On the Brex side it receives ACCOUNTING_RECORD_READY_FOR_EXPORT webhook events, verifies the HMAC-SHA256 signature, and retrieves the accounting record detail via Brex REST. For IFS Cloud it refreshes the OAuth 2.0 bearer token before each call (tokens expire in 60 minutes), then reads the ETag from the target GL account or voucher record before posting a new proposal. Every POST mutation to IFS includes the captured ETag in the If-Match header to satisfy optimistic concurrency. If an ETag is stale (IFS returns 412 Conflict), ml-connector re-reads the record, captures the new ETag, and retries the mutation. It also handles IFS OData page-size limits (keeping expanded arrays under 5000 elements) and respects the 1000-request-per-minute rate limit with exponential backoff on HTTP 429. Brex vendor and expense records are deduplicated by querying existing IFS posting proposals before creating new ones.

A real-world example

A mid-market technology company uses IFS Cloud for finance and procurement, and uses Brex for employee corporate cards and expense management. Each week, the finance team reviews approved expenses in Brex, exports them to a spreadsheet, and manually re-enters the amounts into IFS Cloud's general ledger by department. With IFS Cloud and Brex connected, each approved accounting record from Brex flows automatically into IFS Cloud as a posting proposal, mapped to the company code and GL accounts for each department, so the manual entry step is eliminated and month-end close reconciliation is complete before the process begins.

What you can do

• •Receive Brex accounting records and expense data via webhook, with HMAC-SHA256 signature verification.
• •Map Brex transactions to IFS Cloud GL accounts and company codes for automatic posting proposal creation.
• •Handle OAuth 2.0 token refresh on the IFS Cloud side (60-minute expiry) and bearer token auth on the Brex side (1-hour expiry).
• •Manage IFS Cloud optimistic concurrency by reading and applying ETag headers on every mutation, with automatic retry on stale ETags.
• •Poll Brex and IFS Cloud on a configurable schedule when webhooks are not enabled, with dedup to prevent duplicate posting proposals.

Questions

What data moves from Brex into IFS Cloud?

Brex accounting records and approved expenses flow into IFS Cloud as posting proposal headers. Direction is Brex-to-IFS only. Transactions in Brex are read-only, so ml-connector never writes financial data back into Brex. Reference data such as vendors is aligned so posting proposals map to valid GL accounts and company codes.

How does ml-connector handle IFS Cloud's ETag concurrency requirement?

IFS Cloud enforces optimistic concurrency via ETag headers. Before posting a new proposal, ml-connector reads the target GL account or voucher record to capture its current ETag, then includes that ETag in the If-Match header on the mutation. If the ETag is stale (IFS returns 412 Conflict), ml-connector re-reads the record, obtains the new ETag, and retries automatically.

Does ml-connector use Brex webhooks or polling?

It uses Brex webhooks where available. ml-connector listens for ACCOUNTING_RECORD_READY_FOR_EXPORT events, verifies the HMAC-SHA256 signature, and processes the record immediately. If webhooks are not enabled, it falls back to scheduled polling of Brex and IFS Cloud on a cadence you control.