Which direction does data move between QAD and Brex?

The main flow is Brex into QAD. Coded accounting records move from Brex into QAD as supplier invoices or GL entries, while vendors and suppliers are aligned so spend lands on a known counterparty. Card transactions and account balances stay read-only in Brex, and ml-connector marks each record as exported once QAD accepts it so it is not posted twice.

Does the integration use Brex webhooks or polling?

It can do either. ml-connector can subscribe to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, verify the Svix signature, and pull the coded record as soon as Brex finishes coding it. Where webhooks are not used, it polls the Brex accounting records endpoint on a schedule, since QAD itself has no webhook system and is read by polling.

How are Brex GL codes and merchants matched to QAD?

GL accounts and cost centers are mapped first, so every posted line references a QAD account and cost center that already exists. Brex accounting field dimensions map to QAD cost centers, and because Brex merchant names rarely match QAD supplier names exactly, ml-connector fuzzy-matches merchants to QAD suppliers and caches the result for consistency.

QADBrex

QAD and Brex integration

QAD runs manufacturing, procurement, and finance. Brex runs corporate cards, expense management, and bill pay. Connecting the two moves coded card spend out of Brex and into the QAD ledger without re-keying. When Brex finishes coding a card transaction, the accounting record posts into QAD as a supplier invoice or GL entry against the correct cost center, and Brex vendors stay aligned with QAD suppliers. ml-connector handles the different APIs on each side and moves the data on a schedule or on a Brex webhook event.

How QAD works

QAD Adaptive ERP exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, items, and goods receipts through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname and no public sandbox. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no public webhook system for cloud connectors, so finance records are read by polling.

How Brex works

Brex exposes card transactions, coded expenses, accounting records, vendors, transfers, users, and custom accounting fields through its REST Developer API in JSON. Most connectors use a single-tenant User Token bearer credential, while partner apps use OAuth 2.0 with a one-hour access token refreshed through the offline_access scope. The Accounting Records and Vendors surfaces support reads and writes, and transactions and accounts are read-only. Brex can also push events through Svix-signed webhooks, including an accounting-record ready-for-export event that signals a transaction has been coded.

What moves between them

The main flow runs from Brex into QAD. After Brex codes a card transaction, ml-connector reads the accounting record and posts it into QAD as a supplier invoice or general ledger entry, mapped to the matching QAD GL account and cost center. Brex vendors and QAD suppliers are aligned so card spend lands against a known counterparty, and accounting field dimensions on the Brex side are mapped to QAD cost centers. Once QAD accepts the entry, ml-connector marks the Brex accounting record as exported so it is not posted twice. Card transactions and account balances stay read-only in Brex.

How ml-connector handles it

ml-connector stores the Brex token or OAuth client secret encrypted and sends it as a bearer header on every Brex call, refreshing the OAuth access token when a call returns 401 since Brex access tokens last about an hour. On the QAD side it accepts the full tenant URL per customer, because QAD publishes no shared base address, and validates entity paths against that instance. It can subscribe to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, verify the Svix signature, and pull the coded record, or poll the accounting records endpoint on a schedule where webhooks are not used, since QAD itself is pull-only. GL accounts and cost centers are mapped first so every posted line references a QAD account that already exists, and Brex merchant names are fuzzy-matched to QAD suppliers because Brex merchant names rarely match supplier names exactly. Brex returns HTTP 429 above its request limit and the Expenses API now caps page size at 100, so ml-connector paginates by cursor, backs off, and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A growing contract manufacturer with around 200 employees runs QAD Adaptive ERP for procurement and finance and gives its buyers and plant managers Brex corporate cards for tooling, freight, and shop supplies. Before the integration, an accountant exported card activity from Brex every week and hand-entered each charge into QAD, guessing at the right GL account and cost center and often mismatching the merchant to a supplier. With QAD and Brex connected, each coded Brex accounting record posts into QAD automatically against the mapped account and cost center, vendors stay aligned, and the weekly export-and-retype step is gone. Month-end close starts with card spend already in the ledger.

What you can do

Post coded Brex accounting records into QAD as supplier invoices or GL entries against the correct cost centers.
Map Brex GL accounts and accounting field dimensions to QAD GL accounts and cost centers.
Keep Brex vendors aligned with QAD suppliers and fuzzy-match merchant names to known suppliers.
Authenticate Brex with its bearer token or OAuth 2.0 and QAD with its tenant-specific login.
React to the Brex ready-for-export webhook or poll on a schedule, with cursor pagination, retries, and a full audit trail.

Questions

Which direction does data move between QAD and Brex?: The main flow is Brex into QAD. Coded accounting records move from Brex into QAD as supplier invoices or GL entries, while vendors and suppliers are aligned so spend lands on a known counterparty. Card transactions and account balances stay read-only in Brex, and ml-connector marks each record as exported once QAD accepts it so it is not posted twice.
Does the integration use Brex webhooks or polling?: It can do either. ml-connector can subscribe to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, verify the Svix signature, and pull the coded record as soon as Brex finishes coding it. Where webhooks are not used, it polls the Brex accounting records endpoint on a schedule, since QAD itself has no webhook system and is read by polling.
How are Brex GL codes and merchants matched to QAD?: GL accounts and cost centers are mapped first, so every posted line references a QAD account and cost center that already exists. Brex accounting field dimensions map to QAD cost centers, and because Brex merchant names rarely match QAD supplier names exactly, ml-connector fuzzy-matches merchants to QAD suppliers and caches the result for consistency.

Connect QAD and Brex

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

Get started