Heeft Nmbrs een API waar je uren doorheen kunt sturen?

Ja. Nmbrs heeft een REST API met eigen registratie via het developerportaal: je maakt een app aan, krijgt een subscription key en authenticeert met OAuth 2.0. Daarnaast bestaat de oude SOAP-API nog, maar Nmbrs stopt daar per 1 maart 2027 mee. Bouw je nu iets nieuws, dan bouw je op REST. En draait er nog een integratie op SOAP, dan is dat een migratie die je beter dit jaar inplant dan in het laatste kwartaal van 2026.

Wat is het verschil tussen gewerkte uren en verloonde uren?

Gewerkte uren zijn wat een medewerker registreert. Verloonde uren zijn wat er over een periode in de loonaangifte terechtkomt, en dat is een eigen berekening: vakantie-uren, doorbetaald verlof, ADV en verzuim tellen mee terwijl er niemand aan het werk was, en niet elk overwerkuur landt in dezelfde periode als waarin het gemaakt is. Voor een rapportage over projectrendement wil je meestal beide getallen zien, juist omdat ze uit elkaar lopen.

Mag je salarisgegevens zomaar door een koppeling sturen?

Salarisgegevens zijn onder de AVG gewone persoonsgegevens, geen bijzondere. Dat is een misverstand dat je in veel offertes ziet staan. Dat maakt het niet vrijblijvend: je hebt een grondslag nodig, een verwerkersovereenkomst met iedereen die de gegevens namens jou verwerkt, en je mag ze alleen gebruiken voor het doel waarvoor je ze hebt verzameld. Wat wél bijzondere persoonsgegevens zijn: verzuim- en gezondheidsgegevens en vakbondslidmaatschap. Die zitten allemaal in een salarispakket, en die horen dus niet in een urenrapportage thuis.

Kan ik mijn urenregistratie niet gewoon in Nmbrs doen?

Voor de verloning kan dat prima: Nmbrs kent tijdregistratie, urencodes en een dashboard voor extra uren en dagen. Waar het ophoudt is projectadministratie. Nmbrs weet welke uren betaald moeten worden, niet of een opdracht binnen budget bleef. Draai je projectwerk, dan houd je een planning- of projectsysteem naast Nmbrs, en dan is de koppeling ertussen precies de plek waar het antwoord ontstaat.

Hoe lang duurt het bouwen van deze koppeling?

De techniek is niet het lange stuk. Twee tot vier weken doorlooptijd is realistisch, en het meeste daarvan gaat zitten in afspraken: welke urencode hoort bij welke soort uren, wat doe je met een medewerker die in twee opdrachten tegelijk zit, en vanaf welk verschil wil je een melding. Dat zijn geen technische vragen, en ze zijn belangrijker dan de code.

Werkt dit ook als mijn salarisadministratie bij een accountant ligt?

Meestal wel, maar het is een gesprek dat je vooraf voert en niet achteraf. Nmbrs wordt vrijwel altijd geleverd via een accountant of loonservicekantoor, en die beheert de omgeving. Voor een API-koppeling heb je toegang nodig tot die omgeving en toestemming van de beheerder. In de praktijk werken accountants hier prima aan mee, zeker als je laat zien dat je alleen aantallen ophaalt en geen bedragen.

DenkBot

Plan 30 minuten →

Nmbrs koppelen aan je urenregistratie

De meeste Nmbrs-koppelingen sturen uren één kant op: van de planning naar de loonrun. De interessante richting is de andere. Haal de verloonde uren terug, zet ze naast wat je had gepland, en je ziet voor het eerst wat een opdracht je echt heeft gekost.

Plan 30 minuten met een bouwer →Naar het rapport

Uitvoerder op een bouwplaats houdt een telefoon vast met de uren van vandaag: 8 gepland, 9,5 gemaakt

Beeld: uren van vandaag op een telefoon op de bouwplaats, gepland naast gemaakt

Wat levert een Nmbrs-koppeling je op?

Twee dingen, en het tweede is het punt.

Het eerste is het werk dat verdwijnt. Uren die nu per mail, in Excel of via een goedkeurronde naar de salarisadministratie gaan, komen automatisch in de juiste loonperiode terecht, met de juiste urencode, bij de juiste medewerker. Dat scheelt elke maand een middag overtypen en het scheelt correcties achteraf, want een overgetypt uur is een uur waar een typefout in kan zitten.

