WBSO-projectadministratie: uren, technische keuzes en controlebewijs

Een WBSO-dossier lijkt compleet zolang iedereen zijn uren ergens invult. Tot je moet uitleggen waarom die uren bij dit project horen, welke technische keuze eraan voorafging en wat er met een mislukte proef gebeurde. Dan blijken uren in een timer te staan, besluiten in Slack en bewijs in drie losse mappen.

De praktische oplossing is één werkstroom per WBSO-project. Je koppelt de goedgekeurde technische vraag aan dagelijkse uren, technische voortgang, bronbestanden, afwijkingen en een vaste vrijgave. Zo hoef je bij een controle niet opnieuw te vertellen wat er maanden geleden is gebeurd. Je exporteert het verhaal dat je tijdens het bouwen al hebt bijgehouden.

De regels hieronder zijn gecheckt op 22 september 2026. De percentages en bedragen voor 2026 komen uit de Handleiding WBSO 2026 van RVO, gepubliceerd in februari 2026. Voor een zelfstandige gelden eigen voorwaarden en fiscale gevolgen. Gebruik deze gids als inrichting van je bewijsstroom, niet als vervanging van fiscaal advies.

Wat je nodig hebt voor een controleerbaar dossier

Een controleerbare WBSO-projectadministratie laat per S&O-project zien wat je technisch ontwikkelt, welke knelpunten en oplossingsrichtingen je hebt onderzocht, wie wanneer uren maakte en hoe de voortgang uit bronbestanden blijkt. Uren, projectdocumenten en eventuele kostenadministratie vormen één herleidbaar geheel. Een los urenoverzicht is dus geen volledig dossier.

RVO verlangt dat de projectadministratie, urenadministratie en kostenadministratie op elkaar aansluiten en zeven jaar worden bewaard. Een administratie mag digitaal of op papier. Voor softwareontwikkeling is een digitale route meestal praktischer, omdat je technische werk al in versiebeheer en issuebeheer ontstaat.

Je hebt vijf dingen nodig:

• Een vaste projectidentiteit. Geef ieder project een unieke code, bijvoorbeeld WB26-02, en gebruik die code in je urenregistratie, mapstructuur, issues, technische notities en kwartaalrapportage.
• Een afgebakende technische vraag. Leg vast welk technisch probleem je oplost, wat technisch nieuw is voor jouw onderneming, welke onzekerheid je onderzoekt en wat buiten het goedgekeurde project valt.
• Een urenbron. Dat kan het Excel-model van RVO zijn, een urenpakket zoals Keeping of een eigen formulier. De bron moet per medewerker, per project en per dag de werkelijke uren kunnen tonen.
• Een bewijsbron. Denk aan GitHub voor commits en pull requests, Jira voor issues, testresultaten, meetwaarden, ontwerpnotities, e-mails, berekeningen en foto’s van prototypes. Bewaar ook mislukte pogingen.
• Twee verantwoordelijken. De ontwikkelaar of projectleider beheert de technische inhoud. Eén eigenaar controleert de uren, openstaande uitzonderingen en periodieke vrijgave.

Voor een BV of andere werkgever zijn de 2026-parameters relevant voor je begroting: 36 procent over de eerste S&O-grondslag van 391.020 euro, 16 procent over het meerdere en 50 procent over de eerste schijf voor starters. Dat is het fiscale voordeel, niet een reden om meer uren te boeken dan werkelijk aan S&O zijn besteed. Dien je als zelfstandige in, dan geldt in 2026 een vaste S&O-aftrek van 15.979 euro bij minimaal 500 S&O-uren, met een aanvullende startersaftrek van 7.996 euro als je aan de startersvoorwaarden voldoet. Controleer de actuele situatie bij RVO en de Belastingdienst voordat je rekent.

Een duur systeem is niet verplicht. Een duidelijke, consequente administratie wel.

Concrete stappen: van WBSO-verklaring naar dagelijkse werkstroom

1. Maak één projectkaart die de aanvraag letterlijk kan dragen

