With vierwekenverloning (four-weekly payroll) you record in advance, in a fixed table, which accounting period of the ERP each pay period falls in, and you post every run from AFAS, Nmbrs or YouForce as its own entry with run and period in the description. That way thirteen pay periods, correction runs and extra runs land in the right month of Exact Online, Visma.net, Unit4 or NetSuite, without duplicate or lost entries.
For finance, a payroll run is often simply "the payroll costs for March". For the payroll administration it is one of several runs, in a period that does not always coincide with a calendar month. This article is about that mismatch, and the agreements you make for it.
Thirteen periods, twelve months
If you pay every four weeks, you have thirteen periods. Finance usually posts in twelve months. Somewhere in the year two pay periods therefore fall in the same accounting month, or a period runs over the end of a month.
The solution is a fixed table that links each four-week period to an accounting period of the ERP. You set that table at the start with finance and the payroll administration, for the whole year. After that nobody has to choose per run.
One possible agreement is the period of the end date. An AFAS period that does not coincide with a calendar month is posted in Unit4, by agreement, in the period of the end date.
More than one run per period
A pay period does not always produce one run. There is a correction run after approval, or an extra run for a bonus. Without an agreement, a correction is posted in the wrong month, a run is posted twice, or an extra run goes missing.
That is why every run becomes its own entry:
- Run and period are in the description, so finance sees which amount belongs to the correction.
- The original entry is not touched.
- KoppelHet compares the payroll's list of runs with what is already in the ERP. An extra run thus becomes its own journal and does not go missing.
- If the same period comes out of the payroll again after a correction, KoppelHet recognises that by the document number and sets the correction aside, ready to post.
If required, AFAS shows a correction period together with the main period. The integration posts only the rows of the approved processing, so a main period never enters the ERP twice.
A negative correction
A correction can also produce a negative total, for example when too much was paid. How you post that differs per ERP. For Visma.net ERP, KoppelHet swaps debit and credit instead of posting a negative amount.
The December run that runs in January
The payroll run for December sometimes only runs in January. Nmbrs links the journal to the company's active year. A December run that runs in January therefore needs an agreement.
By agreement, KoppelHet posts such a run in the old financial year, as long as finance has that period open. We test a correction run and the year-end changeover before go-live.
When the month is already closed
Finance closes months. If a correction for that month comes in afterwards, the integration may not choose another period on its own.
Before posting, KoppelHet checks whether the period exists in the ERP and is open. If it is already closed, the journal is held and KoppelHet asks finance for a period.
An error in a period that has already been posted needs something else again. In Exact Online a posted general journal entry can no longer be changed. We solve it with a reversing entry followed by the correct journal, so the history stays visible.
How KoppelHet builds this
KoppelHet builds every integration per organisation on its own platform. We set the period table and the agreements on corrections at the start with finance and the payroll administration. After an outage the integration can safely retry, because it keeps track of which runs have already been posted.
Examples are Nmbrs with Visma.net ERP and AFAS with Visma.net ERP. Read more about correction runs and periods and about payroll to finance. A correction run can start with a retroactive change in HR; how that reaches the payroll is described under effective dates and retroactive changes.