Visma and Cleo integration

What moves between them

Purchase orders and supplier invoices from Visma.net ERP flow into Cleo as EDI transactions (850 for POs, 810 for invoices). Purchase receipts from Visma trigger 856 ASN (advance ship notice) transactions in Cleo so Cleo reflects goods received. Supplier master data such as names, addresses, and tax identifiers syncs in both directions to keep Visma suppliers aligned with Cleo trading partners. All transactions carry full audit trails and can be replayed if a downstream action fails.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents the Visma tenant_id and ipp-company-id header on each call, refreshing the Visma OAuth token when needed. For Cleo, it exchanges the username and password for a Bearer token using the password grant flow and refreshes it on expiry. Because Visma webhooks have no automatic retry and Cleo has no programmatic webhook API, ml-connector polls both systems on a schedule tied to your procurement cycle. It queries Visma's purchase orders and invoices using lastModifiedDateTime to fetch only records changed since the last run, transforms them into EDI 850 and 810 messages, and files them into Cleo as JSON payloads via the Cleo REST API. Supplier address changes in Cleo are read back and validated against Visma's supplier entities so trading partner master data stays in sync. Visma requires optimistic locking with ETag on update calls, and ml-connector includes the If-Match header on every PUT request. Visma test clients are rate-limited to 500 calls per hour per company, so ml-connector batches requests and backs off on 429 responses.

A real-world example

A mid-sized logistics and distribution company in Sweden uses Visma.net ERP for procurement and accounts payable, and Cleo Integration Cloud to manage EDI with 200+ suppliers. Before the integration, the procurement team received purchase orders and delivery updates separately in Visma and Cleo, leading to misaligned inventory and duplicate data entry during invoice reconciliation. With Visma and Cleo connected, every purchase order from Visma flows into Cleo as an 850 EDI transaction in real time, suppliers respond with 856 advance ship notices, and receiving confirmations post back into Visma automatically. The team no longer manages two separate supplier master lists and invoice matching happens in Cleo while Visma payables stays in sync.

What you can do

• •Sync purchase orders and supplier invoices from Visma.net ERP into Cleo as EDI 850 and 810 transactions.
• •Map Visma purchase receipts to Cleo 856 advance ship notice transactions so goods received updates flow both ways.
• •Keep Visma supplier master data aligned with Cleo trading partner records and validate address changes across both systems.
• •Authenticate Visma with OAuth 2.0 and tenant credentials, and Cleo with password grant, managing token refresh and expiry.
• •Poll on a schedule aligned with your procurement cycle, with retries on rate-limit responses and full audit trails on every record.

Questions

Which direction do purchase orders and invoices move between Visma and Cleo?

Purchase orders and invoices move from Visma.net ERP into Cleo as EDI transactions (850 for POs, 810 for invoices). Supplier address changes and trading partner updates may flow from Cleo back to Visma to keep master data aligned. Visma is the source of procurement truth, and Cleo is the integration hub.

Does Visma support webhooks, and if so, why does ml-connector poll instead?

Visma offers webhooks, but they are one-time delivery with no automatic retry if the receiver is unavailable. Cleo does not expose a programmatic webhook API, so ml-connector polls both systems on a schedule. This ensures no events are lost and integrations continue if either system is temporarily unreachable.

How does ml-connector handle Visma rate limits and the tenant-specific headers?

Visma test clients are rate-limited to 500 calls per hour per company, and ml-connector batches requests and backs off when it receives a 429 response. Every Visma API call includes the ipp-company-id header and the OAuth 2.0 Bearer token, and ml-connector refreshes the token on expiry so rate limits are never caused by authentication failures.