A retroactive pay rise reaches payroll correctly when the integration passes on the effective date from the HR system instead of the date on which HR entered the rise. AFAS, Loket or Nmbrs then settles the difference over the right months itself in the next run.
It goes wrong with integrations that only pass on today's state. A rise effective July, entered in September, then becomes a rise effective September. The difference only surfaces when a payslip is wrong.
Entry date and effective date are two different things
HR works with two dates at once. The entry date is the day someone puts the change into the system. The effective date is the day the change applies. For payroll, only the second counts.
Workday, HiBob and SAP SuccessFactors store that effective date per record. A salary then has a history: this amount up to and including June, that amount from July. The integration has to read those records. If it only reads the "current salary" field, the history is lost along the way.
Three situations every integration must handle
At the start, we test three kinds of change in the test environments of both systems.
- Retroactive. The rise takes effect before the entry date. The integration passes on the original effective date, and AFAS, Loket or YouForce settles the difference over the right months.
- Future-dated. In March, HR records a departure as of June, or a rise as of next month. It is ready in payroll with its own effective date, and is only paid in that period.
- Across the year end. Loket settles retroactive changes itself within the same year. If the effective date crosses the year end, the payroll team gets a notification, because such a correction has to be handled deliberately.
Seeing future changes
Future-dated changes are harder than they look, because HR systems do not always show them. SAP SuccessFactors shows only what applies today by default. Without a targeted request for future records, a new starter as of the first of next month is invisible.
Personio and HiBob only report a start or departure on the day itself. If the integration waits for that event, a new colleague who starts on the first reaches the run too late. KoppelHet therefore acts as soon as the contract or the leaving date is in HR.
How payroll processes a date
Each payroll system handles effective dates differently, and the integration has to follow it.
Nmbrs works per pay period. A new version goes to the period in which the effective date falls, and a retroactive change is reported separately.
In Loket, pay and working hours are separate parts, each with its own start date. A change in hours therefore does not close a pay record. Loket does allow only one record per start date. SuccessFactors sometimes records several changes on one day, and then the last change of that day counts.
A bank account has no effective date in HiBob, while YouServe asks for one. The new IBAN then applies from the next salary payment.
What must not go through
An effective date says nothing about approval. A rise that is still awaiting approval in Sympa or Sage People does not go into the payroll run. Only approved records go through.
The other way round, HR can remove a record. If HR deletes a salary record in HiBob that was entered by mistake, no event is sent. For the integration, that change does not exist. That is why KoppelHet compares HR with payroll before every submission deadline. The difference then shows in the platform, and the payroll team resolves it before the run.
How KoppelHet builds this
Effective dates are the part a payroll integration is judged on. KoppelHet builds each integration per organisation on its own platform, tests future-dated, retroactive and year-end rises before go-live, and then compares HR with payroll before every submission deadline.
Examples are Workday with AFAS, SAP SuccessFactors with Loket and Personio with Nmbrs. More on this topic is under effective dates and retroactive changes and on the page about payroll integration. A back payment settled in payroll then reaches the payroll journal; how a correction lands in the right accounting period there is covered under correction runs and periods.