Which direction does data move between Wave Accounting and Brex?

The main flow is Brex into Wave Accounting. Coded accounting records and vendor details move from Brex into Wave, where they become money transactions and vendor records. Brex card and cash transactions are read-only, so ml-connector never writes financial data back into Brex; it only marks a record exported once Wave has confirmed the write.

Does this create bills or accounts-payable entries in Wave Accounting?

No. Wave Accounting has no purchase order, bill, or structured accounts-payable object in its GraphQL API. Brex spend is recorded in Wave as money transactions through the moneyTransactionCreate mutation, with debit and credit lines posted against the mapped chart-of-accounts entries.

How does the connector avoid posting the same Brex charge twice?

The Wave moneyTransactionCreate mutation accepts an external id, and ml-connector derives that id from the Brex accounting record id. If a sync is retried after a failure, the same external id is reused, so Wave recognizes the existing entry instead of booking a duplicate. The connector also reads accounting records on a schedule to backfill any webhook that Brex did not deliver.

Wave AccountingBrex

Wave Accounting and Brex integration

Wave Accounting runs invoicing and the books for small businesses. Brex runs corporate cards, expenses, and bill pay. Connecting the two gets your card and cash spend into the ledger without anyone re-typing it. After Brex codes a transaction and marks it ready for export, ml-connector posts it into Wave Accounting as a money transaction against the right account, and it keeps the vendor list in step on both sides. ml-connector handles the very different APIs on each side and moves the data on a schedule you control.

How Wave Accounting works

Wave Accounting exposes its data through a single GraphQL endpoint at gql.waveapps.com/graphql/public, where reads are queries and writes are mutations. It authenticates with an OAuth2 authorization-code token that expires in about two hours, so a refresh token from the offline_access scope is required for unattended syncs. Every entity is scoped to a business id that the connector reads first through the businesses query. Key entities are customers, invoices, products, chart-of-accounts entries, and money transactions, and the moneyTransactionCreate mutation accepts an external id for safe retries. Wave can push invoice, customer, and transaction events to a registered HTTPS endpoint, signed with an x-wave-signature HMAC-SHA256 header. Wave has no purchase order, bill, or structured accounts-payable object, so spend is recorded as money transactions rather than bills.

How Brex works

Brex exposes its data through a REST API across two active hosts, api.brex.com for v2 endpoints and platform.brexapis.com for the v1 payments and accounting endpoints. It authenticates with a bearer token, either a static admin-generated API token or an OAuth2 access token for partner apps, sent in the Authorization header. Card and cash transactions are read-only, while expenses, vendors, transfers, and accounting records are read and write. The accounting records surface carries the gl_account_id, custom accounting fields, and an export_status that moves from READY_FOR_EXPORT to EXPORTED. Brex signs webhooks with Svix and can fire an ACCOUNTING_RECORD_READY_FOR_EXPORT event the moment a transaction has finished coding. List endpoints use cursor pagination, and the Expenses API caps the page limit at 100.

What moves between them

The main flow runs from Brex into Wave Accounting. When Brex finishes coding a card or cash transaction and marks it ready for export, ml-connector reads the accounting record and posts a money transaction into Wave, with debit and credit lines mapped to the matching Wave chart-of-accounts entries. Vendor records flow the same direction so a Brex payee that does not yet exist in Wave is created there. Chart-of-accounts entries and Brex GL accounts and dimensions are aligned first so every posted line references a Wave account that already exists. Brex transactions are read-only, so ml-connector never writes spend data back to Brex, and the records it posts are marked exported in Brex once Wave confirms the write.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the Brex bearer token on every REST call, and attaches the Wave OAuth2 access token on every GraphQL request, refreshing the Wave token before its two-hour expiry rather than waiting for a 401. It reads the Wave business id once through the businesses query and scopes every following call to it. The trigger is the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT webhook, whose Svix signature is verified against the signing secret, and a scheduled poll of accounting records backs it up so nothing is missed if a delivery is dropped. Each Brex record becomes a Wave money transaction whose external id is derived from the Brex record id, so a retry updates rather than duplicates the entry, and Wave returns GraphQL errors inside an HTTP 200 body, so the connector checks the errors array, not just the status code. Brex merchant names rarely match Wave vendor names exactly, so a fuzzy match with a cached mapping decides whether to reuse an existing Wave vendor or create one. Brex returns HTTP 429 when its per-minute request budget is exceeded and Wave throttles per token, so ml-connector backs off with jitter and retries. The connected Wave business must hold an active Wave Pro subscription for third-party access, which is checked during onboarding.

A real-world example

A thirty-person design studio runs its books in Wave Accounting and gives staff Brex corporate cards for software, travel, and client costs. Before the integration, the bookkeeper exported a Brex transaction list at month end and hand-entered each charge into Wave as a transaction, guessing at the right account and chasing missing receipts. With Wave Accounting and Brex connected, each charge Brex has coded posts into Wave as a money transaction on the correct account the same day, and any new vendor is created in Wave automatically. The bookkeeper reviews coded entries instead of typing them, and the month-end catch-up is gone.

What you can do

Post coded Brex card and cash transactions into Wave Accounting as money transactions on the correct accounts.
Map Brex GL accounts and accounting dimensions to Wave chart-of-accounts entries before any posting.
Create or match Wave vendors from Brex payees using fuzzy matching with a cached mapping.
Trigger on the Brex ready-for-export webhook and back it up with a scheduled poll of accounting records.
Refresh the Wave OAuth2 token automatically and dedupe every posting by a stable external id.

Questions

Which direction does data move between Wave Accounting and Brex?: The main flow is Brex into Wave Accounting. Coded accounting records and vendor details move from Brex into Wave, where they become money transactions and vendor records. Brex card and cash transactions are read-only, so ml-connector never writes financial data back into Brex; it only marks a record exported once Wave has confirmed the write.
Does this create bills or accounts-payable entries in Wave Accounting?: No. Wave Accounting has no purchase order, bill, or structured accounts-payable object in its GraphQL API. Brex spend is recorded in Wave as money transactions through the moneyTransactionCreate mutation, with debit and credit lines posted against the mapped chart-of-accounts entries.
How does the connector avoid posting the same Brex charge twice?: The Wave moneyTransactionCreate mutation accepts an external id, and ml-connector derives that id from the Brex accounting record id. If a sync is retried after a failure, the same external id is reused, so Wave recognizes the existing entry instead of booking a duplicate. The connector also reads accounting records on a schedule to backfill any webhook that Brex did not deliver.

Connect Wave Accounting and Brex

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

Get started