Payroll to finance
Nmbrs to Visma.net ERP integration: every payroll run as a journal in Visma.net
With an integration between Nmbrs and Visma.net ERP, every completed payroll run in Nmbrs automatically becomes a journal in Visma.net, per cost centre and cost unit and in the right post period. Every Nmbrs company posts into its own Visma.net company, and a run that has already been posted never goes in a second time.
What the integration does
Organisations that run payroll in Nmbrs and use Visma.net ERP for accounting download the journal after every run, convert it in Excel and post it as a general journal. An extra run mid-month is sometimes forgotten, and every January the question is which year the last December run belongs to.
- Payroll completes a run in Nmbrs, as today.
- KoppelHet sees the new run in the company's run list and fetches the journal, split over cost centre and cost unit, for the year of the run.
- The Nmbrs accounts and cost centres are translated to accounts and subaccounts of the Visma.net company that belongs to that BV.
- KoppelHet checks whether the post period is open, creates the journal and releases it after a successful check.
- The Visma.net batch number is stored per run in the KoppelHet platform, so finance can find every run.
What to watch for with Nmbrs and Visma.net ERP
- Nmbrs provides the journal per run in several variants, including per cost centre with cost unit or per employee. For Visma.net we use the variant with cost centre and cost unit, because it fits the subaccount exactly and no amounts per person end up in the ledger.
- The standard Nmbrs journal variants take the company's active year. There is also a variant where you pass the year yourself. KoppelHet uses that one, so a December run that only happens in January still lands in the Visma.net December period, as long as finance keeps that period open.
- With four-weekly payroll Nmbrs writes a period as year, number and the type 4W. Visma.net posts in the financial periods finance has set up, usually twelve a year. The integration places each Nmbrs period in the right Visma.net period through a fixed table.
- Nmbrs keeps a run list per company per year. KoppelHet compares that list with what is already in Visma.net. An extra run or correction run in the same month therefore becomes its own journal and does not get lost.
- One Nmbrs environment can contain several companies, while every Visma.net company has its own access and its own API limit. KoppelHet records per Nmbrs company which Visma.net company the journal belongs to and processes the companies one after another.
- Visma.net only allows posting in a period that is active and still open in the general ledger. If it is not, KoppelHet does not create the journal and asks finance to open the period or choose another one.
- Nmbrs and Visma.net both belong to Visma, but the journal does not move from one to the other by itself. The integration fills that gap without an export file, and the journal check stays with finance in Visma.net.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Can the journal go to Visma.net per employee?
Nmbrs offers that variant, but we advise against it. Finance posts per account and cost centre, and salaries per person do not belong in the ledger.
Who releases the journal in Visma.net?
By default the integration, after the checks on period and accounts. If finance wants to release it, KoppelHet puts the journal on hold.
What happens with a correction run?
It becomes its own journal with the run number in the description, in the period it belongs to. If that period is already closed, KoppelHet asks finance first.
Do cost centres also go from Visma.net to Nmbrs?
Not in the first version. Nmbrs can add or update cost centres through an integration, so this can be added later as an extension.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Nmbrs through the SOAP API, CompanyService - Run_GetList for the runs per year and Journals_GetByRunCostCenterCostUnitPerYear for the journal as XML. The SOAP API stops in 2027; as soon as the REST API provides the journal, we switch.
- Visma.net ERP through POST /v2/journaltransaction (postPeriod, transactionDate, description, lines with accountNumber, subaccount as segmentId and segmentValue, debitAmountInCurrency and creditAmountInCurrency), then the release action on the journal. Beforehand GET /v1/financialPeriod (active, closedInGeneralLedger).
- Visma Connect with OAuth 2.0 client credentials and a tenant_id per Visma.net company. API limits per combination of company and client, visible in the X-RateLimit headers.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Nmbrs | Field in Visma.net ERP | Notes |
|---|---|---|
Grootboekrekening uit het journaal | accountNumber | Through a lookup table per company |
Kostenplaats | subaccount (segment kostenplaats) | |
Kostendrager | subaccount (tweede segment) of project | Choice per Visma.net setup |
Bedrag debet of credit | debitAmountInCurrency of creditAmountInCurrency | |
Jaar en periode van de run | postPeriod en transactionDate | Four-week periods mapped to months through a fixed table |
Bedrijf | Visma.net-bedrijf (tenant) | One fixed mapping per Nmbrs company |
Run-ID, jaar en bedrijf | description | Makes the posting traceable to the run |
Related
ADP Workforce Now → Nmbrs
ADP Workforce Now to Nmbrs integration: the Dutch payroll group from ADP in the right Nmbrs company
AlexisHR → Nmbrs
AlexisHR (Simployer One) to Nmbrs integration: Dutch employees into payroll
BambooHR → Nmbrs
BambooHR to Nmbrs integration: Dutch payroll next to a global HR system
Bullhorn → Nmbrs
Bullhorn to Nmbrs integration: placements with hourly pay and end date in payroll