WBSO: the form isn't what gets you rejected

If your Dutch company writes software, there are two WBSO dates in front of you. 30 September 2026 is the last day to apply for what's left of this year — October through December. 20 December 2026 is the last day for employers to apply with a 1 January 2027 start; self-employed applicants have until 1 January itself. There are no extensions.

I should say up front what I am and what I'm not. I'm not a subsidy consultant. I've never filed a WBSO application, and if you want one filed, a bureau will do it faster and more correctly than I will. I'm an engineer — twenty years of it, at Apple, Meta and BlackBerry — and I'm writing this because the thing that sinks software WBSO applications isn't administrative. It's a technical writing problem that the people filing your application usually can't solve, because solving it requires having been the engineer in the room.

What WBSO actually is

WBSO — Wet Bevordering Speur- en Ontwikkelingswerk — is the Netherlands' R&D tax incentive, administered by RVO. S&O (speur- en ontwikkelingswerk) is the term for the qualifying work itself, so when you see "S&O hours," read "R&D hours."

It pays out two ways:

• If you have payroll, it comes back as a reduction on your wage tax remittance. For 2026 the rate is 36% of the first €391,020 of R&D wage costs and expenses, 16% above that, and 50% on the first bracket if you qualify as a starter. Those figures are re-set every year.
• If you're self-employed with no staff, there's no payroll to reduce, so you get a fixed deduction against profit instead: €15,979 for 2026, plus €7,996 more if you're a starter — broadly, an entrepreneur in no more than four of the five preceding years, with the starter status usable for at most three years. To claim it you need 1,225 hours in the business over the calendar year and 500 hours of approved R&D. It's flat: 500 qualifying hours and 900 pay exactly the same, and 499 pays nothing.

One consequence of that flat 500 is worth stating plainly. If you're self-employed and only apply on 30 September, your period is October to December, and 500 R&D hours in thirteen weeks is nearly forty hours a week of pure development. For most solo operators, the September date is really an employer's deadline. Your move is the 1 January start.

The steps, briefly

1. Apply before the hours you want to claim. WBSO is forward-looking: only hours worked inside your approved period count. It does not matter whether the project is already underway — most are — but nothing before the period start is claimable. For employers, the period begins the first of the month after you apply; for the self-employed, it begins the day you submit. Every period runs to 31 December.
2. Describe the projects — this is the part everyone underestimates, and the rest of this post is about it.
3. Get the S&O-verklaring (the approval statement) back from RVO.
4. Record hours per person, per project, per day. RVO requires the timesheets to be up to date within ten working days, and the project records within two months of each quarter's end.
5. Report by 31 March the following year. Employers file the hours actually made; the self-employed only need to notify RVO if they fell short of 500.

Steps 1, 3 and 5 are calendar work. Step 4 is discipline. Step 2 is where applications die.

Functional innovation is not technical innovation

Here is the distinction that decides your application, and it is not intuitive.

RVO does not assess whether your product is new, clever, or commercially unprecedented. Its two tests, in its own words, are that the development is technically new for your company, and that during it you expect concrete technical problems that you or your R&D staff must solve yourselves.

Those are wildly different from "is this innovative." You can be building something no one in your market has built, solving a real customer problem no competitor has touched, and still be rejected — because you built it by assembling well-understood components in a well-understood way. Conversely, deeply unglamorous plumbing can qualify, if you genuinely didn't know whether it would work.

The most common failure in software applications is describing what you're building rather than why it was technically uncertain. Applicants write product descriptions. RVO is reading for named unknowns.

So what actually counts as R&D?

RVO's own handbook is the authority, and it's more specific than most people expect. For software, the work must be written in a formal programming language and must resolve a technical bottleneck in information technology by way of a new technical working principle — new to your company, not to the world.

The handbook's own list of what does not qualify is short and worth reading twice:

• "Describing models, formulating algorithms and describing an architecture" — designing on paper is not development
• "Applying, compiling or implementing software"
• "Designing and realising a new functionality based on available or obtainable technology"
• Prototypes that have commercial or productive value in themselves
• Work by non-technical staff, trade fairs, and outsourced research

In practice, bureaus read that list as excluding: configuration and customisation of existing platforms, however much effort it takes; wiring up third-party libraries and frameworks as designed; standard REST/JSON integrations against documented APIs; website and webshop building; functional design, UI/UX and front-end design; functional testing and testing by non-programmers; data modelling and SQL scripting; and all project management, documentation and market research. Low-code and no-code platforms sit awkwardly against the formal-programming-language requirement, and bureaus commonly treat builds on Mendix or OutSystems as configuration — check with yours before counting on them.

