Is a description per hour required?
No. For the hour records RVO asks for a split by day, by project and by employee. The content of the work belongs in the project records: reports, designs, test results and the like.
A short description per day is still wise. In an audit you have to show that the hours belong to the work in the project documents. A line ‘6 hours, project A’ forces you to work that out afterwards. A line mentioning ‘heat test prototype 3’ points straight to that day's test report.
What makes a description good?
A good WBSO description is short and concrete, written for someone who doesn't know the project but can follow it technically.
Write it on the day itself. You still remember which test you ran and what came out of it. A week later it turns into ‘continued work on project A’, which helps nobody in an audit.
- The subject: which component or which problem.
- The action: designing, testing, measuring, analysing, building a prototype.
- The result or next step: did it work, what did you find, what are you trying now.
- A pointer to documents: a test number, prototype version or design name, where it comes naturally.
Rule of thumb: if a colleague can find the matching document from the description, it's good enough.
Examples: from weak to better
The examples below are made up but recognisable. The better version is no longer than it needs to be: one sentence with subject, action and outcome.
| Project type | Weak | Better |
|---|---|---|
| Software | Programming | Designed sync algorithm for offline changes, tested conflict handling for simultaneous edits |
| Software | Fixing bugs | Investigated memory leak in image recognition, traced it to buffer reuse, tried an alternative design |
| Software | Meeting | Architecture session on event storage: chose between two storage models based on load test results |
| Product development | Prototype | Printed housing prototype 4 with thinner wall, ran 1.5 m drop test, crack at the hinge |
| Product development | Testing | Measured battery life at -10 °C, 30% shorter than calculated; designed insulation variant B |
| Process development | Machine setup | Trialled new welding parameters for thin-walled aluminium, measured porosity per setting |
| Process development | Research | Measured coating drying time at higher humidity, adjusted the drying curve model |
How do you describe technical problems?
R&D work is usually about technical problems you solve where the outcome isn't settled in advance. Write those problems down when you hit them, not when you file the year-end report. A problem recorded in March is more convincing than a look back in December.
A useful structure for a note in your project records:
- The problem: what doesn't work technically, and why the solution isn't known or can't be applied directly.
- The approach: which solutions you're trying.
- The outcome: what you measured or saw, even if it failed.
- The next step: what you'll try now.
Failed attempts belong in there. A test that didn't work shows that the outcome wasn't settled.
What work usually doesn't count as R&D?
Not everything a development team does is R&D. What counts and what doesn't is set out in RVO's WBSO manual (Handleiding WBSO); check it for your own situation. In practice, work like the list below is often not treated as R&D.
- Routine maintenance and management of existing systems.
- Education and training of staff.
- Sales, marketing and customer contact.
- Work that applies existing knowledge and techniques without a new technical problem.
- General administration and project management that isn't the technical work itself.
In doubt about an activity? Don't log it as R&D, and note why you doubted. Hours you can't back up are a risk in an audit.
How Half5 does it
In Half5 every entry has a description, which is also in the CSV export. Whoever approves hours sees a warning on entries without a description. On the Timeline an employee sees their own commits, file changes and AI sessions for the day, which helps when writing a concrete description; with Premium the desktop app can suggest a description with AI. You check those suggestions yourself.
Half5 doesn't judge whether something is R&D. That stays your call: you log the work on the ‘WBSO’ activity or you don't. More on the setup in Tracking WBSO hours automatically.
Frequently asked questions
How long should a WBSO description be?
One sentence is usually enough: subject, action and outcome. Longer explanations belong in the project records, for example a test report or design document.
Can I use the same description every day?
You can, but it doesn't help. A description that's the same every day makes it impossible to link the hours to specific documents.
Should I record failed experiments?
Yes, those especially. A failed attempt shows there was a technical problem whose solution wasn't settled.
Do meetings count as R&D?
That depends on the content. The WBSO manual describes what counts; if you log a technical discussion as R&D, describe concretely what it was about.
Can an AI tool write my descriptions?
A suggestion from a tool can help, but you're responsible for what it says. Read it and adjust it so it matches the work and the documents.
Sources
- RVO, Keeping your R&D records (Dutch) · checked on
- RVO, WBSO (Dutch) · checked on