Begin niet met de urenapp. Maak eerst de projectkaart. Die kaart is het vaste vertrekpunt voor iedereen die later een uur boekt of een technisch document toevoegt.

Gebruik minstens deze velden:

Gebruik in de projectnaam een technische omschrijving. Nieuwe klantportal vertelt weinig. Incrementele synchronisatie van conflicterende orderrecords geeft meteen een onderzoeksvraag mee. Dat maakt later duidelijker waarom een test, foutmelding of codewijziging bij het project hoort.

Heb je meerdere WBSO-projecten, geef ieder project een eigen kaart. Eén project met de naam Productontwikkeling 2026 is meestal te breed. Je maakt het de ontwikkelaar dan bijna onmogelijk om op een drukke dag het juiste project te kiezen.

2. Vertaal de technische vraag naar een logboek van keuzes

De voortgang van een WBSO-project is geen lijst met afgeronde taken. Het bewijs zit in de route van technisch probleem naar onderzochte oplossing.

Maak voor elk knelpunt een record met:

1. Datum en eigenaar.
2. Technische vraag. Wat werkt nog niet, en onder welke omstandigheden?
3. Beginsituatie. Welke bestaande techniek, bibliotheek, infrastructuur of meetwaarde vormt het vertrekpunt?
4. Mogelijke oplossingsrichtingen. Welke opties heb je serieus overwogen?
5. Proef of implementatie. Wat heb je daadwerkelijk gebouwd, gemeten of getest?
6. Uitkomst. Wat werkte niet, gedeeltelijk of wel?
7. Besluit en vervolg. Welke route kies je, waarom en welk risico blijft open?

RVO vraagt bij ontwikkelingsprojecten dat uit de administratie blijkt welke technische problemen of knelpunten ontstonden en welke oplossingsrichtingen je koos. Schrijf dus niet alleen API aangepast of model getest. Schrijf bijvoorbeeld: De synchronisatie verloor de volgorde bij twee gelijktijdige updates. De vergelijking tussen een timestampstrategie en een versienummer per record liet zien dat de timestamp faalde bij gelijke milliseconden; de versieaanpak werd gekozen, maar vraagt nog een herstelstrategie voor offline clients.

Dat is geen dagelijks verslag van elk detail. Het is een compacte verklaring van de technische onzekerheid. Een functionele wens zoals gebruikers willen sneller zoeken wordt pas relevant als je hem vertaalt naar een technisch probleem zoals de zoekindex moet wijzigingen verwerken zonder volledige herbouw, maar de bestaande indexer kent geen veilige incrementele update.

3. Kies een eenvoudige combinatie van urenbron en bewijsbron

RVO schrijft geen specifiek administratief systeem voor. Een praktijkuitleg van PNO bevestigt dat je voor een ICT-project GitHub, Jira of vergelijkbare software kunt gebruiken zolang de labels en de technische knelpunten logisch aansluiten op je aanvraag. Die uitleg is oorspronkelijk gepubliceerd op 20 december 2019 en geraadpleegd op 22 september 2026, dus gebruik hem voor het principe, niet voor actuele percentages.

Kies één van deze werkbare combinaties:

• RVO Excel plus projectmap. Geschikt voor een zelfstandige of klein team met één of twee projecten. Gebruik het RVO-model voor uren en een mapstructuur op je bestaande opslag voor de projectdocumenten.
• Keeping plus GitHub of Jira. Geschikt zodra meerdere mensen uren schrijven of iemand moet goedkeuren. Keeping heeft een gratis plan voor één gebruiker en maximaal vijftien projecten en taken. De Plus-versie kost volgens de actuele prijspagina 6,50 euro exclusief btw per actieve gebruiker per maand bij jaarlijkse vooruitbetaling. De Pro-versie kost 8,50 euro exclusief btw en voegt onder meer verlof- en verzuimregistratie, uren goedkeuren en vergrendelen en budgetrapportage toe. Deze prijzen zijn gecontroleerd op 22 september 2026.
• Een eigen formulier of bestaande projecttool met vaste velden. Dat kan als je huidige systeem al medewerkers, projecten, datums, uren en bewijslinks vastlegt. Test eerst of je een volledig overzicht kunt exporteren. Een mooie registratie die geen bruikbaar controlebestand oplevert is niet af.

