Uren overtypen naar de salarisadministratie: zo koppel je het aan Nmbrs

Kort antwoord. Je hoeft gewerkte uren niet elke maand handmatig over te typen naar Nmbrs. Je koppelt je urenregistratie via een directe integratie of een eigen bouwstuk dat uren ophaalt, omzet naar het juiste loonformaat en klaarzet voor verwerking. Zo kloppen de cijfers, met minder handwerk en minder fouten.

Elke maand dezelfde rituele dans. Iemand exporteert de gewerkte uren uit het planning- of urenregistratiesysteem, plakt ze in Excel, telt overuren en toeslagen bij elkaar op en typt het resultaat regel voor regel over in de salarisadministratie. Dat is precies het soort proces dat ik in de praktijk telkens weer tegenkom, en het is precies het soort proces dat ik opnieuw inricht.

Waarom dit overtypen blijft misgaan

Handmatig data van het ene systeem naar het andere overzetten is per definitie foutgevoelig. Een verschoven regel, een vergeten toeslag, een typefout in een aantal uren. Het verschil valt pas op als een medewerker zijn loonstrook controleert, en dan ben je al een correctie en een hoop irritatie verder. Nmbrs zelf rekent het handmatig verwerken van uren, overuren en onregelmatigheidstoeslag tot de tijdrovende salarisprocessen die je kunt automatiseren.

Maar het echte doel is niet alleen tijd besparen. Het doel is grip. Cijfers die kloppen omdat ze niet via mensenhanden zijn overgetikt. Een loonrun die je vertrouwt zonder dat iemand achteraf steekproeven hoeft te doen. Minder handwerk is daarvan het prettige gevolg, niet het hele verhaal.

Eerst het proces doorlichten, dan pas bouwen

Voordat ik ook maar één koppeling bouw, leg ik het hele traject van klok tot loonstrook naast me neer. Want veel van wat er nu handmatig gebeurt, is zo gegroeid en bestaat alleen nog omdat het altijd zo ging.

Een paar vragen die ik standaard stel:

• Welke uursoorten gaan er echt naar de salarisadministratie? Regulier, overwerk, verlof, toeslagen. En welke van die berekeningen doet iemand nu met de hand terwijl het systeem dat ook kan?
• Worden uren eerst in Excel "opgeschoond" voordat ze het salarissysteem in gaan? Dat is meestal een stap die je kunt schrappen door de bron beter in te richten.
• Hoeveel correcties achteraf zijn er per maand, en waar komen die vandaan?

Het komt regelmatig voor dat de helft van het handwerk verdwijnt zodra je het proces opschoont. Dat is een bewuste stap, geen reden om niks te bouwen. Het zorgt ervoor dat ik straks de juiste oplossing bouw in plaats van een rommelig proces te automatiseren dat ook rommelig blijft.

De koppeling die wel op jouw situatie past

Voor veel standaardsituaties is er een kant-en-klare koppeling. Urenregistratiepakketten als Keeping, Werktijden.nl, Dyflexis en Yoobi hebben een directe integratie met Nmbrs waarmee je gewerkte uren in een paar klikken doorzet. Past dat op jouw situatie, dan is dat vaak het slimste startpunt en zeg ik dat ook gewoon.

De praktijk is alleen lang niet altijd standaard. Ik zie regelmatig situaties waarin een standaardkoppeling het niet redt:

• Uren komen uit een eigen systeem, een branchepakket of een combinatie van bronnen waar geen kant-en-klare Nmbrs-koppeling voor bestaat.
• De omrekening naar looncomponenten zit vol bedrijfseigen of cao-specifieke regels die een standaardintegratie niet kent.
• Je werkt met meerdere administraties of entiteiten en moet uren consolideren voordat ze de loonrun in gaan.

Daar bouw ik de oplossing. Een workflow die de uren bij de bron ophaalt, de logica toepast die voor jou geldt, het resultaat omzet naar het importformaat dat Nmbrs verwacht en de batch klaarzet, vaak via de Nmbrs API of een gecontroleerde import. Met validatie en een logboek erbij, zodat je achteraf kunt zien wat er is verwerkt en waarom. Dat onderscheid tussen kopen wat past en bouwen wat ontbreekt, is precies waar de winst zit.