Which direction does data flow between Procurify and Visma?

The main flow is Procurify into Visma. Approved purchase orders and vendor bills move from Procurify into Visma as supplier invoices and GL transactions, while vendors and account codes sync in both directions. Procurify's purchase orders are read-only in the API, so ml-connector does not write orders back to Procurify.

Why does ml-connector poll instead of using webhooks?

Procurify does not support webhooks, and Visma webhooks are sent only once with no automatic retry if the receiver is unavailable. Polling with date-range filters on both sides is more reliable and ensures no records are dropped if either system or the connector is temporarily offline.

How does ml-connector handle Procurify's OAuth tokens and Visma's different auth model?

ml-connector manages two separate OAuth token refresh cycles. Procurify tokens are valid for 24 hours and are refreshed on the same cadence, while Visma tokens are obtained on-demand and refreshed when API calls return 401. Each credential set is stored encrypted, and the audit log tracks all auth events so token expiry or refresh failures surface immediately.

VismaProcurify

Visma and Procurify integration

Procurify manages the procurement workflow from purchase request through approved order, and Visma runs your general ledger and AP function. Connecting them keeps Visma's supplier invoices in sync with Procurify's approved purchase orders and vendor bills. Approved orders and three-way-matched bills flow into Visma as supplier invoice records and AP transactions without re-keying. ml-connector handles the different OAuth models, polls both systems on a schedule, and provides a complete audit trail of every sync.

How Visma works

Visma.net ERP exposes suppliers, supplier invoices, purchase orders, purchase receipts, GL accounts, dimensions, and journal transactions through a REST API at https://api.finance.visma.net using OAuth 2.0 with client_credentials grant. Authentication requires client_id, client_secret, and tenant_id, and the API requires an ipp-company-id header on all requests. Visma supports both webhooks and polling. Webhooks are sent once with no automatic retry if the receiver is unavailable, so polling via the lastModifiedDateTime query parameter is more reliable for connectors. ETag and If-Match headers enable optimistic locking on updates.

How Procurify works

Procurify exposes vendors, purchase orders, requisitions, bills, account codes, locations, and departments through a REST API at https://<customer-domain>.procurify.com using OAuth 2.0 with client_credentials grant. The token endpoint returns tokens valid for 24 hours, and every request requires the Authorization bearer token and X-Procurify-Client header. Procurify API does not support webhooks or push notifications, so all data sync must use polling with date-range filters on endpoints like /vendors, /purchase-orders, /bills, and /account-codes. Order items and payments are read-only through the API. Purchase orders are generated from approved requisitions and order items, not created directly.

What moves between them

The main flow moves from Procurify into Visma. Approved purchase orders and three-way-matched vendor bills flow from Procurify into Visma as supplier invoices and GL transactions mapped to the corresponding Visma GL accounts and cost dimensions. Vendor and account-code data sync in both directions so Procurify purchases land on valid Visma accounts. The integration polls Procurify and Visma on a schedule independent of either system's webhook capability and retries any failed posts into Visma.

How ml-connector handles it

ml-connector stores both credential sets encrypted and manages separate OAuth token refresh cycles for Procurify (24-hour tokens) and Visma (on-demand refresh). It polls Procurify at a fixed schedule using the last_modified filter on /bills and /purchase-orders to find new records, then queries Visma's matching accounts and dimensions before posting. Each Procurify bill becomes a Visma SupplierInvoice with line items mapped to Visma accounts and dimensions. If a Visma post fails due to a missing account or dimension, ml-connector queues a retry with backoff. Webhook events from Visma (if enabled) are processed, but polling remains the primary mechanism because Visma's webhook delivery is one-time only. Every record carries a timestamp and sync status in the audit log so failed bills can be replayed when the underlying account is created.

A real-world example

A mid-market services company uses Procurify to manage purchase requests and vendor spend across three offices, and Visma to run accounting and GL close. Before the integration, the AP team waited for Procurify's end-of-month report, manually verified bills against POs, then re-entered invoice headers and line items into Visma by hand. This manual step delayed GL posting until days after bills arrived and sometimes introduced coding errors. With Procurify and Visma connected, approved bills flow into Visma as full invoice records on the day Procurify marks them three-way matched, and the AP team spends month-end validating Visma's automatic postings rather than re-keying. The audit trail shows every sync so discrepancies can be traced back to the source bill.

What you can do

Post Procurify vendor bills into Visma as supplier invoices with line items allocated to the correct GL accounts and cost dimensions.
Sync Procurify vendors and Visma suppliers so new vendors in Procurify are available for coding in Visma and do not cause blocking validation errors.
Map Procurify account codes to Visma accounts and dimensions, ensuring every bill line posts to a valid Visma account.
Poll both systems on a schedule independent of Procurify's lack of webhooks and Visma's one-time-only webhook delivery.
Audit every sync with timestamp, status, and payload so failed bills can be replayed or investigated downstream.

Questions

Which direction does data flow between Procurify and Visma?: The main flow is Procurify into Visma. Approved purchase orders and vendor bills move from Procurify into Visma as supplier invoices and GL transactions, while vendors and account codes sync in both directions. Procurify's purchase orders are read-only in the API, so ml-connector does not write orders back to Procurify.
Why does ml-connector poll instead of using webhooks?: Procurify does not support webhooks, and Visma webhooks are sent only once with no automatic retry if the receiver is unavailable. Polling with date-range filters on both sides is more reliable and ensures no records are dropped if either system or the connector is temporarily offline.
How does ml-connector handle Procurify's OAuth tokens and Visma's different auth model?: ml-connector manages two separate OAuth token refresh cycles. Procurify tokens are valid for 24 hours and are refreshed on the same cadence, while Visma tokens are obtained on-demand and refreshed when API calls return 401. Each credential set is stored encrypted, and the audit log tracks all auth events so token expiry or refresh failures surface immediately.

Connect Visma and Procurify

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started