Visma and Procore integration

What moves between them

Data flows bidirectionally. Visma supplier master records sync into Procore vendors, and Visma purchase orders sync into Procore commitments mapped to project-specific cost codes and dimensions. Procore payment applications and direct costs flow back into Visma by polling Procore's requisition and direct cost endpoints, then post into Visma's general ledger as journal transactions allocated to the matching cost centers. Cost codes and budget line items are aligned in both directions.

How ml-connector handles it

ml-connector stores OAuth credentials for both systems encrypted and handles Visma's tenant isolation by including the ipp-company-id header on every Visma API call. On the Procore side, it manages the 1.5-hour token expiry cycle and maps every project to a Visma dimension and cost center before syncing commitments. Because Visma webhooks have one-time delivery with no automatic retry, ml-connector polls Visma's purchase order and journal endpoints on a schedule using the lastModifiedDateTime query parameter to detect changes. Procore webhooks are enabled on the integration's registered endpoint, and ml-connector processes those events immediately for payment applications and direct costs. Optimistic locking on Visma PUT operations is handled via ETag caching, and Procore's requirement for 2xx response within 5 seconds is met by queuing inbound webhook events and responding immediately. Every record carries a full audit trail and can be replayed if a downstream GL post fails.

A real-world example

A mid-sized construction contractor manages multiple building projects across regions. Finance uses Visma.net ERP for accounting and GL management. Project teams use Procore for daily cost tracking, commitments, and payment applications. Before integration, the project accountant exported requisitions from Procore weekly and manually entered the actuals into Visma to reconcile costs against budget, a process that created delays and reconciliation gaps between the two systems. With Visma and Procore connected, payment applications and direct costs flow into Visma automatically at the end of each billing period, allocated to the correct project cost center, and supplier invoices in Visma sync into Procore as vendor records. Month-end close begins with project costs already rolled up and reconciled, eliminating the manual export-and-entry step.

What you can do

• •Sync Visma suppliers into Procore vendors with automatic updates when supplier records change.
• •Move Visma purchase orders into Procore commitments, mapped to project cost codes and budget line items.
• •Pull Procore payment applications and direct costs back into Visma and post them as GL journal transactions.
• •Align cost codes, dimensions, and budget between Visma and Procore so costs land on valid GL accounts.
• •Handle Visma's tenant isolation, Procore's OAuth token refresh cycle, and optimistic locking constraints with automatic retry and full audit trail.

Questions

Which direction does data move between Visma and Procore?

Data flows both ways. Visma suppliers and purchase orders sync into Procore vendors and commitments, while Procore payment applications and direct costs flow back into Visma for GL posting. Cost codes and dimensions are aligned in both directions to ensure every cost posts to the correct GL account and project center.

How does the integration handle Visma's one-time webhook delivery and lack of automatic retry?

Visma webhooks are one-time only with no automatic retry if the receiver is unavailable. ml-connector overcomes this by polling Visma's purchase order and journal endpoints on a schedule using the lastModifiedDateTime query parameter to detect changes, ensuring no records are missed if a webhook fails to reach the endpoint.

What mapping is needed for Visma purchase orders to become Procore commitments?

Each Procore project must be pre-mapped to a Visma dimension and cost center. When a Visma purchase order syncs, ml-connector matches it to the corresponding Procore project and maps GL accounts to Procore cost codes. Budget line items are aligned so cost actuals land on valid project dimensions in both systems.