Richt je urenbron in met zo weinig mogelijk keuzes. Laat iemand selecteren uit de actuele WBSO-projecten, kies een datum, vul de uren in en voeg een korte werknotitie plus bewijslink toe. Zet reguliere uren, ziekte en verlof apart. Laat niemand zelf nieuwe projectcodes typen.

4. Registreer uren op de dag zelf en sluit ze binnen tien werkdagen

De harde basis is eenvoudig: uren per persoon, per project en per dag. De uren moeten binnen tien werkdagen zijn bijgewerkt en aansluiten op verlof- en ziekteregistratie. RVO biedt daarvoor een Excel-model, maar je hoeft dat model niet te gebruiken als je eigen systeem dezelfde informatie duidelijk laat zien.

Maak een uurregel zo concreet dat je hem drie maanden later begrijpt:

Ontwikkeling, overleg of bugfix is te vaag als losse tekst. De werknotitie hoeft geen essay te zijn, maar moet de koppeling met de technische vraag zichtbaar maken.

Registreer aan het eind van elke werkdag. Gebruik de tien werkdagen als uiterste vangrail, niet als planning. Wie op vrijdag de week afsluit, maakt vergeten uren zichtbaar voordat ze in de maand verdwijnen. Wie wacht tot de kwartaalafsluiting, reconstrueert geheugen in plaats van werk.

Een onafhankelijke controleuitleg van WBSO-subsidies.nl, gepubliceerd op 16 juli 2026, beschrijft dezelfde keten van uren per medewerker, project en dag, technische documentatie, afwezigheidsregistratie en aansluiting op de uiteindelijke realisatiemelding. Dat is precies de reden om een losse urenexport niet als eindproduct te behandelen.

5. Koppel ieder werkpakket aan een bronbestand

Je hoeft niet te bewijzen dat elke minuut een eigen commit heeft. Je moet wel kunnen laten zien hoe de geregistreerde werkzaamheden passen bij het technische project.

Gebruik een vaste bewijsregel:

• Een technische keuze verwijst naar een besluitnotitie, issue of ontwerp.
• Een programmeerblok verwijst naar een commit, pull request of wijzigingsset.
• Een technische test verwijst naar een testresultaat, meetbestand of log.
• Een mislukte route verwijst naar de proef, foutmelding en reden om ermee te stoppen.
• Een overleguur telt alleen mee als het aantoonbaar over het S&O-probleem en de technische uitvoering ging.

De naam van de maker en de datum moeten bij ieder document blijven staan. Bij een GitHub-migratie controleer je daarom of commitgeschiedenis, auteursnamen en datums behouden zijn. Bij een export uit Jira bewaar je de oorspronkelijke issuecode en een momentopname, niet alleen een samenvatting achteraf.

Hezelburcht beschrijft in een IT-praktijkvoorbeeld van 24 oktober 2024 dat een controle niet alleen naar werkende code kijkt, maar ook naar repositories, voortgang en documentatie van werkzaamheden die niet werkten. Bewaar dus de mislukte test. Juist die laat zien welke technische onzekerheid je hebt onderzocht.

6. Bouw een uitzonderingsqueue voordat je gaat automatiseren

Een foutloos formulier bestaat niet. Een controleerbaar proces maakt fouten zichtbaar en geeft ze een eigenaar.

Maak een queue met minstens deze uitzonderingen:

• Uren zonder projectcode.
• Uren op een project dat niet bij de medewerker hoort.
• Een werknotitie zonder technische vraag.
• Een bewijslink die ontbreekt of niet toegankelijk is.
• Een nieuwe technische richting die niet in de projectkaart staat.
• Uren van een externe partij of ingehuurde medewerker die per ongeluk als eigen S&O-uren zijn geboekt.
• Uren op een dag met ziekte of verlof.
• Een totaal dat niet aansluit op de bronregistratie.
• Een project dat is gestopt, maar nog wel uren ontvangt.