Het tweede is een cijfer dat bij bijna geen enkel mkb-bedrijf op tafel ligt: het verschil tussen wat je hebt gepland en wat je hebt verloond. Dat verschil is precies waar je marge weglekt, en het is onzichtbaar omdat de twee helften ervan in twee systemen staan die niets van elkaar weten. De planning kent geen loonperiodes, en Nmbrs kent geen opdrachten.

Deze pagina gaat over allebei: hoe je uren in Nmbrs krijgt, hoe je de verloonde uren er weer uit haalt, wat je daarbij aan persoonsgegevens wel en niet over de lijn stuurt, en wat het kost. Zoek je de bredere Nmbrs-mogelijkheden (verlof, journaalposten, mutaties), dan is het koppelingenoverzicht het betere startpunt.

Een uur is vier verschillende getallen

Voordat je iets koppelt: begrijp waarom deze vier nooit gelijk zijn. Dat is geen boekhoudkundig detail, het is de hele reden dat de koppeling iets oplevert.

Geplande uren

Wat je vooraf hebt ingeschat en ingeroosterd: acht uur op deze opdracht, twee monteurs, donderdag. Dit is het getal waarop je hebt geoffreerd.

Staat in

Planningssysteem of projecttool

Geregistreerde uren

Wat de medewerker zelf invult. Dit is meestal het getal dat je factureert, en meestal ook het getal dat het dichtst bij de waarheid ligt, als het volledig is ingevuld.

Staat in

Urenregistratie of werkbon

Verloonde uren

Het aantal uren dat over een periode daadwerkelijk in de loonaangifte terechtkomt. Een eigen begrip in de loonadministratie, en het enige getal waar je echt voor betaalt.

Staat in

Nmbrs

Gefactureerde uren

Wat er bij de klant op de factuur staat. Vaak lager dan alle drie de andere getallen, en zelden kijkt iemand na waarom.

Staat in

Boekhouding

Verloonde uren zijn het getal dat de meeste mensen verrast. Het is geen optelsom van wat er is gewerkt: doorbetaald verlof, vakantie-uren, ADV en verzuim tellen mee terwijl er niemand op een opdracht stond, en overwerk landt niet altijd in de periode waarin het gemaakt is. Bij een team van tien mensen loopt dat makkelijk honderden uren per jaar uiteen met wat er op werkbonnen staat. Precies daarom is het een goed controlegetal. Registratie kun je vergeten in te vullen; een loonrun vergeet je niet. Wie zijn geregistreerde uren naast zijn verloonde uren legt, ziet meteen waar de urenregistratie lek is, en dat is meestal bij de mensen die het drukst zijn.

Wat er heen en terug gaat.

Gewerkte uren gaan naar de loonrun, verloonde uren komen terug. Aantallen, geen bedragen.

Urenregistratie
Gewerkte uren per urencode
Nmbrs
Urenregistratie
Overwerk en toeslag op eigen code
Nmbrs
Nmbrs
Verloonde uren per periode
Urenregistratie
Nmbrs
Gepland naast verloond, per opdracht
Rapportage

Veertig gepland, vijftig gemaakt

De tien uur ertussen zijn niet verdwenen. Ze zijn betaald, alleen niet doorberekend.

Abstracte weergave van twee stapels uren naast elkaar: de rechterstapel is hoger, met de extra uren in oranje

Illustratie

Het voorbeeld hierboven komt niet uit een rekenmodel maar van een ondernemer die het zelf aankaartte: op zijn opdrachten wordt regelmatig veertig uur gepland en vijftig uur gemaakt. Die tien uur worden gewoon uitbetaald (ze staan netjes in de loonrun), maar ze staan niet op de factuur, omdat niemand op het moment van factureren wist dat ze er waren.

Reken het één keer door en het houdt op een gevoelskwestie te zijn. Tien uur per opdracht, bij een kostprijs van veertig euro per uur, is vierhonderd euro marge per opdracht. Bij drie van dat soort opdrachten per week is dat ruim zestigduizend euro per jaar, op omzet die je al hebt gedraaid. Je hoeft er niets voor te verkopen. Je moet het alleen kunnen zien.

