A sound time administration is a legal obligation within the WBSO. The RVO needs to be able to establish how much time was spent on R&D, and whether those hours match the content and progress of the projects as applied for. That's why time registration never stands on its own: your hours need to be linkable to your project documentation (the technical justification).
Why keep a time administration for the WBSO?
Audits often go wrong on two points. First, hours are logged, but the technical justification is too thin. Second, hours and content-related output can't be properly linked, so one can't clearly explain, per project and period, what exactly was done. A simple, ongoing routine, e.g. per sprint or monthly, prevents you from having to reconstruct afterwards what happened.
What requirements does a time administration need to meet?
The essence is that your time registration should clearly answer three questions: who worked, when, and on which WBSO project. This means the time registration should consist of the R&D hours made on a daily level, per employee with a clear distinction between R&D and non-R&D hours. Additionally, it is of importance to record on which project or activity the hours were spent on, such that the hours can be linked to the technical progress made in that same period.
Working on days that deviate from the normal pattern (weekends, public holidays, vacation days)? Then it's wise to briefly note why work was still done.
Linking hours to project progress: how to make it verifiable
A good administration doesn't just show that hours were made, but also which technical steps were taken. You can do this by documenting milestones, experiments, design choices, and test results, and connecting them to the hours you logged in that period. A compact log (daily or weekly) often suffices, if it refers to the underlying supporting evidence you're producing during the work anyway.
In practice, this works best when your time registration stays close to the normal process. Think of references to prototypes, test reports, tickets, commits, or measurement reports.
Hardware / product development: what is to be recorded?
For hardware and product development, the project administration often consists of tangible or measurable development results. Think of prototypes and test setups, drawings, calculations, measurement reports, specifications, test reports, and changes in design choices. It's important to also keep failed iterations and rejected variants, since these often best demonstrate the technical uncertainty and development route. Where possible, add a date, parameters (settings, materials, tolerances), and a reference to the employees involved, so you can link the step to the time registration.
Software development: what is to be recorded?
For software projects, the evidence is often found in the development environment and its accompanying documentation. Version control such as Git, tickets/issue tracking, pull requests, test results, technical design notes, and release notes can together provide a solid picture of the nature, scope, and progress of the R&D work. It's important that not just the result becomes visible, but also the development route, i.e. the solution directions investigated, rejected design choices, experiments, and code that ultimately was not pursued. This information helps make the technical uncertainties and the R&D character plausible.
How long to keep the time and project administration?
Because the RVO can ask questions or carry out an audit retroactively, it's important that your time registration and accompanying project documentation remain available and accessible for several years, including attachments. In practice, a minimum retention period of seven years is often assumed.
