Visma and Rippling integration

What moves between them

Employee records and department assignments flow from Rippling into Visma. When an employee is hired, terminated, or rehired in Rippling, those changes sync to Visma's employee master, tagged with the matching Rippling department. Accounting dimensions such as cost centers from Rippling are mapped to Visma dimensions so payroll allocations land on the correct GL accounts. Changes to compensation and department assignment in Rippling trigger updates to the matching Visma records on a schedule you configure. The flow is unidirectional from Rippling to Visma; Visma is the source of truth for GL posting and financial reporting.

How ml-connector handles it

ml-connector authenticates to both systems independently: Visma via OAuth2 client credentials with the tenant_id and ipp-company-id header on all calls, and Rippling via API Key (if direct integration) or OAuth2 with appropriate scopes (if App Shop). Because Rippling direct API key integrations do not receive webhooks, ml-connector polls Rippling's employees endpoint at a cadence you set, filtering by updated_at to catch only recent changes. Visma webhooks are optional; polling is always supported. Employee records from Rippling include department, location, and accounting dimension assignments that map to Visma dimension sublegers. ml-connector matches Rippling departments to Visma cost centers before writing, ensuring no employee record lands on a nonexistent dimension. Tokens are refreshed automatically when they expire, and failed employee syncs are retried with exponential backoff. Every record carries a full audit trail showing source, target, mapping, and result.

A real-world example

A mid-sized Nordic manufacturing company runs Visma.net ERP for accounting and GL posting, and Rippling for payroll and HR across three offices and a distribution center. Before integration, the finance team manually reviewed hire and termination reports from Rippling each month, created matching employee records in Visma for GL allocation, and matched Rippling departments to Visma cost centers by hand. Month-end GL reconciliation revealed discrepancies between HR headcount and the labor cost accounts because employee changes were delayed or miscoded. With Rippling and Visma connected, new hires flow into Visma automatically with the correct Rippling department mapped to the corresponding Visma cost center, terminations remove the employee from active payroll allocation, and compensation changes update GL dimensions immediately. The finance team no longer re-enters employee data and can close the books faster because labor accounts are aligned to current headcount and department structure.

What you can do

• •Sync employee hire, termination, and rehire events from Rippling into Visma with the correct department and cost center mapping.
• •Map Rippling accounting dimensions to Visma GL dimensions so payroll allocations land on the right accounts.
• •Authenticate Rippling via API Key or OAuth2 and Visma via OAuth2 client credentials with automatic token refresh.
• •Poll Rippling on a schedule you control, with retries and full audit trails for every employee record.
• •Keep Visma employee master current with changes to department, location, and compensation from Rippling.

Questions

Which direction does employee data flow between Rippling and Visma?

Employee records flow from Rippling into Visma. Hires, terminations, rehires, and department changes in Rippling sync to Visma's employee master so GL allocation is always current. Visma remains the source of truth for financial reporting and GL posting; Rippling is the master for workforce and payroll events.

How does ml-connector handle Rippling's restriction on webhooks for direct API key integrations?

Direct API key integrations cannot receive Rippling webhooks, so ml-connector polls the Rippling employees endpoint on a schedule you set, using the updated_at filter to capture only recent changes. This polling approach ensures no employee changes are missed and works for both API Key and OAuth2 authentication methods.

What happens if a Rippling department does not exist in Visma as a cost center?

ml-connector maps Rippling departments to Visma dimensions before writing. If a department has no matching Visma cost center, the record is flagged in the audit log and the sync waits for the dimension to be created in Visma or the mapping to be updated, preventing orphaned employee records and GL posting errors.