Planday logoNmbrs logo

Leave, absence and time

Planday to Nmbrs integration: approved hours as variable hours in the right period, employees back

With an integration between Planday and Nmbrs, the approved hours and supplements from Planday go per payroll period to the right company and employee in Nmbrs as variable hours and wage components. New employees, scheduled hours and leaving dates from Nmbrs come back into Planday, so scheduling and payroll work with the same people.

What the integration does

Organisations that schedule in Planday and run payroll in Nmbrs, with a separate Nmbrs company per legal entity, make a report from Planday after each period and enter the hours per company in Nmbrs. Shifts approved too late slip to the next period and are settled by hand.

  1. HR records a new employee in Nmbrs with employment and schedule.
  2. KoppelHet places the employee in the right Planday portal and department, with the Nmbrs employee number as salary identifier.
  3. After the period KoppelHet fetches the approved shifts and separates hours, supplements in money and fixed monthly salaries.
  4. Hours and supplements go to the right company in Nmbrs, in the current payroll period.
  5. Shifts from an earlier period approved later go into the current period and appear as an alert in the platform.
Planday → KoppelHet → NmbrsSOURCEPlandayTARGETNmbrsKoppelHetmapping · logging · monitoringPlanday → KoppelHet → NmbrsSOURCEPlandayTARGETNmbrsKoppelHetmapping · logging · monitoring
Out: Worked hours as variable hour component · Supplements as hours or as an amount · Company within the Nmbrs environment
Back: New employees with portal and department · Scheduled hours converted to hours per month · Deactivation on the termination date

What to watch for with Planday and Nmbrs

  • Nmbrs accepts variable hours in the company's current period. Booking hours in an earlier period only works with a separate retroactive setting, otherwise Nmbrs rejects them. KoppelHet therefore places shifts approved in Planday after closing in the current period and reports them, so payroll sees the settlement.
  • Nmbrs keeps hour codes and wage codes separate. A supplement in Planday can be a percentage on the hourly rate, but also a fixed amount per hour or per shift. KoppelHet sends time-based supplements as hours and money-based supplements as a wage component, so Nmbrs pays each part the right way.
  • Planday includes fixed monthly salaries in its payroll data when someone has a monthly salary. In Nmbrs that salary is already a fixed wage component. KoppelHet leaves out the monthly salaries from Planday, so a salaried employee is not paid twice.
  • One Nmbrs environment often contains several companies, one per legal entity. In Planday departments are usually the stores, sometimes spread over several portals in a network. KoppelHet determines the Nmbrs company per department, and stores employees by portal and employee ID together, because the same ID can recur in another portal.
  • Nmbrs records a schedule as hours per day over two weeks, so an alternating week also fits. Planday calculates contract hours per month. KoppelHet converts the two-week schedule into a monthly average, so scheduling sees how many hours someone should work on average.
  • Planday can register absence as a shift with its own shift type, such as leave or sick, with its own salary code. Such shifts are not worked hours. KoppelHet recognises them by the salary code and does not send them to Nmbrs as variable hours; which absence must land in Nmbrs is agreed with payroll.

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, architecture and compliance

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.

Price indication · Basic

Leave your work email and you see the price indication right away.

We only use your address to follow up on your question about this integration.

Frequently asked questions

Do leave balances from Nmbrs also go to Planday?

That can be added later as an extension. Nmbrs supplies the balance per leave type and Planday can post adjustments to a vacation account. We start with hours and employees.

Does the integration use the hourly rates from Planday?

No. Planday also supplies amounts, but Nmbrs calculates pay with its own rates and collective agreement. Only supplements set up in Planday as a fixed amount are sent as an amount.

Technical details for IT

For those who want to know how it works under the hood: APIs, fields and sources used.

  • Planday is read through the Payroll API (GET /payroll/v1.0/payroll with departmentIds, from, to and shiftStatus=Approved). shiftsPayroll contains per shift salaryCode, shiftTypeId, departmentId, breaks and supplements; supplementsPayroll and salariedPayroll are separate. Salary identifiers through the Pay API (salaryIdentifiers). OAuth 2.0; employeeId and departmentId are only unique within one portal.
  • Nmbrs is written through the Nmbrs REST API with OAuth 2.0 and a subscription key, per company (hour codes through /api/companies/{companyId}/hourcodes, variable hours and wage components per employee and period). In the SOAP API this is HourComponentVar_Insert and WageComponentVar_Insert; a period before the company's current period requires unprotected mode there, otherwise a TWK error follows. The SOAP API stops on 1 March 2027.
  • Planday is written through the HR API (employees with departments, employeeGroups, salaryIdentifier and workHours; deactivate with date and keepShifts).

Which fields are transferred

The key fields. The full mapping is agreed per customer.

Field in PlandayField in NmbrsNotes
portalId plus employeeIdInterne sleutel van KoppelHetA Planday employee ID is only unique within one portal
salaryIdentifierPersoneelsnummer in Nmbrs
departmentIdBedrijf (company) in NmbrsThrough a table from department to company
salaryCode van een dienstUurcode (variabele uren)
salaryCode van een toeslag in geldLooncode (variabel looncomponent)
salariedPayrollNiet overgenomenThe fixed salary is already in Nmbrs
Nmbrs rooster week 1 en 2 (terug)workHours (uren per maand)
Nmbrs voornaam, achternaam, e-mail (terug)firstName, lastName, userName en email
Nmbrs einddatum dienstverband (terug)deactivate met date

Related

Which systems do you want to connect?

Tell us which systems you use and what should happen automatically. Together we define the smallest working solution, with a clear design and a quote before building.