Geef elke uitzondering een status: nieuw, in behandeling, hersteld, buiten scope of besluit nodig. Voeg een eigenaar, datum en korte toelichting toe. Corrigeer een fout nooit stilletjes. Behoud de oorspronkelijke regel, markeer hem als gecorrigeerd en leg vast wie de wijziging heeft gedaan.

Een nieuwe technische richting is geen administratieve irritatie. Het kan betekenen dat de huidige projectomschrijving de werkzaamheden niet meer dekt. Stop dan de registratie op die code en laat eerst beoordelen of een update of nieuwe aanvraag nodig is.

7. Geef het dossier periodiek vrij en sluit het jaar af

Een dagelijkse registratie is bruikbaar. Een periodieke vrijgave maakt hem beheersbaar.

Gebruik deze cadans:

• Dagelijks: medewerker boekt uren, werknotitie en bewijslink.
• Wekelijks: projectleider controleert ontbrekende regels, verkeerde codes en nieuwe technische knelpunten.
• Maandelijks: bronhouder sluit de maand, behandelt uitzonderingen en exporteert een controlebestand.
• Na elk kwartaal: werk de projectadministratie uiterlijk binnen twee maanden bij. RVO verlangt dat de projectadministratie per project de aard, inhoud en voortgang toont.
• Na het kalenderjaar: vergelijk toegekende en gerealiseerde uren en kosten. Dien de mededeling van de realisatie uiterlijk 31 maart in. Bewaar daarna het vrijgegeven dossier zeven jaar.

De maandelijkse vrijgave is een interne beheerstap. De wettelijke kwartaaltermijn is de bovengrens voor het bijwerken van de projectadministratie, niet je ideale werkritme.

Valkuilen die je controlebewijs breken

Alleen uren bijhouden. Een urenstaat toont omvang, niet de aard, inhoud en voortgang van het S&O. Koppel iedere maand aan technische keuzes, tests en resultaten. Een export zonder projectverhaal is een halve administratie.

Een klantnaam als projectdefinitie gebruiken. Project Acme zegt niet welke technische onzekerheid je onderzocht. Gebruik de technische kern als projectnaam en bewaar de klantrelatie als apart veld.

Uren achteraf reconstrueren uit agenda of Git. Een agenda laat zien dat je een afspraak had. Een commit laat zien dat iemand code wijzigde. Geen van beide vertelt vanzelf hoeveel S&O-uren op welk project en welke dag zijn gemaakt. Registreer de uren als eigen bron en gebruik agenda, Git en Jira als controleerbare onderbouwing.

Werkende code bewaren en mislukte code verwijderen. Daarmee wis je het spoor van de technische onzekerheid. Bewaar testresultaten, foutmeldingen, afgewezen routes en korte notities met datum en maker.

Een generieke activiteit als ontwikkeling boeken. Gebruik vaste projectcodes en schrijf één zin over het technische probleem. Als een teamlid niet kan uitleggen waarom een uur bij het project hoort, hoort het uur eerst in de uitzonderingsqueue.

Reguliere bouw en S&O door elkaar laten lopen. Implementatie van een bekende oplossing, configuratie, beheer, gebruikerstesten en klantwerk kunnen in hetzelfde project voorkomen als S&O. Maak de grens zichtbaar en boek de uren gescheiden. Bij twijfel laat je de technische eigenaar de classificatie vastleggen voordat de periode wordt vrijgegeven.

Een project laten verschuiven zonder besluit. Een nieuwe productfunctie kan technisch interessant zijn, maar daarmee valt hij nog niet automatisch binnen de goedgekeurde aanvraag. Noteer het als wijziging, stop de twijfeluren en beoordeel de scope.

Extern werk als eigen uren opvoeren. WBSO-uren moeten aan de juiste onderneming en medewerkers gekoppeld zijn. Leg de technische inbreng van partners apart vast en laat de fiscale behandeling controleren.

