You import the payroll journal without Excel by fetching it directly from AFAS, Nmbrs or YouForce after every payroll run and putting it into Exact Online, Unit4, Microsoft Dynamics 365 or Oracle NetSuite as one posting, totalled per general ledger account and cost centre. The detail per employee stays in payroll, and finance checks the posting before it becomes final.
In many organisations it still goes differently. After the run, someone exports a file, adjusts it in Excel and imports it into finance. That works, until one day it does not. This article shows where that monthly routine keeps stalling.
Where the manual file comes from
AFAS no longer supports the old exports for external accounting packages. As a result, many organisations are stuck with a home-made file: an export from payroll, a few columns converted by hand, and an import into the ERP.
Every month that produces small differences the controller has to sort out. An account that does not exist, a cost centre that has just been closed, a journal that does not balance to zero. Or a run that was accidentally imported twice.
Every package wants the journal differently
Most of the manual work is in the format. Payroll and the ERP describe the same posting differently.
- AFAS keeps debit and credit separate.
- Unit4 and Business Central want one amount with plus or minus.
- NetSuite wants debit and credit per line again.
On top of that come limits per package. A posting in Unit4 may have at most 500 lines; a larger journal goes through batch processing. Exact Online and Business Central limit the number of requests. That is why KoppelHet posts the journal as one posting with lines, not line by line.
Separating account and cost centre
In AFAS, a substitution rule can extend the account number with a cost centre code. The ERP does not know those extended numbers. KoppelHet therefore reads account and cost centre separately.
Before posting, KoppelHet checks whether accounts and cost centres exist in the ERP and are open. A missing code then stands out before the batch is sent, and not at the month-end close. Where those cost centres come from and who is their source is under cost centres from the ERP.
Not posting payroll costs to projects twice
Take an organisation with field engineers. They already book their hours to projects in the ERP. If the journal then also posts the payroll costs to the project, they appear twice in the project results. In that case the journal posts to account and cost centre and not again to the project.
Control stays with finance
An integration does not mean finance loses control. The agreements are:
- The journal goes into a separate payroll journal book or as a draft. Finance posts after checking.
- Posting directly is possible, per ledger, if finance chooses that.
- A journal only goes through if it balances to zero.
- After posting, KoppelHet looks at the status in the ERP. A rejected journal appears in the platform with the reason.
- KoppelHet remembers which runs have already been posted, so a run never ends up in the accounts twice.
No amounts per person go into the ERP. Finance wants the journal at the level of general ledger account and cost centre, and project where needed.
How KoppelHet builds this
KoppelHet builds every integration per organisation on its own platform. At the start, we agree with finance at what level postings are made, in which journal book and whether finance completes the posting itself. Vierwekenverloning (four-weekly payroll), multiple bv's (Dutch private limited companies) with their own charts of accounts and reporting a rejected posting immediately are part of the design. As an indication, allow three to six weeks.
Examples are AFAS with Exact Online, AFAS with Unit4 and Nmbrs with AllSolutions. Read more about posting the payroll journal automatically or start with payroll to finance. The data payroll needs before the run is under the payroll integration.