En zien kan niet, want de twee helften van de som staan uit elkaar. Je planning weet wat er zou gebeuren en kent geen loonperiode; Nmbrs weet wat er is uitbetaald en kent geen opdrachtnummer. Beide systemen hebben gelijk, en samen zeggen ze niets. Dat is het gat dat een koppeling dicht, niet door er een nieuw systeem bij te zetten, maar door twee getallen op één regel te krijgen.

Wat je vervolgens met dat overzicht doet, is een keuze. Sommige bedrijven willen een wekelijkse mail met alleen de uitschieters. Andere willen het in hun bestaande dashboard, naast omzet en debiteuren. Daar gaat rapportages en dashboards automatiseren over. Het patroon is hetzelfde: de meting is niet het doel, het gesprek dat erop volgt wel.

Van geplande dienst tot verloond uur

Vier stappen, twee richtingen. Zo ziet de koppeling er in de praktijk uit.

Planning uitlezen

Een geplande dienst of opdrachtregel bevat een medewerker, een datum, een opdracht en een aantal uren. Die vier velden zijn genoeg; de rest laat je staan waar het staat.

Uren naar Nmbrs

De gewerkte uren gaan als urencomponent de juiste loonperiode in, op de urencode die bij die soort uren hoort. Overwerk en toeslag zijn aparte codes, geen opgeteld totaal.

Verloonde uren terughalen

Na het verwerken van de loonrun haalt de koppeling per medewerker en per periode het aantal verloonde uren op. Geen bedragen, geen loonstroken, alleen aantallen.

Het verschil tonen

Gepland, geregistreerd en verloond komen naast elkaar in één overzicht, per opdracht en per week. Afwijkingen boven een grens die jij bepaalt, worden gemeld.

Technisch loopt dit over de Nmbrs REST API. Je registreert een app in het developerportaal, krijgt een subscription key die bij elk verzoek mee moet, en authenticeert met OAuth 2.0. De oude SOAP-API bestaat nog en wordt door veel bestaande integraties gebruikt, maar Nmbrs stopt daar per 1 maart 2027 mee. Nieuwe koppelingen bouw je dus op REST, en draait er nog iets op SOAP, dan is die migratie werk dat je beter nu inplant dan straks onder tijdsdruk.

Aan de kant van de inrichting draait alles om urencodes. Uren komen Nmbrs binnen als urencomponenten die aan een urencode hangen: in de standaardinrichting is code 2100 de gewerkte uren, die op de loonstrook uitkomt op looncode 1000. Een component kan vast zijn, en dan wordt hij elke periode automatisch opnieuw ingevoerd tot je hem stopzet, of variabel, en dan geldt hij één periode. Voor uren uit een planning wil je vrijwel altijd variabel: elke periode een nieuw getal, geen stilzwijgende herhaling.

Twee dingen die in de praktijk misgaan. Het eerste is overwerk en toeslag: die horen op hun eigen urencode, want alleen dan berekent Nmbrs de juiste opslag. Wie alles optelt tot één totaal, betaalt het overwerk uit tegen het gewone tarief en ontdekt dat pas als een medewerker het meldt. Het tweede is het rooster. Voor medewerkers zonder vast rooster (oproepkrachten, nulurencontracten) moet het rooster in Nmbrs daadwerkelijk op nul staan, anders telt het systeem de contracturen én de doorgegeven uren mee. Dat is een inrichtingsfout die er in de eerste maand uit moet komen, en dus draai je de eerste loonrun met de koppeling altijd naast de hand.

Aan de kant van je planning is er geen standaard. Draai je Gripp, Simplicate of Teamleader, dan is er een API en is dit vooral veldenwerk; draai je een eigen systeem of een planbord in Excel, dan begint het gesprek daar. Hoe wij zo'n koppeling aanpakken staat op API-koppeling laten bouwen, en welke pakketten in Nederland onderling wél kant-en-klaar praten vind je in het koppelingenoverzicht.