Geen eigenaar van de bronbestanden aanwijzen. Als iedereen verantwoordelijk is, verplaatst niemand een document naar de projectmap. Wijs per project één bronhouder aan en laat hem maandelijks de volledigheid vrijgeven.

Beslis-kader: Excel, een pakket of maatwerk

De beste inrichting is de kleinste die je dagelijks volhoudt en waarmee je later het hele spoor kunt tonen. De aantallen hieronder zijn praktische werkgrenzen, geen RVO-regels.

Kies Excel en een vaste projectmap als je klein begint

Gebruik het RVO-model voor de uren en een vaste digitale map als je:

• alleen werkt of met één andere ontwikkelaar;
• één of twee WBSO-projecten hebt;
• geen goedkeuringsstap of koppeling nodig hebt;
• bereid bent iedere vrijdag de uren en technische notities te controleren.

Maak in dat geval discipline belangrijker dan software. Een eenvoudige map met 01-aanvraag, 02-knelpunten, 03-uren, 04-tests, 05-besluiten en 06-vrijgave werkt beter dan een duur pakket dat niemand gebruikt.

Kies Keeping of een vergelijkbaar urenpakket als de registratie moet worden afgedwongen

Een urenpakket past bij een team met meerdere medewerkers, meerdere projecten of een formele controle vóór vrijgave. Keeping is concreet bruikbaar omdat het volgens de actuele productpagina uren per klant, project en taak registreert, directe en indirecte uren kent en op Pro uren kan laten goedkeuren en vergrendelen. De gratis variant is voor één gebruiker; Plus en Pro rekenen per actieve gebruiker en zijn op 22 september 2026 geprijsd op respectievelijk 6,50 en 8,50 euro exclusief btw per maand bij jaarlijkse vooruitbetaling.

Let op de grens: Keeping kan je urenstructuur bewaken, maar het maakt niet vanzelf je technische bewijs. Voeg GitHub, Jira, een documentmap en een vaste besluitregistratie toe. De urenbron en bewijsbron blijven twee verschillende lagen die je met de projectcode koppelt.

Kies maatwerk als je dossier een procesprobleem is geworden

Maatwerk is verdedigbaar als je:

• meer dan één juridische entiteit of meerdere loonheffingennummers beheert;
• uren uit verschillende bronnen samenbrengt;
• GitHub, Jira, een urenpakket en documentopslag automatisch wilt verbinden;
• een uitzonderingsqueue met rollen, termijnen en auditlog nodig hebt;
• periodiek een vrijgavepakket met bronlinks, totalen en wijzigingen wilt genereren;
• meerdere WBSO-projecten hebt met overlappende teams en duidelijke toewijzingsregels.

Bouw dan eerst de regels uit deze gids als proces. Laat pas daarna software koppelen. Een maatwerkapp die een vaag proces sneller uitvoert, levert vooral sneller onduidelijke dossiers op.

Twijfel je nog tussen WBSO, MIT en SLIM, dan bepaalt of je zelf bouwt, eerst haalbaarheid onderzoekt, samen ontwikkelt of opleidt welke regeling past. Deze gids begint op het moment daarna: hoe je de gekozen WBSO-route dagelijks aantoonbaar uitvoert.

Uitgewerkt voorbeeld: een softwareteam met één technische kern

Stel: DeltaRoute Software B.V. ontwikkelt in 2026 een planningsmodule die wijzigingen uit drie systemen verwerkt. De functionele wens is eenvoudig: een wijziging moet overal zichtbaar worden. De technische onzekerheid zit in de volgorde. Twee systemen kunnen tegelijk een wijziging sturen, tijdelijk offline zijn en later met verouderde gegevens terugkomen.

Het team maakt projectkaart WB26-02 met deze technische kern: een incrementeel synchronisatiemechanisme dat gelijktijdige en vertraagde updates verwerkt zonder stille overschrijving. Buiten scope staan schermontwerp, klantinrichting, documentatie voor eindgebruikers en beheer van de bestaande koppeling.

De projectkaart krijgt drie knelpunten:

