Visma and Airbase integration

What moves between them

Supplier invoices, purchase orders, and vendors flow from Visma into Airbase. Supplier and dimension master data (cost centers, GL accounts) are synced bidirectionally to keep Airbase reference tables current. When an invoice is approved in Airbase, the payment transaction flows back into Visma as a supplier payment record, where it posts to the accounts payable ledger allocated to the correct GL account and cost center. The cadence is delta-based: Visma webhooks trigger immediate pulls on entity updates, and a scheduled poller maintains sync during periods of low activity.

How ml-connector handles it

ml-connector stores Visma tenant credentials (client_id, client_secret, tenant_id) and Airbase token encrypted, and obtains a fresh Visma OAuth2 bearer token on each batch cycle using the client-credentials grant. It passes the ipp-company-id header on all Visma calls to target the correct company within the tenant. On the Airbase side it presents the static bearer token in the Authorization header. For inbound supplier data, ml-connector queries Visma for suppliers and invoices via lastModifiedDateTime filters, maps them to Airbase bill creation or update events, and seeds the billable amount from the invoice. For outbound payments, ml-connector polls Airbase for approved bills, reads the payment status, and writes a SupplierPayment record back to Visma with the remittance amount and GL account reference. Because Visma requires ETag for optimistic locking on PUT operations, ml-connector reads the invoice or payment before updating and includes the ETag in the request to prevent race conditions. Airbase rate limits and timeouts are handled with exponential backoff. A full audit log is kept on every record transition.

A real-world example

A mid-sized import-export company operates in Sweden with Visma.net ERP for financial management and purchasing across three warehouses. They use Airbase for centralized spend management, corporate card oversight, and vendor payment approval. Before the integration, the AP team exported vendor invoices from Visma weekly, manually entered them into Airbase for approval routing, waited for approvals, then exported approved payment lists back to Visma and posted them by hand. With Visma and Airbase connected, invoices flow automatically into Airbase the moment they are received, approvers review and approve via Airbase's workflow, and approved payments post back to Visma without touching a spreadsheet. Month-end close is faster because the AP ledger is already current.

What you can do

• •Sync supplier master data and invoices from Visma into Airbase for centralized spend review and approval.
• •Post approved vendor payments from Airbase back to Visma accounts payable with full GL account and cost center allocation.
• •Keep purchase orders and receipts aligned between Visma and Airbase so procurement and finance agree on inventory movement.
• •Bridge Visma OAuth2 authentication with Airbase static tokens, handling token refresh and expiry on the Visma side.
• •Poll for delta changes via lastModifiedDateTime, respect Visma ETag requirements for safe updates, and maintain a complete audit trail on every record.

Questions

Which direction does data flow between Visma and Airbase?

The main flow is Visma into Airbase for supplier invoices, purchase orders, and vendor master data. Approved payments flow back from Airbase into Visma for posting to accounts payable. GL accounts and subsidiaries are reference data synced to ensure Airbase payment allocations land on valid Visma dimensions.

How does ml-connector handle Visma's OAuth2 and company-level headers?

ml-connector stores the Visma client credentials encrypted and obtains a fresh bearer token on each batch cycle using the client-credentials grant via Visma Connect. The ipp-company-id header is required on every API call to target the correct company within the tenant, so ml-connector includes it on all requests.

What happens if an invoice update in Visma conflicts with a payment write from Airbase?

Visma requires an ETag on PUT operations for optimistic locking. ml-connector reads the full record (invoice or payment) before updating, extracts the ETag from the response, and includes it in the PUT request. If the ETag is stale, Visma rejects the write and ml-connector re-fetches and retries.