Visma and Brex integration

What moves between them

The primary flow is from Brex into Visma.net. After each expense cycle or card statement cycle, ml-connector reads Brex accounting records and expense transactions, maps them to the correct Visma supplier accounts, cost centers, and journal dimensions, and posts them as supplier invoices or journal entries into Visma's general ledger. Vendor master data flows from Brex to Visma so expense postings reference valid suppliers. Reference data such as cost centers and departments is synchronized where both systems support it, ensuring expense allocations land on valid Visma dimensions. Accounting records are read-only in Brex, so ml-connector reads and posts but does not write financial entries back into the Brex platform.

How ml-connector handles it

ml-connector stores Brex Bearer tokens and Visma client credentials encrypted and handles the different authentication schemes: OAuth 2.0 client credentials with ipp-company-id headers for Visma.net, and Bearer tokens for Brex. Brex webhooks via Svix can trigger the sync when ACCOUNTING_RECORD_READY_FOR_EXPORT fires, or ml-connector can poll both systems on a configurable schedule. Because Brex transactions are read-only, the sync reads Brex expense and card transaction data, reconciles it against Visma's existing journals to avoid duplicate postings, and creates new entries where needed. Visma requires ETag/If-Match headers for optimistic locking on updates, which ml-connector manages per entity. Both systems are rate-limited, so ml-connector includes exponential backoff on 429 responses and tracks retry state. Every record carries a full audit trail linking the original Brex expense or transaction to its corresponding Visma journal entry.

A real-world example

A mid-sized professional services firm uses Visma.net ERP for accounting and project billing, and Brex for corporate cards and expense management across 30 employees and four project teams. Before the integration, the accounting team spent two days a month exporting Brex transactions and reconciling them manually against Visma's journal, then re-entering approved expenses as supplier invoices. Now, Brex expenses and card statements post automatically into Visma allocated to the correct projects and cost centers as soon as they are approved. The team spends 30 minutes instead of two days on expense reconciliation, and project costs are always current in the ledger.

What you can do

• •Read Brex transactions and expenses and post them into Visma.net's journal as supplier invoices or journal entries allocated to the correct cost center and project.
• •Synchronize Brex vendor master data to Visma to ensure expenses reference valid suppliers.
• •Authenticate Brex via Bearer token and Visma.net via OAuth 2.0 client credentials with required ipp-company-id headers.
• •Listen for Brex webhooks via Svix (including ACCOUNTING_RECORD_READY_FOR_EXPORT) or poll on a schedule, with retries and optimistic locking for Visma updates.
• •Maintain a full audit trail linking each Brex transaction to its posted Visma journal entry, with deduplication to prevent duplicate postings across syncs.

Questions

Which direction does data move between Visma.net and Brex?

The primary flow is Brex into Visma.net. Brex expenses, card transactions, and accounting records are read and posted as journal entries into Visma's general ledger, allocated to the correct cost centers and projects. Vendor master data is synchronized to Visma so Brex expenses reference valid suppliers. Brex accounting records are read-only, so ml-connector does not write financial entries back into Brex.

Does Visma.net's ipp-company-id header requirement need special setup?

Yes. Visma.net API requires the ipp-company-id header on every request to route calls to the correct tenant. ml-connector includes the tenant company ID in the header for all Visma.net calls and validates it at setup time. The Visma.net OAuth 2.0 client credentials are obtained via Visma Connect and do not issue refresh tokens for service applications, so ml-connector obtains a new token on expiry.

How does the integration handle duplicate expense postings?

ml-connector maintains an audit log linking each Brex transaction ID and expense ID to its posted Visma journal entry reference. On each sync, it queries the audit log before posting, so the same Brex transaction is never posted twice. If a Visma entry fails after being created, ml-connector tracks the failure state and can replay the posting once the error is resolved.