• WB-14: hoe detecteer je twee gelijktijdige wijzigingen zonder alleen op een milliseconde-timestamp te vertrouwen?
• WB-18: hoe herstel je een offline update als de lokale versie ouder is dan de centrale versie?
• WB-21: hoe voorkom je dat een herhaalde gebeurtenis een record nogmaals toepast?

De medewerkers boeken uren in Keeping Pro. GitHub bevat de code en pull requests. Jira bevat de technische vragen. Een map in de bestaande documentopslag bevat testuitvoer, besluitnotities en maandelijkse vrijgaven.

Op 12 september registreert Anna 3,5 uur op WB-14. Haar notitie zegt dat ze een scenario met twee gelijktijdige updates heeft gereproduceerd. Ze verwijst naar Jira-issue WB-14 en testresultaat T-028. Bram registreert 2 uur op hetzelfde knelpunt voor het vergelijken van timestampen en versienummers. Zijn bewijs is besluitnotitie N-041. Anna boekt die middag nog 1 uur op een productie-incident. Dat uur krijgt de code REGULIER, niet WB26-02.

Op vrijdag controleert de projectleider de week. Eén regel van Cato heeft 2 uur op WB26-02, maar de werknotitie luidt alleen overleg. De regel gaat naar de uitzonderingsqueue. Cato vult aan dat het overleg de keuze tussen versiebeheer en last-write-wins onderzocht en koppelt de notitie aan WB-14. Een andere regel staat op het WBSO-project, maar verwijst naar een klantdemo. Die wordt als buiten scope gemarkeerd. De oorspronkelijke registratie blijft bewaard.

Aan het einde van september maakt de bronhouder een vrijgavepakket:

• de urenexport per medewerker, project en dag;
• een lijst van de zeven uitzonderingen, met vier hersteld en drie buiten scope;
• de actuele projectkaart;
• de drie knelpuntrecords met keuzes en uitkomsten;
• links naar Jira, GitHub en testbestanden;
• een overzicht van wijzigingen sinds de vorige vrijgave;
• naam en datum van de persoon die de maand heeft vrijgegeven.

In het kwartaaloverzicht staan 312 geboekte uren. Zeven regels waren aanvankelijk onvolledig. Vier zijn vóór vrijgave aangevuld. De drie regels die buiten scope zijn geplaatst bevatten 2,0 uur klantdemo, 3,0 uur functionele implementatie en 5,0 uur beheer van de bestaande koppeling, samen 10,0 uur. Het dossier meldt dus 302 vrijgegeven S&O-uren in dit hypothetische voorbeeld: 312 minus 10. Dat getal wordt niet stil aangepast. Het is herleidbaar van de oorspronkelijke regels naar de vrijgegeven stand.

Een controleur die het spoor volgt, begint bij WB26-02, leest de technische kern, opent WB-14, ziet de twee oplossingsrichtingen, volgt T-028, bekijkt de codewijziging en komt uit bij Anna’s urenregel van 12 september. Dezelfde route werkt voor de mislukte timestampproef en de gekozen versieaanpak. Dat is het verschil tussen uren verzamelen en bewijs organiseren.

Vergelijkingstabel: welke inrichting past bij je situatie?

De prijzen en productlimieten hieronder zijn gecontroleerd op 22 september 2026. Keeping-prijzen zijn exclusief btw en gebaseerd op jaarlijkse vooruitbetaling. De RVO-regels zijn geen productprijzen en blijven leidend boven een toolkeuze.

De juiste keuze is niet de tool met de meeste functies. Het is de inrichting waarin een ontwikkelaar op dinsdag zonder nadenken een juist uur boekt, een projectleider op vrijdag een fout kan herstellen en je op 31 maart zonder reconstructie de gerealiseerde stand kunt melden.

Een WBSO-dossier wordt sterk op het moment dat een technische keuze, een werkdag en een bronbestand dezelfde projectidentiteit delen. Wie die koppeling dagelijks onderhoudt, maakt van controle geen jaarlijks zoekwerk maar een normale laatste stap van het ontwikkelproces.