What does qualify is the part where you genuinely didn't know: your own algorithms, engines, protocols or data structures where the working principle wasn't available to you; performance, scale or concurrency problems where the approach wasn't known in advance; technical prototyping to find out whether something works, including prototypes that fail; and the technical testing done by your programmers to resolve that uncertainty.

The line, in one sentence: assembling existing components is implementation, and building new ones is development. Most real projects contain both. WBSO funds the second part, which means the work of the application is separating them honestly — and being able to say why the second part was uncertain.

Two things follow from this that surprise people. Your flagship feature may not qualify while some unglamorous internal engine does. And "we've done this kind of thing before" disqualifies you faster than "nobody in our market has done this" qualifies you.

What that looks like in practice

Take a real-shaped example. A company builds scheduling software for healthcare providers across many locations. Here's how that gets written by someone describing the product:

We are developing a scheduling platform that allows healthcare providers to manage appointments across multiple locations. This is innovative because no existing product serves this segment in the Netherlands, and it will significantly improve efficiency for our customers.

Every claim there is about market position and business outcome. There is not one sentence RVO can evaluate. This gets rejected, or it gets a vragenbrief — a letter of questions — which is a slow, expensive way to arrive at the same place.

Now the same project, written by the engineer who did it:

Our scheduling engine must resolve appointment conflicts across 40+ locations, each with its own rule set, where rules between locations can contradict each other. We evaluated two existing constraint solvers; neither converges inside our 200 ms budget at this rule count, and both assume a non-contradictory rule set, which ours is not. We do not know in advance whether a heuristic pre-pass can reduce the constraint space enough to make convergence reliable at this scale. Establishing that is the technical risk in this project, and it is why the work is not a matter of applying existing solutions.

Same project. Same code. One of these is fundable and the other isn't.

Look at what the second version does: it names a specific unknown, it says what was ruled out and why, it gives a measurable bar (200 ms), and — critically — it admits the outcome wasn't known in advance. That last part feels like weakness when you're used to writing for investors and customers. In a WBSO application it's the entire point. Uncertainty is the thing being funded.

Why the bureaus struggle with exactly this

Subsidy bureaus are genuinely good at what they do. They know the scheme, the deadlines, the forms, the audit exposure, and they'll keep you out of trouble. If you're filing, use one.

But their consultants aren't engineers. They can ask you what was technically difficult; they can't tell when your answer is thin, they can't push back when you describe a feature instead of a risk, and they can't recognise the qualifying uncertainty buried in work you've dismissed as routine — which, in my experience reading other people's architectures, is where a lot of it hides. So they write down what you tell them. If what you tell them is a product description, that's what gets submitted.

The gap isn't competence. It's that the person translating your engineering into RVO's language has never been the engineer.

The other trap: hours

Approval isn't the finish line. The most common way companies lose WBSO money is by getting approved and then failing the administration.

RVO expects hours recorded per person, per project, per day, with timesheets kept current within ten working days. Reconstructing them at year end, logging them in weekly lumps, or blending R&D with regular client work in one bucket all create the same problem: at audit you can't demonstrate which hours were R&D. Report fewer hours than you were approved for and you get a revised declaration; file late and you get a fine on top; file nothing and RVO sets your hours to nil, revises the declaration, and fines you anyway.

If you're going to claim, set the tracking up in the same week the approval lands, not in March.

If you're reading this before a deadline

Two honest possibilities. Either your work has real technical uncertainty in it and you're leaving money on the table for want of an afternoon's writing — or it genuinely doesn't, in which case you should know that now rather than after a rejection.

Until the December cut-off, I'll read one WBSO technical narrative for free and tell you which of those two you're in — sooner if you're an employer chasing the 30 September date. Send me your project description — the technical section, not the whole application — and you'll get back specific notes on where it's describing product instead of naming risk, and what an RVO reviewer will want that isn't there yet. No charge, no obligation, and if the answer is "this doesn't qualify," I'll tell you that plainly.

Email me at badpirate@kaperkun.de.

This is not tax advice. Your accountant or a subsidy bureau handles eligibility, filing and audit exposure, and you should use one. I'm commenting only on the engineering substance of the narrative. Figures and rules above are from RVO's 2026 WBSO handbook and calendar; they change annually.

Kevin Lohman runs Kaperkunde, an independent software consultancy in Amstelveen. Twenty years of iOS and full-stack engineering at Apple, Meta, BlackBerry and Grindr; four patents in iOS inter-container communication and security. Available for interim senior engineering and fractional CTO work in Amsterdam and the wider Randstad.