Er is nog een derde richting, en die wordt bijna nooit gebouwd: het overzicht niet als rapport opleveren maar als vraag beantwoordbaar maken. Wij zetten daar een MCP-server voor neer op de gekoppelde urendata, zodat je in een AI-assistent gewoon kunt vragen welke opdrachten vorige maand uitliepen en hoeveel dat kostte, met dezelfde rechten en dezelfde grenzen als het dashboard. Dat is dezelfde koppeling, één laag verder doorgetrokken, en het is het verschil tussen een rapport dat je maandelijks opent en een cijfer dat je gewoon kunt opvragen.

Wat je wel en niet over de lijn stuurt

Er is één hardnekkig misverstand, en daarna een aantal keuzes die je gewoon goed kunt maken.

Wel doorgeven

Een intern medewerkersnummer of het Nmbrs-employeeId als sleutel. Datum, aantal uren en de urencode. De opdracht of kostenplaats waar de uren op horen. Per periode: het totaal aantal verloonde uren.

Niet doorgeven

Het BSN: daar geldt een eigen wettelijke grondslag voor, en een koppelsleutel is dat niet. Bruto- en nettobedragen, uurlonen en loonstroken. Verzuim- en verlofredenen: dat raakt gezondheidsgegevens. Inhoudingen zoals loonbeslag, alimentatie of vakbondscontributie.

Het misverstand eerst: salarisgegevens zijn onder de AVG géén bijzondere persoonsgegevens. Die categorie is limitatief en gaat over ras en etnische afkomst, politieke opvattingen, religie, vakbondslidmaatschap, genetische en biometrische gegevens, gezondheid en seksuele gerichtheid. Een brutoloon staat daar niet tussen. Het BSN evenmin. Dat is een gewoon persoonsgegeven met een eigen regel eromheen: je mag het alleen gebruiken waar de wet dat voorschrijft, en een koppeling tussen twee systemen is zo'n wettelijke taak niet.

Dat het geen bijzondere gegevens zijn, maakt het niet vrijblijvend. Wat er wél in een salarispakket zit en wat wél bijzonder is: verzuim- en gezondheidsgegevens, vakbondscontributie die uit het loon wordt ingehouden, en soms alimentatie of loonbeslag. Die staan in Nmbrs één klik naast de uren, en ze horen niet in een urenrapportage. Een koppeling die "alles ophaalt en later filtert" sleept ze mee naar een systeem waar ze niet thuishoren, en dat is precies de fout die je met één ontwerpkeuze aan het begin voorkomt.

De praktische regel die daaruit volgt is kort: haal aantallen op, geen bedragen. Voor een rapportage over gepland versus gemaakt heb je nooit een euro nodig. Wil je de afwijking in geld uitdrukken, doe dat dan met een kostprijs per uur of per rol die jij zelf vaststelt, niet met het werkelijke uurloon van een individuele medewerker. Dat scheelt een categorie gegevens, het scheelt een discussie met je ondernemingsraad, en het rapport wordt er beter van omdat je opdrachten onderling kunt vergelijken.

Verder gelden de gewone dingen, en die zijn niet ingewikkeld. Leg vast waarom je de gegevens verwerkt en hoe lang je ze bewaart. Sluit een verwerkersovereenkomst met iedereen die namens jou aan de knoppen zit, ook met je bouwer. Laat de koppeling loggen wat hij ophaalt, zodat je achteraf kunt aantonen dat hij binnen de lijnen bleef. En informeer je medewerkers: een rapportage over projectrendement is iets anders dan een prestatiemeting per persoon, maar dat onderscheid moet je uitleggen voordat het rapport rondgaat, niet erna. De bredere checklist staat op AI Act en AVG voor het mkb.

Wat kost een Nmbrs-koppeling?

Eén vast bedrag voor de koppeling, plus wat je aan Nmbrs zelf kwijt bent.

Een Nmbrs-koppeling prijzen we per situatie: een eenmalige bouwsom plus een vast bedrag per maand, inclusief beheer en doorontwikkeling. Alleen uren van je planning naar de loonrun sturen blijft bescheiden; uren heen, verloonde uren terug én een rapportage met meldingen erbovenop zit hoger. Dat bedrag dekt ook het bijhouden ervan: een API-versie die verandert of een urencode die erbij komt lossen wij op zonder meerwerkfactuur. Hoe die prijsopbouw werkt staat op wat kost een AI-medewerker.

