Infor CloudSuite and Brex integration

What moves between them

Brex to Infor CloudSuite is the main direction: coded accounting records become supplier invoices and GL entries in Infor, posted shortly after Brex marks each record ready for export. Brex vendors are reconciled against Infor suppliers so each charge lands on a known payee. Infor GL accounts and dimensions flow back to Brex Fields and the accounting integration on a scheduled refresh so Brex coders pick valid ERP segments. Card and cash transactions can be pulled read-only from Brex for reconciliation. Cadence is event-driven for export readiness and scheduled polling for master data.

How ml-connector handles it

ml-connector holds two credential sets: the Brex bearer token or OAuth client, and the Infor .ionapi fields used to fetch an OAuth2 password-grant token, which it refreshes before expiry rather than waiting for a 401. It subscribes to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, verifies the Svix signature over the raw body, then calls GET on the accounting record to pull the coded detail. A Brex gl_account_id maps to an Infor accounting string (M3 CRS630MI dimensions), and accounting_fields map to the company and cost segments; the record is written with APS100MI AddHead and AddLine. Because the M3 API has no idempotency key, the connector queries by invoice number with GetHead before writing to avoid duplicates, then calls PUT to set the Brex record to EXPORTED. Merchant-to-vendor matching is fuzzy, so a cached supplier map resolves Brex merchants to Infor SUNO values. 429 responses on either side back off with jitter, and where ION Desk BOD flows are configured, Process.SupplierInvoice can be used instead of direct M3 writes.

A real-world example

A 250-person specialty manufacturer runs Infor M3 CloudSuite for finance and gives department leads Brex cards for tooling, software, and travel. At month end the accounting team exports a Brex spreadsheet and rekeys hundreds of charges into M3 as supplier invoices, which is slow and error-prone and delays the close. With this connection each Brex charge, once coded and marked ready for export, is posted automatically into M3 against the right GL account and company, so the team reviews exceptions instead of typing every line and closes days earlier.

What you can do

• •Post coded Brex accounting records into Infor CloudSuite as supplier invoices and GL entries.
• •Match Brex vendors to Infor suppliers so each charge lands on a known payee.
• •Push Infor GL accounts and dimensions into Brex Fields so spend is coded to valid ERP segments.
• •Mark each Brex accounting record EXPORTED once it is confirmed written in Infor CloudSuite.
• •Pull Brex card and cash transactions read-only for reconciliation against Infor postings.

Questions

Which direction does spend data move between Brex and Infor CloudSuite?

The primary direction is Brex into Infor CloudSuite. Coded Brex accounting records are posted into Infor as supplier invoices and GL entries against the correct accounts. Infor GL accounts and dimensions move back to Brex Fields so coders pick valid ERP segments, and Brex card and cash transactions can be pulled read-only for reconciliation.

Does this rely on webhooks or polling?

Both, because the two systems differ. Brex fires the Svix-signed ACCOUNTING_RECORD_READY_FOR_EXPORT event, which ml-connector uses to pull a coded record as soon as it is ready. Infor CloudSuite has no self-service webhooks, so master data such as suppliers and GL accounts is read on a schedule through the ION API Gateway.

How are duplicate invoices prevented when writing to Infor?

The Infor M3 API has no idempotency key and its Add transactions create a new record on every call. ml-connector queries Infor by invoice number with GetHead before writing, and tracks which Brex record IDs were already posted. A record is only marked EXPORTED in Brex after it is confirmed written, so a retry does not create a second invoice.