Acumatica and Brex integration

What moves between them

The main flow runs from Brex into Acumatica. When Brex marks an accounting record ready for export, ml-connector reads the coded transaction and posts it into Acumatica as a journal transaction or an AP bill, mapped to the matching GL account and subaccount, then calls Brex to mark the record exported. Vendor records and accounting dimension fields are aligned in both directions so each posting lands on a valid Acumatica vendor and GL segment. Brex card and cash transactions are read-only, so ml-connector never writes spend events back into Brex, only the export-status acknowledgement on records it has posted.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents the Brex bearer token on every Brex call while obtaining and refreshing an Acumatica OAuth token against the customer instance URL, since Acumatica publishes no shared base address and the endpoint version must match the running ERP release. It can subscribe to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook and verify the Svix signature, and it also polls Brex accounting records and Acumatica entities on a schedule as a catch-up so no coded record is missed. Brex GL dimension fields map first to Acumatica GL accounts and subaccounts, so every posted journal or bill line references a dimension that already exists in Acumatica. Brex merchant names rarely match Acumatica vendor codes exactly, so a fuzzy-match and caching layer resolves the vendor before a bill is created. After Acumatica confirms the post, the Brex record is marked exported so it is not posted twice, and Acumatica journal lines wrap every field value in the required value object. Brex returns HTTP 429 when its per-minute request limit is hit and Acumatica throttles once a tenant passes its licensed request rate, so ml-connector backs off with jitter and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A 150-person technology services firm runs Acumatica Cloud ERP for finance and projects and issues Brex corporate cards to its consultants and operations team. Before the integration, the accounting team exported card transactions from Brex each month, sorted them into GL accounts and project codes in a spreadsheet, then hand-entered the journal into Acumatica, with corrections dragging into the close. With Acumatica and Brex connected, each Brex transaction posts into Acumatica as soon as it is coded, allocated to the right account and project dimension, and the spreadsheet step is gone. The close starts with card spend already in the ledger and reconciled.

What you can do

• •Post coded Brex card and cash spend into Acumatica as journal transactions or AP bills on the correct GL accounts.
• •Subscribe to the Brex ready-for-export webhook and poll on a schedule so no coded record is missed.
• •Map Brex GL dimension fields to Acumatica GL accounts and subaccounts so every posting lands on a valid segment.
• •Resolve Brex merchant names to Acumatica vendor codes with a fuzzy-match and caching layer before creating bills.
• •Bridge the Brex bearer token and Acumatica OAuth login, mark records exported after posting, and retry on rate limits.

Questions

Which direction does data move between Acumatica and Brex?

The main flow is Brex into Acumatica. Coded accounting records and the underlying card and cash transactions move from Brex into Acumatica as journal entries or AP bills, while vendors and dimension fields are aligned in both directions. Brex transactions are read-only, so ml-connector only writes the export-status acknowledgement back to Brex on records it has posted, never the spend itself.

Does the integration use Brex webhooks or polling?

It uses both. ml-connector can subscribe to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook and verify its Svix signature so posting starts as soon as a transaction is coded. It also polls Brex accounting records and Acumatica on a schedule as a catch-up, because Acumatica has no signed push and webhook delivery is not guaranteed.

How does it handle Acumatica's version-locked URL and Brex vendor matching?

ml-connector accepts the full Acumatica instance URL and endpoint version per customer, since the version in the path must match the running ERP release or the call returns a 404. For vendors, Brex merchant names rarely match Acumatica vendor codes exactly, so a fuzzy-match and caching layer resolves the correct Acumatica vendor before any bill is created.