A WBSO or MIT application with a technical story that holds up

You build your own software, a device, or a smarter production process, and someone told you WBSO exists for that. WBSO is a Dutch tax credit for research and development work. Maybe you applied before and were turned down because the description was too general. Or you were approved and now have hour records that nobody on your team knows how to keep. The problem is rarely the scheme itself. The application is written by someone who does not know the technology, and the technology is described by someone who does not know the scheme.

What WBSO and MIT actually reward

WBSO is a scheme run by the Netherlands Enterprise Agency (RVO) for research and development work. It covers work where you develop something technically new and run into bottlenecks you cannot be sure you can solve. Software counts, and so do physical products and production processes. What does not count: setting up a standard package, configuring an existing integration, or building a website from existing components. The line is technical uncertainty, and you must be able to point to exactly that line in the application.

MIT stands for SME innovation stimulation for regions and top sectors, and it works differently. It is not a reduction on wage costs. It is a grant for a defined project, such as a feasibility study or a collaboration with another company. There are fixed application windows, and the project plan is judged on its content. WBSO mainly asks for good records afterward. MIT asks for a plan that convinces up front. For both, the technical core must be clear, and that is the part we do for you.

Why the technology has to carry the story

Most rejections and corrections we see have the same cause. The application describes what the product will be able to do, not what is technically hard about it. A sentence like "we are developing a smart planning platform" tells the assessor nothing. A sentence like "we do not yet know how to reschedule ten thousand deliveries within a second when one truck drops out" does. The second is a technical bottleneck. The first is sales copy.

You can only write that difference down well if you truly understand the code, the schema, or the production process. Our developers do that kind of work every day. We know which step in an integration is routine and which step nobody has done this way before. We use that knowledge to write down, for each project, what is new, why it is uncertain, and which approach you will investigate. That way an assessor without your expertise can still follow why this is development work and not routine.

How we help with the application

We start with a free intake where we go through your development plans for the coming year. For each project, we say honestly whether we see a technical bottleneck. If we do not, we tell you right away. An application for work that an audit would classify as routine costs you more than it brings in. For the projects that look promising, we write the technical description in plain language, with the bottlenecks and the approach in it. You can submit that text yourself or give it to your grant adviser.

We stay with the technology. Submitting and the amounts sit with your grant adviser or accountant, so everyone works on the part they know best. If we already work on your software or product, for example as on-site developers, we know the bottlenecks firsthand, and the description is a matter of writing down what is already happening. A green IT and sustainability project, such as a measurement setup for the energy use of your server fleet, can also contain development work that is easy to overlook without a technical eye.

Records that hold up in an audit

With WBSO, approval is the start, not the end. For each project, you must record who spent which hours on the development work and what was done in those hours. After the period ends, you report the hours actually worked, and RVO can come back years later to check them. A spreadsheet filled in from memory at the end of the quarter does not hold up. Records that run alongside the work do.

We set up those records around the way your team already works. Usually that means bringing the project codes from the application into your ticket system or time tracking, so a developer books once and both the invoicing and the WBSO file are correct. Every quarter, we check that the booked hours still match what was actually built, and whether new bottlenecks have appeared that belong in the next application. That way, an audit finds a file where the description, the hours, and the code tell the same story. You own that file, and it stays usable if you later continue with another adviser or on your own.