HR to ERP
HiBob to Visma.net ERP integration: employees per employer from Bob as employees in Visma.net
With an integration between HiBob and Visma.net ERP, every employee of an employer that books in Visma.net automatically becomes an employee in Visma.net, in that employer's branch, with department, employee class, calendar and work email. KoppelHet sets a departure planned in advance in Bob to inactive on the day after the last working day, so expenses up to that day can still be submitted.
What the integration does
Organisations that run HR in HiBob and finance, projects and expenses in Visma.net ERP create employees in Visma.net by hand, often only when the first expense claim fails. Leavers stay active and can still claim expenses for months.
- HR creates an employee in Bob at an employer that books in Visma.net.
- As soon as Bob has a work email, KoppelHet creates the employee in Visma.net, on hold until the start date.
- A change in the work history goes through on the effective date, with only the fields that differ.
- On the day after the last working day KoppelHet sets the employee to inactive.
What to watch for with HiBob and Visma.net ERP
- Visma.net requires an email address for a new employee. In Bob the work email is often only filled in just before the start, once IT has created the account. KoppelHet waits for that work email and alerts HR if an employee still has none a few days before the start.
- Every employee in Bob belongs to one employer. Branches are read-only in the Visma.net API. KoppelHet maps every employer to an existing branch, and leaves employees of employers without a Visma.net branch out of the integration.
- Visma.net has an employee class and a calendar, Bob does not. KoppelHet derives the class from the employment type in Bob and the calendar from the site, with a table finance sets up. An unknown combination becomes an alert instead of an employee with the wrong calendar.
- A departure only arrives from Bob as a notification in the night after it took effect. An employee in Visma.net has no end date. KoppelHet therefore reads the planned leaving date from Bob itself every day and sets the employee to inactive on the day after the last working day.
- A notification from Bob only names which fields changed, not the new values. Visma.net refuses a change without the current version tag. After the notification KoppelHet fetches the values from Bob and the version from Visma.net, and then only sends the differences.
- A department in Visma.net carries an expense account and subaccount, and can be created through the API. A new department in Bob therefore does not reach Visma.net automatically: KoppelHet only creates it if finance has put the accounts for it in the table, and reports it otherwise.
- If the service user in Bob lacks the right to a field, Bob does not return it, without an error. Visma.net would refuse an empty department or calendar. KoppelHet checks for every employee that employer, department and site are present, and reports a permissions problem instead of a refused employee.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Does the manager go along for expense approval?
No. Approval runs through work groups in Visma.net, and they are not in the API's employee model. That can be added later as an extension.
Does pay data go along?
No. Visma.net only gets what is needed for hours, projects and expenses.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- HiBob through webhooks v2 (employee.created, employee.updated, table.entry.created and table.entry.updated, employee.left; only IDs and changed fields; HMAC-SHA512 in Bob-Signature) and the Employee data API: POST /people/search with fields and showInactive, and the work history per employee with effectiveDate. Missing permissions lead to omitted fields without an error.
- Visma.net ERP through the Service API with Visma Connect (OAuth 2.0 client credentials, per tenant). POST /v1/employee (mandatory employeeCd, department, employeeClass, branch, calendar and contact with lastName and email), PUT /v1/employee/{employeeCd} with If-Match, status Hold, Active or Inactive. GET /v1/branch (read-only), POST /v1/department (departmentId, description, expenseAccount, expenseSubaccount).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in HiBob | Field in Visma.net ERP | Notes |
|---|---|---|
Employee ID (werk) | employeeCd | |
firstName, surname | contact.firstName en lastName | |
Werkmail | contact.email | Mandatory in Visma.net |
Employer | branch | Through a table; branches already exist |
work.department | department | |
Soort dienstverband | employeeClass | Through a table from finance |
work.site | calendar | Calendar per site or country |
Startdatum en geplande vertrekdatum | status (Hold, Active, Inactive) |
Related
Ashby → HiBob
Ashby to HiBob integration: a hire from Ashby straight in as an employee in Bob
Bullhorn → HiBob
Bullhorn to HiBob integration: an approved placement as a new employee in Bob
Carerix → HiBob
Carerix to HiBob integration: successful match becomes a new employee in Bob
Greenhouse → HiBob
Greenhouse to HiBob integration: from a hire in Greenhouse to a new employee in Bob