Visma and BILL integration

What moves between them

The primary flow is from BILL into Visma. When a vendor is created or updated in BILL, ml-connector receives the webhook notification, verifies the HMAC-SHA256 signature, and creates or updates the corresponding supplier record in Visma. When a bill is created or updated in BILL, ml-connector maps it to a supplier invoice in Visma, ensuring the vendor reference is already synced. Because Visma webhooks lack automatic retry, ml-connector also polls BILL on a configured cadence to catch any events that arrived after the one-time webhook delivery failed or timed out. Dimensions such as cost centers are aligned manually in the configuration so that bill allocations land on valid GL dimensions in Visma.

How ml-connector handles it

ml-connector stores BILL and Visma credentials separately. For Visma, it exchanges the client credentials for an OAuth2 token via Visma Connect and includes the ipp-company-id header on every API call. For BILL, it logs in once per session to obtain a sessionId and uses that to authenticate subsequent calls. When BILL sends a webhook for a vendor or bill event, ml-connector verifies the x-bill-sha-signature header using the webhook securityKey - a one-time value returned only at subscription creation that must be stored securely - and processes only valid signatures. Since the webhook securityKey is single-use, ml-connector stores it encrypted immediately and never requests it again. On webhook delivery failure or timeout, ml-connector polls BILL's vendor and bill lists using the minified JSON HMAC computation standard that BILL expects and compares lastModifiedDateTime to Visma's last sync point to detect new or changed records. Because Visma requires optimistic locking via the ETag header on PUT operations, ml-connector fetches the current record, checks the ETag, and includes it on the update to prevent conflicts. BILL vendors without a Visma supplier counterpart are logged as unmatched and held until the supplier is created manually.

A real-world example

A Nordic accounting firm works with multiple SMB clients across Sweden and Denmark. Several clients use BILL for AP automation and want their vendor master and bills to also appear in Visma.net ERP for consolidated accounting. Before the integration, accountants manually created supplier records in Visma when new vendors were added in BILL, and then re-entered bill details from BILL into Visma invoices during month-end close. With BILL and Visma connected, new vendors in BILL automatically appear as suppliers in Visma, and approved bills flow directly into Visma as supplier invoices mapped to the correct GL accounts and cost centers. Month-end close is faster, and the risk of duplicate bills or mismatched vendor records is eliminated.

What you can do

• •Sync vendors created or updated in BILL as suppliers in Visma.net ERP, with webhook verification and polling fallback for reliability.
• •Map BILL bills to Visma supplier invoices, ensuring each bill references an existing vendor and valid GL accounts.
• •Authenticate BILL with session tokens and Visma with OAuth2 via Visma Connect, managing token renewal and session expiry.
• •Verify BILL webhook signatures using HMAC-SHA256 and the one-time securityKey provided at subscription creation.
• •Reconcile vendor and bill records on a configurable schedule using lastModifiedDateTime polling to catch any missed webhook deliveries.

Questions

How does ml-connector handle the different authentication schemes in BILL and Visma?

BILL uses a custom login flow with username, password, organizationId, and devKey to obtain a sessionId that expires after 35 minutes of inactivity. Visma uses OAuth2 via Visma Connect with client_credentials grant and requires the ipp-company-id header on every call. ml-connector manages both credential sets separately, refreshing the BILL session before expiry and obtaining new Visma OAuth2 tokens as needed.

What happens if a BILL webhook fails to deliver?

BILL webhooks have one-time delivery with no automatic retry. ml-connector compensates by polling BILL's vendor and bill lists on a schedule using the lastModifiedDateTime query parameter to detect new or changed records since the last successful sync. This ensures vendors and bills are not lost if a webhook delivery times out or is not received.

Why does BILL webhook verification require the securityKey to be stored immediately?

BILL returns the webhook securityKey only once in the subscription creation response. ml-connector must store this key securely and encrypted immediately, because it is used to verify HMAC-SHA256 signatures on all subsequent webhook payloads and cannot be retrieved again. If the key is lost, the webhook subscription must be recreated.