WBSO administration checklist for software teams (2026)

WBSO administration does not start when an audit is announced, and it does not end when your application is approved. It starts when the approved R&D work starts.

For software teams, that work is spread across pull requests, issues, experiments, architecture decisions, tests and time records. If you wait until the end of the year to collect it, your WBSO dossier becomes a reconstruction exercise.

This WBSO administration checklist explains what RVO requires, what useful software evidence looks like and how to keep your hours and project records review-ready throughout 2026.

WBSO administration requirements at a glance

RVO expects your records to give a clear and simple view of the nature, content, progress and extent of the S&O work for each project. In practice, that means keeping the following records:

• Timesheets showing the S&O hours per person, per project and per day.
• Project records showing the nature, content and progress of the approved S&O work.
• Cost and expenditure records if your company chose actual costs and expenditures instead of the fixed amount.

The deadlines matter. Record S&O hours within 10 working days. Bring the project administration up to date no later than two months after the end of each calendar quarter. Keep the WBSO records for seven years, and report the realized hours and any applicable costs and expenditures to RVO by 31 March of the following year.

Start keeping records from the beginning of the project or application period, even if RVO has not issued the S&O declaration yet. Work that is ultimately rejected will not qualify, but waiting for the decision can leave a gap in the records for work that is approved.

1. Give every WBSO project a clear foundation

A strong software dossier starts with the approved project, not with a folder full of unrelated tickets. Keep the project scope visible so developers and reviewers can tell which work belongs to the WBSO project.

For each project, record at least:

• The project name and application period.
• The approved or expected S&O hours.
• The employees carrying out the S&O work.
• The technical problem, bottleneck or uncertainty.
• The planned development steps or research approach.
• The changes, experiments, results and failed approaches that show progress.

The work in the administration must match the activities approved in the application. If the project changes materially, do not quietly rewrite the original problem after the fact. Preserve the original scope and document what changed so you can decide whether a new or updated application is needed.

A useful test is simple: could someone outside the development team understand what was technically uncertain, what the team tried and how the project moved forward?

2. Record S&O hours per person, project and day

A compliant WBSO timesheet is more specific than a monthly total. RVO requires the hours actually spent on S&O to be recorded for each employee, project and day, and the timesheets must be updated within 10 working days.

For a software team, a useful hour entry answers five questions:

• Who performed the work?
• On which date?
• For how many hours?
• On which approved WBSO project?
• What qualifying technical work was performed?

Avoid notes such as “development work” or “backend tasks”. They may be quick to enter, but they do little to explain why the hours belong to the S&O project.

Investigated the indexing bottleneck that prevented search latency from staying below 200 ms at the target data volume.

Tested an alternative conflict-resolution strategy after the first synchronization approach produced inconsistent state.

An entry does not need to be an essay. It needs enough context to connect the person and time to the approved technical work. The totals should also remain consistent with leave and sick-leave records.

3. Keep project records that show technical progress

Timesheets show the extent of the work; project records show its nature, content and progress. These records should explain the technical problems encountered, the paths considered and the results of the work, whether the project succeeded or not.

RVO says software project records can draw on version-control and issue-tracking systems. That makes the material your team already creates useful, but a Git repository or ticket backlog is not automatically a clear WBSO dossier. Keep the items that explain the approved R&D work and preserve their dates and contributors.

Useful technical evidence can include:

• Pull requests and selected commits with technical context.
• GitHub, Linear, Jira or Azure DevOps issues and work items.
• Architecture decisions and technical design notes.
• Experiment plans, results and measurements.
• Test results, benchmarks and performance profiles.
• Prototype screenshots or recordings.
• Technical meeting notes and decision summaries.
• Failed approaches and the reason the team changed direction.

The strongest evidence tells a technical story. A pull request title on its own may say little. A pull request connected to the bottleneck it addressed, the approach tested and the relevant work period is much easier to understand later.

Keep documents grouped per project, with the date and author available. Do not discard failed experiments or earlier phases merely because the final implementation went in another direction: those records can demonstrate the uncertainty and development path.

4. Connect hours and evidence without inventing certainty

RVO requires the timesheet and project records to align, but it does not prescribe a one-to-one link between every hour entry and a specific pull request or ticket. Linking them is a practical way to make the relationship visible; it is not a separate statutory requirement.

Use links where they improve traceability. A pull request can support several days of work, and one hour entry can be supported by multiple pieces of evidence. Do not force a match just because two records share a date. A defensible connection should also make sense for the same project, person and technical topic.

This distinction matters for automation too. Suggestions can reduce searching, but uncertain matches should remain a human decision. A clean gap that needs review is better than a confident-looking link with no real basis.

5. Run a monthly WBSO administration review

A monthly review is not an RVO deadline. It is a practical cadence that helps software teams meet the 10-working-day timesheet rule and the quarterly project-record deadline while the context is still fresh.

Use this monthly WBSO checklist:

