Visma and Basware integration

What moves between them

The main flow runs from Visma into Basware. ml-connector reads supplier records, purchase orders, and invoices from Visma on a schedule you set and pushes them into Basware's P2P API. Supplier master data flows first so purchase orders and invoices reference vendors that already exist in Basware. Purchase orders are matched against Basware's three-way matching engine, and invoices are fed into Basware's approval workflows. The flow is one-way (Visma to Basware); payment confirmations and exceptions flow back into Visma through a separate audit trail if configured.

How ml-connector handles it

ml-connector stores both OAuth2 credential sets encrypted, applies the ipp-company-id header on every Visma call, and refreshes the Visma token when it expires. For Basware, it detects the customer's region from the provisioned credentials and routes calls to the correct regional base URL (EU, US, AU, CA). It reads Visma suppliers first to populate Basware's vendor master, then polls for new or modified purchase orders and invoices via lastModifiedDateTime. When events arrive at Basware webhooks (if enabled), ml-connector validates the HMAC-SHA256 signature before processing. Because Visma webhooks have no automatic retry, ml-connector backs off on 429 responses from Basware and carries the audit trail so any failed record can be replayed once the downstream issue is resolved.

A real-world example

A mid-sized manufacturing company uses Visma for accounting and procurement in the Nordic region and Basware for AP Automation to streamline invoice approval across multiple sites. Before the integration, procurement staff entered purchase orders into both systems and the AP team manually matched invoices to POs in Basware, causing delays and occasional three-way matching failures. With Visma and Basware connected, each purchase order created in Visma flows into Basware within minutes, invoices from suppliers are automatically matched, and approval workflows start without manual data entry. Month-end AP close is faster, and the team recovers hours previously spent on double-entry.

What you can do

• •Sync supplier master data from Visma to Basware so purchase orders and invoices reference valid vendors.
• •Push purchase orders from Visma into Basware's three-way matching engine on a configurable schedule.
• •Send invoices from Visma to Basware for processing, approval routing, and automated exception handling.
• •Route API calls to the correct Basware regional instance (EU, US, AU, CA) based on customer provisioning.
• •Validate Basware webhook signatures (HMAC-SHA256) and replay failed records with a full audit trail.

Questions

Which direction does data move between Visma and Basware?

The main flow is Visma to Basware. Suppliers, purchase orders, and invoices move from Visma into Basware's P2P API for matching and approval. Payment confirmations and AP exceptions flow back into Visma through the audit log if configured. Basware does not write financial entries back into Visma's general ledger.

How does ml-connector handle Visma's tenant routing and Basware's regional deployment?

ml-connector applies the ipp-company-id header on every call to Visma to route requests to the correct tenant. For Basware, it reads the customer's region from the provisioned credentials and routes all calls to the matching regional base URL (EU, US, AU, CA). Both systems use OAuth2, and ml-connector stores and refreshes tokens as needed.

What happens if a webhook or API call fails?

Visma webhooks have no automatic retry, so ml-connector polls Visma on a schedule to catch missed events. For Basware, ml-connector backs off on HTTP 429 responses and retries. Every record carries a full audit trail, and failed records can be replayed once the downstream issue is fixed.