Payroll integration
Keka to Nmbrs integration: HR changes of the Dutch entity from Keka to Nmbrs
With an integration between Keka and Nmbrs, new employees, salary changes and approved exits of the Dutch entity go from Keka to the right Nmbrs company, in the period in which the effective date falls. The payroll bureau no longer retypes anything from Keka and keeps the Dutch setup such as collective agreement, pension and payroll tax credit in Nmbrs itself.
What the integration does
Groups that use Keka for HR and Indian payroll, and have the Dutch entity paid in Nmbrs by a payroll bureau, now send the bureau an Excel list every month. An exit that has not yet been approved in Keka sometimes already appears on it.
- Keka sends KoppelHet a message for a new employee, a salary change or an exit.
- KoppelHet fetches the profile and the salary record and checks whether the employee belongs to the Dutch entity.
- The employee lands in the Nmbrs company of that entity, with employment, hours and salary.
- A new salary goes to the Nmbrs period of the effective date.
- Before the cut-off KoppelHet compares Keka and Nmbrs and reports to the bureau what differs.
What to watch for with Keka and Nmbrs
- On a salary adjustment Keka sends the previous and the new amount, with both effective dates. KoppelHet uses the new effective date to pick the Nmbrs period; if it falls in a period the bureau has already closed, the bureau gets an alert instead of a silent correction.
- In Keka a salary consists of CTC, gross, net and a set of earnings and deductions under Indian rules. Nmbrs calculates gross to net itself. That is why only the fixed monthly component agreed per customer goes to Nmbrs, and no net pay or employer costs.
- The salary list in Keka can be filtered on pay group. If the Dutch entity has its own pay group, KoppelHet reads only that one; salaries of colleagues in other countries thus never end up in Nmbrs.
- Bank details in Keka have an IFSC code and an account number, no IBAN, and the profile has no BSN. Nmbrs needs both for the payroll tax return and payment. They come from custom fields in Keka, or the bureau completes them in Nmbrs.
- With fifty API requests per minute, a collective pay rise in Keka is not a matter of one request per employee. KoppelHet fetches salaries in pages of two hundred and then writes them to Nmbrs, so the limit is not hit.
- Keka shows whether an employee is in the notice period and what the status of the exit is. Nmbrs only gets the end date after approval in Keka. If an exit is cancelled afterwards, KoppelHet removes the end date in Nmbrs again.
- The payroll bureau gives the integration access in Nmbrs only to this group's companies. The bureau's other clients stay out of view, and what the integration wrote per employee is in KoppelHet's logging.
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 anything go back from Nmbrs to Keka?
Not by default. Keka can receive documents per employee; whether payslips from Nmbrs should end up there is agreed per customer.
What stays with the payroll bureau?
The Dutch setup: collective agreement, pension, payroll tax credit and the payroll run. The integration delivers the HR changes and does not overwrite those settings.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Keka is read through the Keka API (https://{company}.keka.com/api/v1), with a token from login.keka.com/connect/token (client_id, client_secret, api_key, scope kekaapi). Endpoints GET /hris/employees (filter lastModified, employmentStatus Working or Relieved) and GET /payroll/salaries (filter paygroupIds; fields ctc, gross, netPay, earnings, deductions, effectiveFrom). Fifty requests per minute; pages of at most two hundred rows.
- Webhooks through event triggers in Keka (Settings > Communications > Event Triggers), including EmployeeSalaryUpdated and exitCancelled.
- Nmbrs is written through the Nmbrs REST API with OAuth 2.0 and an employer-level login. The SOAP API stops on 1 March 2027.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Keka | Field in Nmbrs | Notes |
|---|---|---|
employeeNumber | Personeelsnummer | Key between Keka and Nmbrs |
Naam en geboortedatum | Persoonsgegevens | |
Huidig adres (straat, postcode, plaats, land) | Adres | |
joiningDate | Datum in dienst | |
exitDate na goedkeuring | Datum uit dienst | |
Groep van de Nederlandse entiteit | Nmbrs-bedrijf | One Nmbrs company per Dutch entity |
Eigen veld met uren per week | Rooster | |
Vast looncomponent met effectiveFrom | Salaris met ingangsperiode |
Related
Keka → Active Directory
Keka to Active Directory integration: domain accounts per office, with expiry on the exit date
Keka → ADP iHCM
Keka to ADP iHCM integration: salary structure, variable payouts and leavers of the Dutch pay group to ADP
Keka → AFAS Profit
Keka to AFAS integration: Dutch employees from Keka in payroll
Keka → Arbodienst (SIVI)
Keka to the occupational health service via SIVI: sickness leave requests as absence reports