When is software work R&D?
RVO lists developing new software as one of the types of work the WBSO covers, provided it's done in a planned way. Not every software project qualifies. How RVO assesses software projects is set out in the WBSO manual (Handleiding WBSO); read it before you apply.
A useful test for your own team: are you solving a technical problem where you don't know in advance whether or how it'll work, or building features with techniques you already master? A new sync protocol for offline use often carries more technical uncertainty than an extra form in an existing app.
In doubt about a project? Describe the technical problem in one paragraph. If you can only talk about user-facing features, read the WBSO manual closely before you apply for it as R&D.
What evidence does a software team already have?
For software, RVO explicitly mentions designs, code or commits and test reports as examples of project records. Software teams have the advantage that much of this is already recorded automatically with a date and an author.
| Source | What it shows | Watch out |
|---|---|---|
| Git commits | Who worked on which part, and when | Commit messages are often too short to show the why |
| Branches | Experiments and alternative approaches | Keep or document branches you throw away |
| Pull requests | Discussion of design choices and review | Lives in GitHub or GitLab; export or reference it |
| Design documents | The technical problem and the chosen approach | Add a date and author |
| Test reports and benchmarks | What worked and what didn't, with numbers | Keep failed runs too |
| AI coding agent sessions | Which problem you investigated and which routes you tried | Contain code; share summaries, not raw sessions |
Do sessions with Claude Code, Codex or Cursor count?
A session with an AI coding agent often shows clearly which problem you investigated, which solutions you tried and where it got stuck. That makes it useful material for your project records, just like notes from a technical discussion.
The session itself isn't the R&D work; the work is solving the technical problem, by the developer, with the agent as a tool. So log the hours against the developer and the project, and use the session as backup. Raw sessions contain code and sometimes client data; put a short dated summary in your project file instead. More on what to share with AI tools in Privacy and AI context.
How do you track hours per developer per project?
The requirement is the same as for any team: per day, per project, per employee, updated at least every 10 working days. In software teams R&D work often runs through regular work. A developer fixes a client bug in the morning and researches the new search algorithm in the afternoon.
- Create a separate activity for R&D in your time tracking, and one project per R&D project from your application.
- Have developers log R&D hours separately from other work at the end of the day.
- Use a short description that points to a branch, pull request or design document.
- Every two weeks, check that the hours match what happened in git.
Can you use commit history to fill in hours?
As a memory aid, yes. Commits show which project someone worked on each day. That helps fill in a forgotten day honestly, or check that R&D hours sit on days where R&D work is visible too.
Commits say nothing about how long something took. A day of research can end in one commit, a small change in ten. So don't calculate hours from commits; let the developer confirm the hours with the commits alongside. See also Logging hours with AI.
Evidence supports the hour records; it doesn't replace them. RVO asks for hour records per day, project and employee, alongside the project documents.
How Half5 does it
Half5's desktop app (Mac and Windows) puts a developer's git commits from chosen git folders (matched by commit e-mail), file changes in chosen folders and sessions from Claude Code, Codex and Cursor on their Timeline, under AI sessions. That timeline is end-to-end encrypted and only visible to the developer, not the organisation. They use it to log hours; evidence for the project records you put in your project file yourself.
An AI coding agent can also log work itself through the MCP server with log_work, using the ‘WBSO’ activity and the right project. Such an entry stays ‘Not approved yet’ until someone approves it. Half5 has no dedicated WBSO export or RVO form; the setup is in Tracking WBSO hours automatically.
Frequently asked questions
Does every software project qualify for the WBSO?
No. Developing new software can fall under the WBSO, but whether your project counts depends on the technical work. RVO's WBSO manual describes how software is assessed.
Are git commits enough as WBSO records?
No. Commits are good evidence in your project records, but RVO also asks for hour records per day, per project and per employee.
Can I include AI sessions in my project records?
They can show which problem you investigated and which routes you tried. Include a short dated summary rather than the raw session, which contains code and possibly confidential data.
Does software testing count for the WBSO?
Testing that's part of solving the technical problem, like benchmarking a new approach, is often used as evidence in project records. Whether it counts as R&D hours is something to check in the WBSO manual.
Sources
- RVO, WBSO (Dutch) · checked on
- RVO, Keeping your R&D records (Dutch) · checked on
