Goed voorbereid op een WBSO-controle

De RVO mag controleren of wat je hebt aangevraagd ook écht is uitgevoerd. Zo’n controle komt altijd aangekondigd. Gelukkig maar: dan heb je tijd om je administratie op orde te brengen en verrassingen te voorkomen. De focus ligt op je technische ontwikkelwerk en de uren die je eraan besteed. Als je weet wat je kunt verwachten, hoef je minder stress te hebben. 

Administratieve controle

Hier draait het om structuur. Worden de uren goed bijgehouden? Is het duidelijk wie wanneer aan welk project werkte? Is de registratie actueel en sluit deze aan op de loonadministratie?

Je kunt vragen verwachten als:

• Zijn de uren binnen 10 werkdagen na uitvoering vastgelegd?

• Zijn de opgevoerde uren per project correct gemeld?

• Kloppen de gegevens met wat er bij HR of in de salarisadministratie staat?

🗂 Denk aan: Uurloonberekening · Urenregistratie per medewerker · Tijdigheid van registratie

Technisch-inhoudelijke controle

Nu kijkt de RVO naar de inhoud. Wat heb je nou precies ontwikkeld? Was dat echt technisch nieuw of onzeker, en heb je dat met eigen programmeerlogica opgelost?

Typische vragen:

• Wat was het programmeertechnische knelpunt?

• Waaruit blijkt dat jullie zelf nieuwe logica of architectuur ontworpen hebben?

• Kun je laten zien welke onderdelen van het project écht onder S&O vallen?

🔍 Denk aan: Deliverables · Architectuur componenten · Commitlogs · Technische rapportages

Voortgangscontrole of follow-up

Bij doorlopende projecten kijkt RVO of je consistent werkt. Lijn je voortgang met de oorspronkelijke aanvraag? Zijn eerdere opmerkingen opgevolgd?

🧭 Denk aan:Tussentijdse rapportages · Aangepaste aanpak onderbouwd? · Afbakening nog geldig?

Waar vindt de controle plaats?

• 📍 Op locatie: bij jou op kantoor

• 💻 Of als deskcontrole: digitaal, met vooraf toegestuurde stukken

Meestal vraagt RVO alvast om:

• Een urenoverzicht per project per maand

• Overzicht uren per medewerker (met BSN)

• Eventuele rekentool of interne subsidieberekening

De kern van je S&O-administratie

De wet is helder: je moet per project kunnen laten zien wat er is gedaan, door wie, wanneer, en waarom het technisch vernieuwend is.

Dimensie	Betekenis
Inhoud	Welke deliverables, modules, algoritmes en code zijn ontwikkeld?
Voortgang	Hoe is het werk door de tijd verlopen? (Sprints, versies, changelogs)
Aard	Ging het om nieuwbouw, experimenteel werk, oplossen van technische onzekerheden?
Omvang	Hoeveel uur is er gewerkt, door wie, op welke dagen?

💡 Tip: Gebruik tools als Git en Jira bewust. Ze vormen de ruggengraat van je bewijsvoering

Wat wel en niet onder WBSO valt (en hoe je dat uitlegt)

Bij een controle wil RVO weten of je goed onderscheid maakt tussen:

• 🔴 Niet-WBSO: functioneel ontwerp, wensen van stakeholders, implementatie

• 🟠 Beperkt WBSO: ontwerpkeuzes met technische impact, iteraties in TO

• 🟢 Volwaardige WBSO: eigen ontwikkelwerk in code, eigen algoritmes, engines, tooling

🛠 Voorbeeld:Het bouwen van een eigen AST-generator of synchronisatie-engine = WBSO.Het configureren van een bestaand framework = geen WBSO.

De WBSO-controle als ‘examen’

Een technisch-inhoudelijke controle voelt soms als een mondeling tentamen. Je krijgt vragen als:

Over het project:

• Wat was het doel, en waarom is het technisch vernieuwend?

• Hoe sluit dit project aan op de aanvraag?

Over je knelpunten:

• Wat kon niet met bestaande tools?

• Welke alternatieve aanpakken zijn overwogen?

Over je output:

• Kun je de output in formele programmeertaal tonen?

• Waar zit de echte innovatie in de code?

Over je proces:

• Is de aanpak iteratief geweest?

• Zijn er logs van tests, sprints en commits?

Over je team:

• Wie werkte wanneer aan welk onderdeel?

• Wat was de rol van medewerker X precies?

Tot slot: hoe je nu voorbereidt

📁 Zorg voor een mapstructuur met:

• Per medewerker: uren per maand, rol in het project

• Per sprint: changelogs, rapportages, technische output

• Vraag een expert om je administratie te controleren

Neem contact op voor de uitgebreide constructies!