Payroll to finance
Loket to Visma.net ERP integration: Loket journal runs as a general ledger journal in Visma.net, per branch and posting period
With an integration between Loket and Visma.net ERP, every Loket journal run automatically becomes a general ledger journal in Visma.net, in the right posting period and with cost centre and cost unit as subaccount. The journal is ready for finance in Visma.net, and the run then shows as exported in Loket.
What the integration does
Organisations that process payroll in Loket and keep the books in Visma.net ERP convert the Loket journal into a Visma.net journal by hand after every payroll run. With a recalculation or a four-week period the posting period then easily goes wrong, and payroll cannot see whether finance already has the journal.
- Payroll journalises in Loket, as today.
- KoppelHet fetches the consolidated results of the journal run.
- KoppelHet determines the Visma.net period and checks that it is still open in the general ledger.
- The journal arrives in Visma.net with account and subaccount per line, and with the total as control total.
- Finance reviews and releases the journal; KoppelHet marks the run as exported in Loket.
What to watch for with Loket and Visma.net ERP
- For journal data Loket only has OAuth connections with a few accounting packages, such as Exact Online, Twinfield and AccountView. Visma.net ERP is not among them. That is why KoppelHet requests the journal run results itself and turns them into a journal transaction in Visma.net.
- Visma.net expects the posting period as month and year (MMYYYY). If Loket pays every four weeks, there are thirteen pay periods and twelve posting periods. KoppelHet uses the period table from the Loket journal configuration, so period 13 does not arrive at Visma.net as a month that does not exist.
- Visma.net records per financial period whether it is closed in the general ledger. KoppelHet requests that before the journal is submitted. If the period is closed, the run stays failed in Loket with that reason, instead of the journal landing in another period.
- A journal transaction in Visma.net can be on hold and is only processed with a separate release action. KoppelHet puts the payroll journal on hold, so finance reviews it first. Automatic release can be added later as an extension, once the first months have gone well.
- Visma.net accepts a control total per journal. KoppelHet fills in the total of the Loket run, so a line that would go missing on the way is noticed immediately on saving instead of at month-end close.
- Cost centres and cost units are segments of one subaccount in Visma.net. Loket returns them as separate fields per line. KoppelHet places them in the segments finance designates; a combination that does not exist as a subaccount becomes an alert instead of a posting on a general account.
- After a change in cost allocation, a recalculation in Loket only returns the shift between cost centres. KoppelHet posts it as a new journal transaction with its own description, so the first journal in Visma.net stays untouched.
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
Does the integration also release the journal?
Not in the first version. The journal stays on hold until finance releases it. Automatic release can come later.
What happens with a closed period?
Then the journal does not go to Visma.net and the run shows as failed in Loket. After reopening or another agreement with finance, the run goes again.
Does this work with several employers in Loket?
Yes. Per payroll administration we record which Visma.net company or branch the journal belongs to.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Loket through the REST API with OAuth: GET .../journalruns/{journalrunId}/results with consolidate=Always (generalLedgerAccount, costCenter, costUnit, debetAmount, creditAmount; no results for journalRunStatus 0 to 3), the journal configuration (methodForDeterminingAccountingPeriod, payrollPeriodFinancialPeriodMapping) and PATCH .../journalruns/{journalrunId} with markAsSuccessfullyExported or MarkAsProcessingFailed.
- Visma.net ERP through the Service API: GET /v1/financialPeriod (active, closedInGeneralLedger), POST /v2/journaltransaction (hold, transactionDate, postPeriod as MMYYYY, branch, description, controlTotalInCurrency, journalTransactionLines with accountNumber, subaccount as segmentId and segmentValue, project, debitAmountInCurrency, creditAmountInCurrency, transactionDescription) and POST /v2/journaltransaction/{journalTransactionNumber}/action/release. Visma Connect with OAuth 2.0 client credentials; limit per hour per combination of company and client, tracked in the X-RateLimit headers.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in Visma.net ERP | Notes |
|---|---|---|
generalLedgerAccount | accountNumber | Lookup table if the account numbers differ |
costCenter | subaccount (segmentId en segmentValue) | Segment for cost centre |
costUnit | Tweede subaccountsegment of project | Configuration choice of finance |
debetAmount en creditAmount | debitAmountInCurrency en creditAmountInCurrency | |
Loonperiode van de run | postPeriod (MMJJJJ) | |
Loonadministratie | branch of Visma.net-bedrijf | Fixed mapping per employer |
Som van de regels | controlTotalInCurrency |
Related
ADP Workforce Now → Loket
ADP Workforce Now to Loket integration: hires, pay, hours and bonuses from ADP to the Dutch payroll run
AlexisHR → Loket
AlexisHR to Loket integration: employees of the Dutch company from AlexisHR into payroll
BambooHR → Loket
BambooHR to Loket integration: HR changes from BambooHR for Dutch payroll
Bullhorn → Loket
Bullhorn to Loket integration: placement as a concept employee in the right payroll administration