Wat Nmbrs zelf kost, is lastiger hard te maken en dat zeggen we liever eerlijk: Nmbrs publiceert geen openbare prijslijst en loopt vrijwel altijd via een accountant of loonservicekantoor. In de markt zie je ruwweg vier tot tien euro per medewerker per maand, waarbij het verschil vooral zit in wat je tussenpersoon erbij doet. Vraag dat bedrag dus op bij je eigen kantoor in plaats van het van een vergelijkingssite te halen.

De rekensom die telt is de andere. Een koppeling die tien onzichtbare uren per maand zichtbaar maakt, laat dat cijfer daarna elke maand terugkomen. Wil je weten wat dat in jouw situatie oplevert? Plan 30 minuten met een bouwer, dan rekenen we het samen door op jouw aantallen.

Andere koppelingen.

Veelgestelde vragen over de Nmbrs-koppeling

Heeft Nmbrs een API waar je uren doorheen kunt sturen?: Ja. Nmbrs heeft een REST API met eigen registratie via het developerportaal: je maakt een app aan, krijgt een subscription key en authenticeert met OAuth 2.0. Daarnaast bestaat de oude SOAP-API nog, maar Nmbrs stopt daar per 1 maart 2027 mee. Bouw je nu iets nieuws, dan bouw je op REST. En draait er nog een integratie op SOAP, dan is dat een migratie die je beter dit jaar inplant dan in het laatste kwartaal van 2026.
Wat is het verschil tussen gewerkte uren en verloonde uren?: Gewerkte uren zijn wat een medewerker registreert. Verloonde uren zijn wat er over een periode in de loonaangifte terechtkomt, en dat is een eigen berekening: vakantie-uren, doorbetaald verlof, ADV en verzuim tellen mee terwijl er niemand aan het werk was, en niet elk overwerkuur landt in dezelfde periode als waarin het gemaakt is. Voor een rapportage over projectrendement wil je meestal beide getallen zien, juist omdat ze uit elkaar lopen.
Mag je salarisgegevens zomaar door een koppeling sturen?: Salarisgegevens zijn onder de AVG gewone persoonsgegevens, geen bijzondere. Dat is een misverstand dat je in veel offertes ziet staan. Dat maakt het niet vrijblijvend: je hebt een grondslag nodig, een verwerkersovereenkomst met iedereen die de gegevens namens jou verwerkt, en je mag ze alleen gebruiken voor het doel waarvoor je ze hebt verzameld. Wat wél bijzondere persoonsgegevens zijn: verzuim- en gezondheidsgegevens en vakbondslidmaatschap. Die zitten allemaal in een salarispakket, en die horen dus niet in een urenrapportage thuis.
Kan ik mijn urenregistratie niet gewoon in Nmbrs doen?: Voor de verloning kan dat prima: Nmbrs kent tijdregistratie, urencodes en een dashboard voor extra uren en dagen. Waar het ophoudt is projectadministratie. Nmbrs weet welke uren betaald moeten worden, niet of een opdracht binnen budget bleef. Draai je projectwerk, dan houd je een planning- of projectsysteem naast Nmbrs, en dan is de koppeling ertussen precies de plek waar het antwoord ontstaat.
Hoe lang duurt het bouwen van deze koppeling?: De techniek is niet het lange stuk. Twee tot vier weken doorlooptijd is realistisch, en het meeste daarvan gaat zitten in afspraken: welke urencode hoort bij welke soort uren, wat doe je met een medewerker die in twee opdrachten tegelijk zit, en vanaf welk verschil wil je een melding. Dat zijn geen technische vragen, en ze zijn belangrijker dan de code.
Werkt dit ook als mijn salarisadministratie bij een accountant ligt?: Meestal wel, maar het is een gesprek dat je vooraf voert en niet achteraf. Nmbrs wordt vrijwel altijd geleverd via een accountant of loonservicekantoor, en die beheert de omgeving. Voor een API-koppeling heb je toegang nodig tot die omgeving en toestemming van de beheerder. In de praktijk werken accountants hier prima aan mee, zeker als je laat zien dat je alleen aantallen ophaalt en geen bedragen.

Zien waar je uren weglekken?

In dertig minuten rekenen we het samen door op jouw aantallen. Je krijgt direct een eerlijk antwoord en een prijsindicatie.

Plan 30 minuten met een bouwer →Alle koppelingen →