• Are all S&O hours recorded per person, project and day?
• Were the hours entered within 10 working days?
• Are the notes specific enough to identify the technical work?
• Is the work within the approved project scope?
• Is there evidence for the main technical activities and decisions?
• Are failed experiments and abandoned approaches preserved?
• Which hour entries have no supporting evidence yet?
• Which imported or manually added evidence still needs review?
• Can the evidence be traced to a date and contributor?
• Has the technical direction changed enough to revisit the application?

A short, regular review is much more reliable than asking developers in December to remember why a design changed in February.

6. Close each quarter and year deliberately

At the end of each calendar quarter, check that the project records are complete and can explain the work performed. RVO requires those records to be updated within two months after the quarter ends. If you chose actual costs and expenditures, maintain that separate administration too; it must be completed within two months after the end of the calendar year.

After the year ends, reconcile the realized S&O hours against the approved projects and declarations. Companies with employees submit one mededeling of the realization for the year by 31 March of the following year, including actual costs and expenditures where applicable.

The mededeling is an official RVO process. An internal dashboard or export can help prepare the review, but it does not submit the realization for you.

Common WBSO administration mistakes

Waiting until the end of the year

The code may still exist, but the reasoning is harder to recover. People move on, tickets lose context and failed experiments disappear from memory.

Recording hours without technical context

Hours alone show duration, not why the work qualified or how it related to the approved project.

Saving every engineering artifact

A noisy archive is not automatically a strong dossier. Prioritize records that explain the technical bottleneck, work performed, decisions and progress.

Hiding failed approaches

Failure does not make a project ineligible. Failed technical approaches can be valuable evidence of uncertainty and progress when they are documented honestly.

Treating administration as finance-only work

Finance or operations may own the process, but the technical context usually lives with engineers. Give developers a lightweight way to contribute it while the work is fresh.

How R&Dossier supports this checklist

R&Dossier is built around the parts of WBSO administration that software teams need to keep connected during the year:

• Create WBSO projects with a period, technical description, uncertainties, development steps, expected hours and approved hours.
• Assign project members and expected hour allocations.
• Register hours per person, project and day, add work notes, and review or confirm entries.
• Import TimeChimp time into an hours-candidate queue and, when enabled, bring new time in as drafts that a person still confirms.
• Scan GitHub pull requests, Linear issues, Azure Repos pull requests and Azure Boards work items as evidence candidates.
• Add manual evidence such as notes and documents, then accept, reject or flag evidence for review.
• Link evidence to hours manually, use ranked suggestions or opt into configurable beta auto-linking for sufficiently strong matches.
• Monitor approved-hour progress, evidence coverage, unreviewed evidence, hours without evidence and other attention points on the dashboard.
• Export an Excel auditpack containing projects, members, detailed and monthly hours, evidence, evidence-hour links and review indicators.

Optional automations can schedule integration scans, evidence imports, draft-hours imports and strong evidence-hour matches. They are off until enabled, write to an automation log and leave reviewable work visible. Confirming hours remains a human action.

R&Dossier does not apply for WBSO, submit the mededeling to RVO or guarantee that RVO will accept a claim. It currently focuses on projects, people, hours and technical evidence; companies using actual costs and expenditures must keep the required cost and expenditure administration separately.

Keep the WBSO dossier alive while the work happens

The best time to capture a technical decision is when the team makes it. The best time to fix a missing hour entry is within the 10-working-day window. The best time to find a gap in the project story is this month, not during a year-end reconstruction.

Use the checklist as a recurring workflow: keep the project scope visible, record time promptly, preserve evidence with context, review gaps monthly and close every quarter deliberately. That is how a software team turns scattered engineering activity into a WBSO administration it can actually explain.

Frequently asked questions about WBSO

What administration must a software company keep for WBSO?

For each project, keep timesheets showing S&O hours per person, project and day, plus project records showing the nature, content and progress of the S&O work. If the company chose actual costs and expenditures, it must also keep a separate costs and expenditures administration.

How quickly must WBSO hours be recorded?

RVO requires WBSO timesheets to be updated within 10 working days. The records must distinguish the hours per employee, approved project and day.

Can GitHub and issue trackers be used as WBSO evidence?

Yes. RVO explicitly identifies version-control and issue-tracking systems as possible software project records. The records should still make the technical work, progress, dates and contributors clear and should match the approved project.

When must WBSO project records be updated?

Project records must be updated no later than two months after the end of each calendar quarter. A monthly review is a useful internal cadence, but it does not replace that official deadline.

How long must WBSO records be kept?

RVO requires WBSO records to be retained for seven years. Preserve records from all project phases, including failed approaches and documents that were not used in the final solution.

Does R&Dossier submit the WBSO realization to RVO?

No. R&Dossier helps organize projects, people, hours and technical evidence and can generate a structured Excel auditpack. The official application and mededeling remain the company’s responsibility and are submitted through RVO.