Wanneer is softwarewerk S&O?
RVO noemt het ontwikkelen van nieuwe software als een van de soorten werk waarvoor de WBSO geldt, mits het planmatig gebeurt. Niet elk softwareproject valt daaronder. Hoe RVO softwareprojecten beoordeelt, staat in de Handleiding WBSO; lees die voordat je aanvraagt.
Een bruikbare toets voor je eigen team: los je een technisch probleem op waarvan je vooraf niet weet of en hoe het lukt, of bouw je functionaliteit met technieken die je al beheerst? Een nieuw synchronisatieprotocol voor offline gebruik heeft vaak meer technische onzekerheid dan een extra formulier in een bestaande app.
Twijfel je over een project, beschrijf dan het technische knelpunt in één alinea. Lukt dat niet zonder alleen over functionaliteit voor de gebruiker te praten, lees dan de Handleiding WBSO extra goed voordat je het als S&O aanvraagt.
Welk bewijs heeft een softwareteam al?
RVO noemt voor software uitdrukkelijk ontwerpen, code of commits en testrapporten als voorbeelden van projectadministratie. Softwareteams hebben het voordeel dat veel daarvan al automatisch met een datum en een auteur wordt vastgelegd.
| Bron | Wat het laat zien | Let op |
|---|---|---|
| Git-commits | Wie wanneer aan welk deel werkte | Commitberichten zijn vaak te kort om het waarom te tonen |
| Branches | Experimenten en alternatieve aanpakken | Bewaar of documenteer branches die je weggooit |
| Pull requests | Bespreking van ontwerpkeuzes en review | Zit in GitHub of GitLab, exporteer of verwijs ernaar |
| Ontwerpdocumenten | Het technische probleem en de gekozen aanpak | Datum en opsteller erop zetten |
| Testrapporten en benchmarks | Wat werkte en wat niet, met cijfers | Bewaar ook mislukte runs |
| Sessies met AI-codeagents | Welk probleem je onderzocht en welke routes je probeerde | Bevatten code; deel samenvattingen, niet de ruwe sessie |
Tellen sessies met Claude Code, Codex of Cursor mee?
Een sessie met een AI-codeagent laat vaak goed zien welk probleem je onderzocht, welke oplossingen je probeerde en waar het vastliep. Daarmee is het bruikbaar materiaal voor je projectadministratie, net als een verslag van technisch overleg.
De sessie zelf is niet het S&O-werk; het werk is het oplossen van het technische probleem, door de developer, met de agent als gereedschap. Schrijf de uren dus op de developer en het project, en gebruik de sessie als onderbouwing. Ruwe sessies bevatten code en soms klantgegevens; neem liever een korte samenvatting met datum op in je projectdossier. Meer over wat je wel en niet met AI-tools deelt, lees je in Privacy en AI-context.
Hoe houd je uren per developer per project bij?
De eis is dezelfde als voor elk team: per dag, per project, per medewerker, bijgewerkt minstens elke 10 werkdagen. In softwareteams loopt S&O-werk vaak door gewoon werk heen. Een developer doet 's ochtends een bugfix voor een klant en 's middags onderzoek aan het nieuwe zoekalgoritme.
- Maak in je urenregistratie een aparte activiteit voor S&O en een project per S&O-project uit je aanvraag.
- Laat developers aan het eind van de dag de S&O-uren apart boeken van ander werk.
- Gebruik een korte omschrijving die naar een branch, pull request of ontwerpdocument verwijst.
- Controleer elke twee weken of de uren kloppen met wat er in git gebeurde.
Kun je je commitgeschiedenis gebruiken om uren in te vullen?
Als geheugensteun, ja. Commits laten zien aan welk project iemand op welke dag werkte. Dat helpt om een vergeten dag eerlijk in te vullen of om te controleren of S&O-uren op dagen staan waarop er ook S&O-werk zichtbaar is.
Commits zeggen niets over hoeveel tijd iets kostte. Een dag onderzoek kan in één commit eindigen, een kleine wijziging in tien. Reken uren dus niet uit commits, maar laat de developer de uren bevestigen met de commits ernaast. Zie ook Uren registreren met AI.
Bewijs ondersteunt de urenadministratie, het vervangt haar niet. RVO vraagt een urenadministratie per dag, project en medewerker, naast de projectdocumenten.
Zo doet Half5 het
De desktop-app van Half5 (Mac en Windows) zet op de Tijdlijn van een developer git-commits uit gekozen ‘Git-mappen’ (gekoppeld via het commit-e-mailadres), bestandswijzigingen uit gekozen ‘Mappen’ en sessies van Claude Code, Codex en Cursor onder ‘AI-sessies’. Die tijdlijn is end-to-end versleuteld en alleen voor de developer zelf zichtbaar, niet voor de organisatie. Hij gebruikt het om uren te boeken; het bewijs voor de projectadministratie zet je zelf in je projectdossier.
Een AI-codeagent kan via de MCP-server ook zelf werk boeken met log_work, met activiteit ‘WBSO’ en het juiste project. Zo'n boeking staat op ‘Nog niet goedgekeurd’ tot iemand haar goedkeurt. Een speciale WBSO-export of RVO-formulier heeft Half5 niet; de opzet staat in WBSO-uren automatisch bijhouden.
Veelgestelde vragen
Is elk softwareproject geschikt voor WBSO?
Nee. Nieuwe software ontwikkelen kan onder de WBSO vallen, maar of jouw project telt, hangt af van het technische werk. De Handleiding WBSO van RVO beschrijft hoe software wordt beoordeeld.
Zijn git-commits genoeg als WBSO-administratie?
Nee. Commits zijn goed bewijs in je projectadministratie, maar RVO vraagt daarnaast een urenadministratie per dag, per project en per medewerker.
Mag ik AI-sessies in mijn projectadministratie opnemen?
Ze kunnen laten zien welk probleem je onderzocht en welke routes je probeerde. Neem liever een korte samenvatting met datum op dan de ruwe sessie, die code en mogelijk vertrouwelijke gegevens bevat.
Telt het testen van software mee voor WBSO?
Testen dat hoort bij het oplossen van het technische probleem, zoals een benchmark van een nieuwe aanpak, wordt in de projectadministratie vaak als bewijs gebruikt. Of het als S&O-uren telt, lees je na in de Handleiding WBSO.
Bronnen
- RVO, WBSO · geraadpleegd op
- RVO, S&O-administratie bijhouden · geraadpleegd op
