ml-connector
SAP Business OneBrex

SAP Business One and Brex integration

SAP Business One runs financials, purchasing, and inventory. Brex runs corporate cards, expenses, and bill pay. Connecting the two brings coded spend into the general ledger without re-keying. Once Brex finishes coding a card transaction or expense and marks it ready for export, ml-connector posts it into SAP Business One as a journal entry against the correct GL account and cost center, and keeps Brex vendors aligned with SAP Business One business partners. ml-connector handles the different APIs on each side and moves the data on a schedule you control.

How SAP Business One works

SAP Business One exposes business partners (vendors and customers), purchase invoices, outgoing payments, journal entries, the chart of accounts, profit centers, and dimensions through the Service Layer, an OData v4 REST API. Each customer runs their own instance, so the connector accepts the full Service Layer base URL as a credential rather than deriving it. Auth is a session login that returns a B1SESSION cookie sent on every request, with the session expiring after about 30 minutes of inactivity. Webhooks exist only on recent versions and need server-side admin setup, so finance records are normally read by polling with OData filters on the update date.

How Brex works

Brex exposes coded card expenses, accounting records, vendors, transfers, and settled transactions through a REST API, with most modern calls on api.brex.com and payments and expenses still on the legacy platform.brexapis.com base. Calls authenticate with a bearer token, either a static admin-generated API token or an OAuth access token for partner apps. The accounting records surface is the ERP-export path: each record carries a GL account and accounting field dimensions and an export status of ready for export or exported. Brex pushes Svix-signed webhooks, and the accounting record ready for export event is the one that signals a coded transaction is ready to post.

What moves between them

The main flow runs from Brex into SAP Business One. When a Brex accounting record is coded and marked ready for export, ml-connector reads it and posts a journal entry into SAP Business One against the mapped GL account, with the Brex accounting field dimensions translated to SAP Business One cost centers. Brex vendors used for bill pay are aligned with SAP Business One business partners so spend references a real partner. After each post succeeds, ml-connector marks the Brex record exported so it is never picked up twice. SAP Business One is the system of record for the ledger, so ml-connector does not write financial 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 on every call and switches between the v2 and legacy v1 bases per endpoint; on the SAP Business One side it accepts the full Service Layer base URL per customer, logs in once to get the B1SESSION cookie, reuses it across requests, and re-authenticates when a call returns the session-expired error code -5002. Brex sends Svix-signed webhooks, so each accounting record ready for export notification is verified against the signing secret before anything posts, and the Brex record id is used to deduplicate because the same event can arrive more than once. GL accounts and cost centers are mapped first so every journal line lands on an account and dimension that already exist in SAP Business One. Merchant names from Brex rarely match SAP Business One business partner names exactly, so vendor matching is fuzzy with a cached lookup. Brex rate limits return HTTP 429 and SAP Business One has no published limit, so ml-connector backs off and retries with jitter, and SAP Business One offers no idempotency key, so a posted journal is checked by its reference before any retry. Every record carries a full audit trail and can be replayed if a post fails. Where the customer has not enabled SAP Business One webhooks, Brex records are also swept on a schedule so nothing coded is missed.

A real-world example

A growing software company of about 150 people runs SAP Business One for its financials and gives staff Brex corporate cards for software subscriptions, travel, and office spend. Before the integration, an accountant exported coded transactions from Brex each week and hand-keyed the journal entries into SAP Business One, splitting each charge across the right expense account and department, and month-end close stalled while uncoded or mis-mapped charges were chased down. With SAP Business One and Brex connected, each coded Brex accounting record posts into SAP Business One as a journal entry on the correct account and cost center as soon as it is ready, and the records are marked exported so nothing is entered twice. The weekly re-keying step is gone and close starts from a ledger that already reflects card spend.

What you can do

  • Post coded Brex accounting records into SAP Business One as journal entries on the correct GL accounts after each is ready for export.
  • Translate Brex accounting field dimensions to SAP Business One cost centers and profit centers so spend lands on valid accounts.
  • Align Brex bill-pay vendors with SAP Business One business partners so each charge references a real partner.
  • Verify Brex Svix-signed webhooks and bridge them to the SAP Business One session-cookie login, deduplicating by record id.
  • Mark each Brex record exported after it posts, with retries and a full audit trail on every record.

Questions

Which direction does data move between SAP Business One and Brex?
The main flow is Brex into SAP Business One. Coded accounting records and vendor data move from Brex into SAP Business One as journal entries and business partners. SAP Business One is the system of record for the ledger, so ml-connector marks records exported in Brex but does not write financial entries back into it.
How does ml-connector know when a Brex transaction is ready to post?
Brex marks each accounting record with an export status and fires an accounting record ready for export webhook once a transaction is coded. ml-connector verifies that Svix-signed webhook, reads the record, posts the journal entry into SAP Business One, then sets the Brex record to exported so it is not picked up again. Where webhooks are not in use, a scheduled sweep catches anything coded since the last run.
How does the integration handle SAP Business One session login and its lack of webhooks?
ml-connector accepts the full Service Layer base URL per customer, logs in once for a B1SESSION cookie, reuses it, and re-authenticates on the -5002 session-expired error. SAP Business One webhooks are recent and require server-side admin setup, so by default Brex records are posted as they arrive or swept on a schedule rather than relying on a push from SAP Business One.

Related integrations

Connect SAP Business One and Brex

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

Get started