Worked hours and allowances only reach payroll correctly if each hour type from scheduling is mapped in advance to one pay component in the payroll system. That mapping table, agreed with the payroll team before the first payroll run, determines whether an hour from Dyflexis, Quinyx, Planday or Protime lands as the right pay component in AFAS, Visma Raet YouForce, Loket or Nmbrs.
This article is about that mapping: why it is needed, which choices it contains and where it goes wrong in practice. The wider story of hours to payroll is on the page worked hours and allowances to payroll.
Why scheduling and payroll do not understand each other
A scheduling system and a payroll system describe the same hours in different ways. Dyflexis gives each part of the hours its own name. Loket recognises a pay component by a number. Planday works with salary codes, YouForce with element codes, and Deputy with export codes that have to become a pay component in AFAS.
Without a mapping, you have two options: someone converts an export by hand every month, or hours end up on the wrong component. You notice both only on the payslip.
Examples of the mapping we record per customer:
- a column from Dyflexis to a pay component number in Loket;
- a salary code from Planday to an element code in YouForce;
- an export code from Deputy to a pay component in AFAS.
Sending hours, not amounts
Some scheduling systems calculate an amount themselves. Planday does that per shift. AFAS calculates pay itself, with the cao (collective labour agreement) and its own rates. If you send both, there are two truths about the same pay.
KoppelHet therefore sends hours per type. If scheduling already calculates an amount and the payroll system calculates its own, we leave that amount out. The payroll system stays leading for pay.
Allowances need an extra choice. An allowance in time goes as hours, an allowance in money as a pay component. That way Nmbrs, for example, pays each part in the way it is set up for.
Adding up the way the payroll system wants
A mapping table says which component, but the level of delivery also has to fit. YouForce takes a total per pay component, date and employment contract. Protime delivers minutes per day, which we add up per pay period before they go to AFAS, for example. With an integration of Protime with AFAS, the integration does that conversion, so the payroll team does not have to do it by hand.
If you work with multiple employers or bv's (Dutch private limited companies), the mapping also includes the destination. The location or department in scheduling determines which employer in AFAS or which company in Nmbrs the hours go to.
Edge cases you want to know in advance
Most errors sit in situations that affect only a few employees. A few from practice:
- Hour type without a pay component. If a new hour type appears in scheduling that is not yet in the table, the integration reports it. That way no hours drop out unseen.
- Part-timers in AFAS. AFAS only processes hour types per day for employees with a schedule per day. For part-timers with a schedule in hours per week, we post pay changes per period.
- Night shift across midnight. The shift falls on the day it belongs to according to the schedule, so the allowance falls in the right period.
- Hourly paid and salaried staff. For an hourly paid worker, an allowance hour can count as a worked hour, for a salaried employee it cannot. Per contract type, we check that an allowance hour is not also paid as a worked hour.
- Another cost centre in YouForce. Through this route, a pay component only carries a code, a value and an effective date. Hours on another cost centre we handle with a separate pay component or with the cost allocation in YouForce.
Multiple employers and duplicate postings
With multiple employers or bv's, the hours go to the right employer in AFAS or the right company in Nmbrs, based on the location or department in scheduling. The integration catches duplicate postings, and approved hours go across without manual work. How late and changed hours flow after that is covered in hour corrections after payroll close.
How KoppelHet builds this
KoppelHet builds the integration per organisation on its own platform. We record the mapping table from hour type to pay component together with the payroll team, before the first payroll run. Only hours that have been approved or signed off in scheduling go across, usually daily with a final run just before the close. Per period, we report the status back, so the scheduler sees what has been posted. As an indication, allow two to four weeks until go-live.
Examples of integrations on this topic: Dyflexis with Loket, Quinyx with AFAS and Planday with YouForce. More about the whole process is on the page leave, absence and time, and about how pay components themselves are built up on pay components in the payroll integration.