For a group with multiple bv's (Dutch private limited companies), you post the payroll journal by linking each employer in the payroll to one fixed ledger in the ERP, and by creating a separate journal per employer. An employer in AFAS, a Nmbrs company or a YouForce client then always posts to its own ledger in Exact Online, AllSolutions or 4PS, or to its own subsidiary in Oracle NetSuite.
A group with multiple bv's usually runs payroll in one payroll environment, but keeps the books per operating company. This article is for the controller or finance manager who has to get that right every month, with a payroll bureau or an in-house payroll team in between.
One payroll environment, several sets of books
In the payroll, all the bv's sit together. In the ERP, each operating company has its own books. Each package uses a different name for that: an administration, a company, a subsidiary or a branch. The journal of one bv never belongs in the books of another.
Without a fixed link, someone picks the right ledger again every month. One wrong choice produces a posting that finance has to reverse.
Fixed pairs of employer and ledger
At the start, we record for each employer, Nmbrs company or YouForce client which ledger its journal goes to. KoppelHet checks those pairs on every run. A run can therefore never end up in the books of another company.
Three rules apply:
- One employer, one journal. A journal never spans two ledgers. In NetSuite, a journal entry belongs to exactly one subsidiary.
- Cost centres per pair. Cost centres are matched per pair of employer and ledger, so a cost centre of one bv is never picked in another.
- Euros to the Dutch entity. The journal goes to the Dutch entity in euros. Finance converts to the group currency at consolidation.
How each ERP handles multiple companies
Behind those pairs, each package has a different mechanism. That determines how the integration works.
AllSolutions always starts the integration account in one company. KoppelHet switches to the right company for each employer before the journal is recorded.
In Visma.net ERP, each company has its own access and its own API limit. KoppelHet therefore processes the Nmbrs companies one after the other. If Visma.net works with branches within one company, each employer gets a fixed branch, so the payroll costs per employer show separately in reporting.
Oracle NetSuite works with subsidiaries. A secondment entity next to the BV is its own company in Nmbrs, and becomes its own journal in NetSuite on the subsidiary it belongs to.
A group ERP for all countries
An international group sometimes has one ERP for all countries, such as Dynamics 365, Unit4 or NetSuite. The Dutch payroll journal is one of the flows into it. The integration posts only to the company or subsidiary of the Dutch entity, in euros. Other countries and the group currency stay outside the integration.
If the HR system also sits with head office, the same applies on the payroll side: only the Dutch employees go to payroll. That is covered under global HR with Dutch payroll, and how multiple bv's are set up in the payroll itself under multiple employers.
A payroll bureau without access to the ERP
If a payroll bureau working in Nmbrs runs your payroll, that bureau does not need access to the ERP. The integration has its own access to both systems, separate from the accounts of the bureau and of finance. The bureau runs payroll, finance keeps the books, and the integration carries the journal from one to the other.
How KoppelHet builds this
KoppelHet builds each integration per organisation on its own platform. We record the pairs of employer and ledger at the start and check them on every run. Multiple entities fall into our complex class; as an indication, allow three to six weeks.
Examples are AFAS with AllSolutions, Nmbrs with 4PS Construct and Nmbrs with Visma.net ERP. Read more about multiple employers and ledgers or start with payroll to finance.