Visma and Chargebee integration

What moves between them

Customer records and invoice headers flow from Visma to Chargebee on a configurable schedule. ml-connector polls Visma for customers created or modified since the last sync, maps Visma customer IDs to Chargebee customer records, and upserts them. Invoices follow the same polling pattern. In the reverse direction, Chargebee publishes subscription lifecycle events (created, updated, canceled) via webhooks, which ml-connector can consume and record as journal entries in Visma for revenue recognition and accruals.

How ml-connector handles it

ml-connector stores Visma's OAuth client credentials and Chargebee's API key encrypted in its database. On startup it obtains a Visma OAuth token using client_credentials grant with the client_id, client_secret, and tenant_id, and includes the required ipp-company-id header on all Visma API calls. For Chargebee, it Base64-encodes the API key as the Authorization header. ml-connector polls Visma on a schedule (configurable, often once per hour or per business day) by querying the customer and invoice list endpoints with a lastModifiedDateTime filter to fetch only records changed since the last sync, then upserts each into Chargebee via POST /api/v2/customers or PATCH operations. When Chargebee webhooks for subscription events fire, ml-connector receives them, verifies the signature using Chargebee's event_id retrieval endpoint if needed, and writes the subscription status and amount to a journal table in Visma via POST to the transaction endpoint. Visma refresh tokens are not issued to service applications, so token expiry is handled by re-running the OAuth flow on each expiry; Chargebee API key does not expire. Rate limiting on both sides (Visma 500 calls per hour on test, Chargebee 150-3500 calls per minute depending on plan) is respected with exponential backoff and jitter on 429 responses. Every customer record and invoice pulled from Visma carries a full audit log with timestamp, direction, and payload, so any record can be replayed if a downstream Chargebee call fails.

A real-world example

A Nordic software-as-a-service company uses Visma.net ERP for its financial and accounting operations, including customer master records and invoicing. The company also uses Chargebee to manage recurring subscription billing and payment collection. Before the integration, the finance team manually exported customers from Visma, pasted them into a spreadsheet, and uploaded batches to Chargebee monthly, leading to stale customer data in Chargebee and duplicate or missing records. Subscription invoices issued by Chargebee were manually entered into Visma's accounts receivable to close the billing cycle. After Visma and Chargebee are connected, new customers and customer updates in Visma sync automatically to Chargebee on the daily schedule, subscription lifecycle events from Chargebee flow back into Visma as journal entries for revenue recognition, and the manual re-entry work is eliminated.

What you can do

• •Sync customer records from Visma to Chargebee, with Visma as the source of truth for name, address, and identifier.
• •Poll Visma on a schedule for new and updated invoices, and create or update matching invoice records in Chargebee.
• •Receive Chargebee subscription lifecycle events via webhook and record them as revenue or accrual transactions in Visma.
• •Authenticate Visma with OAuth 2.0 client credentials and handle token refresh on expiry, and authenticate Chargebee with HTTP Basic Auth API key.
• •Track audit history on every customer, invoice, and subscription event, with full replay capability if a sync step fails.

Questions

Which direction does data flow between Visma and Chargebee?

The primary flow is Visma to Chargebee: customers and invoices from your ERP sync to your billing system so Chargebee has current customer data. In the reverse direction, Chargebee subscription lifecycle events (created, updated, canceled) flow back into Visma as journal entries for revenue and accrual accounting, ensuring your ERP books reflect the subscription status.

How does ml-connector handle the different authentication methods on each side?

Visma uses OAuth 2.0 with client credentials grant; ml-connector stores the client_id and client_secret encrypted and obtains a fresh token at startup, refreshing it on expiry. Chargebee uses HTTP Basic Auth with an API key; ml-connector stores the key encrypted and Base64-encodes it in the Authorization header on each request. Both credentials are kept in ml-connector's encrypted vault.

What happens if a Chargebee webhook event is missed or fails?

Chargebee webhook events are published once and retried for up to 2 days with increasing delays. ml-connector can also retrieve missed events by querying the Chargebee events endpoint if notification is lost, and the full audit history in ml-connector allows any transaction to be replayed into Visma if a journal entry fails to post.