Urenregistratie koppelen aan de loonadministratie

Bij veel bedrijven staat urenregistratie los van de loonadministratie. Medewerkers klokken in via een tijdregistratie-app, een rittenlijst of een simpel Excel-bestand, en aan het einde van de loonperiode zet iemand die uren handmatig over in het salarispakket. Bij een paar vaste medewerkers met een vast rooster is dat te overzien. Bij oproepkrachten, ploegendiensten of medewerkers met veel overwerk wordt het al snel foutgevoelig: een verkeerd getypt getal, een vergeten verlofdag, of uren die in de verkeerde loonperiode terechtkomen.

Dat overtypen is ook een moment waarop niemand meer controleert of de onderliggende registratie klopt. De persoon die de uren overneemt, ziet een totaal per medewerker, niet de losse dagen waaruit dat totaal is opgebouwd. Fouten in de brondata reizen dus gewoon mee naar de loonstrook.

Een koppeling tussen het urenregistratiesysteem en de loonadministratie vervangt dat handmatige overtypen door een export of synchronisatie. Dat verandert niets aan de juistheid van de oorspronkelijke registratie — het verandert alleen dat de uren, goed of fout, zonder extra invoerfout in de loonadministratie belanden.

Er zijn grofweg twee routes. De eerste is een kant-en-klare koppeling tussen je urenregistratietool en je loonpakket, zoals die tussen TimeChimp en Loket. Volgens TimeChimps eigen uitleg werkt dat in twee richtingen: medewerkers worden vanuit Loket ingelezen in TimeChimp, en gewerkte uren worden vanuit TimeChimp per maand geëxporteerd naar Loket. Medewerkers worden daarbij gematcht op e-mailadres, en voor normale uren, ziekte-uren en verlofuren moet je vooraf aangeven welk looncomponent in Loket erbij hoort. De koppeling zit alleen in het Professional-abonnement van TimeChimp; het activeren van de Loket-app zelf is gratis.

De tweede route is een eigen koppeling via de API van het loonpakket zelf, voor wie een ander systeem gebruikt dan een kant-en-klare connector ondersteunt. Loket.nl's eigen ontwikkelaarsdocumentatie beschrijft dit via de resource Payroll Period Data: je haalt eerst de dienstverbanden op (werkgevers, medewerkers, dienstverbanden, eventueel bestaande uren en lonen), en levert daarna per dienstverband en per loonperiode de variabele gegevens aan met een PATCH-aanroep. Voor toegang moet je eerst een client en gebruiker aanvragen bij Loket; productiegegevens worden niet automatisch verstrekt.

Een koppeling werkt pas als de autorisatie en de structuur eromheen kloppen. Bij Loket controleert het systeem per werkgever of de gebruiker de juiste rechten heeft via het endpoint GetAuthorizationsByEmployerId; ontbreken die rechten, dan stopt het aanleverproces en krijg je een melding. Die rechten moeten dus geregeld zijn voordat een koppeling voor het eerst draait, niet achteraf als de eerste export misloopt.

Daarnaast moet iemand vooraf bepalen welk looncomponent bij welk type uren hoort. TimeChimp vraagt dat expliciet voor normale uren, ziekte-uren en verlofuren, en laat je optioneel per activiteit een aparte looncode meegeven voor fijnmaziger onderscheid. Zonder die mapping komen uren wel aan, maar niet op de juiste looncomponent — en dat zie je er in de salarisverwerking niet zomaar aan af.

Een laatste punt: matching tussen systemen gebeurt vaak op e-mailadres. Werkt een medewerker in het ene systeem met een werkmail en in het andere met een privéadres, dan ontstaat een dubbele of ontbrekende koppeling. Dat is geen softwarefout, maar een kwestie van vooraf de juiste gegevens invullen bij elke medewerker.

Het directe voordeel is dat niemand meer handmatig een totaal overneemt van het ene systeem naar het andere. Bij een handvol vaste medewerkers met een vast rooster is de tijdwinst daarvan beperkt — een paar minuten per loonperiode. Bij oproepkrachten, wisselende diensten of veel overwerk loopt die tijdwinst snel op, simpelweg omdat er meer losse regels zijn om over te typen en dus meer kans op een fout die je er niet zomaar uit haalt.

Een koppeling vervangt niet de controle vooraf. De uren die worden aangeleverd, zijn nog steeds de uren die in het registratiesysteem staan, inclusief eventuele fouten daarin. Wie nooit meer naar de brondata kijkt omdat het systeem het nu doet, verplaatst het risico van overtypen naar het risico van een verkeerde registratie die ongezien doorloopt naar de loonstrook.

Voor bedrijven met een klein, stabiel team weegt het instellen van een koppeling — rechten regelen, looncomponenten mappen, een duurder abonnement voor de integratie — vaak niet op tegen een kwartiertje handmatig overtypen per maand. Het wordt de moeite waard zodra het aantal medewerkers met wisselende uren groeit, of zodra er periodiek discussie ontstaat over een loonstrook die niet klopt met de werkelijk gewerkte uren.

Gebruik je al een urenregistratietool die een kant-en-klare koppeling met je loonpakket aanbiedt, dan is dat vrijwel altijd de snelste weg: geen eigen ontwikkelwerk, wel een duurder abonnement en een beperking tot wat die specifieke koppeling ondersteunt. Zo exporteert de Loket-koppeling van TimeChimp alleen medewerkers die ook via Loket zijn geïmporteerd — werknemers die los zijn aangemaakt in TimeChimp moet je eerst alsnog koppelen voordat hun uren meegaan in een export.

Bestaat er geen kant-en-klare koppeling voor jouw combinatie van tools, dan blijft een eigen koppeling via de API over. Dat vraagt development, een goedgekeurde toegang bij de leverancier van het loonpakket, en onderhoud zodra een van beide systemen zijn API wijzigt — Loket raadt aan je te abonneren op de API-changelog om dat soort wijzigingen niet te missen. Dat is alleen de moeite waard als je een reden hebt om niet over te stappen naar een systeem waarvoor wél een bestaande koppeling bestaat.