Skip to content
Enterprise SaaS · Case study

Software allowance: two database projects funded.

An enterprise SaaS provider with demanding database technology set up two closely related projects, cleanly separated, on an eligible base over €4 million.

€1.4M
research allowance granted
€4M
eligible base
Up to 35%
SME funding rate
At a glance

The mandate in figures

IndustryEnterprise SaaS / dataAnalytics + proprietary database
Research allowance granted€1.4MSeven figures over the term
Eligible base€4M
ScenarioTwo projects, both certified
Projects2 (both certified)
SME funding rateUp to 35%
About the company

The company, and the R&D underneath

The company runs an analytics platform that merges very large data volumes from many sources and makes them available for near-real-time evaluation. At its core are two technically demanding building blocks: a database system that unites transactional and analytical processing, and a scalable framework for preparing data for machine learning.

Both blocks solve problems for which there is no finished off-the-shelf solution. That is the entry point for funding, but only if the presentation makes the R&D character visible and does not blur into product language.

The challenge

Where the funding really sat

Two risks shape software applications. First, the line between product and research. Much of software development is routine: building features, improving the existing, integrating. Only what goes beyond the state of the art and carries genuine technical uncertainty is eligible. This line must be drawn precisely.

Second, separating related projects. When two building blocks are technically closely linked, it is tempting to lump them together. For certification this is unfavorable: each project should carry its own clearly defined technical goal and its own risk. Merging them blurs novelty and solution path.

Novelty Technical risk / uncertainty Systematic approach
Our approach

How we built the case

We set up the two blocks as two independent projects, each with a sharp technical objective. One addresses the unified transactional and analytical data processing, the other the scalable data preparation for machine learning. For each we named the scientific-technical uncertainty, the point at which the solution path could have failed, and presented the solution path as a causal chain with intermediate results, not a feature list.

We researched the state of the art at the time of each project's start and named the established methods against which the in-house development sets itself apart. Where external developers solved an independent technical problem, we classified the contract research as eligible and cleanly separated it from mere supply. Both projects were certified. Part of the contract research was not recognized, a common outcome that reduces the eligible base in places but does not touch the core of the funding.

How the case moved

Separated
Two independent projects
Delineated
Research split from product
Certified
Both projects granted

What made up the eligible base

In-house ~60%Contract ~35%
In-house personnel workContract research (recognised)Not recognised

Eligible base over €4 million from in-house work plus recognised contract research; a small external share was not recognised. Split shown is illustrative.

The result

A €1.4M research allowance.

In total this yields an eligible base in the order of magnitude of over EUR 4 million. Across the term and both projects, the research allowance moves into the seven-figure range. For a growing SaaS company, this is a substantial, non-repayable financing contribution directly into development.

Eligible base €4M · SME rate Up to 35%
Two projects, both certifiedThe outcome of the mandate.
Eligible base €4MRecognised cost the allowance is calculated on.
SME rate Up to 35%Applied to the eligible base.
Key takeaways

What other companies can learn

Software is eligible, with the right presentation. Three points are decisive:

01

Separate research from product

Only the part that goes beyond the state of the art and carries genuine technical risk belongs in the application. Roadmap, operations, rollout and standard features do not.

02

Cleanly delineate related projects

Two independent projects with distinct goals and risks are stronger than one merged project. The delineation increases certifiability.

03

Expect a partial cut to contract research

That not every external service is recognized is normal. Separating strong from weak engagements and documenting cleanly protects the bulk of the funding.

Software is widely thought hard to fund because the line between product work and genuine research seems blurry.
BeFunded On the research allowance
FAQ

Your questions, answered

The most common questions on this kind of case. Short answer first, detail after.

Yes, insofar as it goes beyond the state of the art and is tied to scientific-technical uncertainty. Routine work, mere feature building and operations are not eligible. The delineation in the application is decisive.

Yes. Several independent projects are possible and often sensible. Each should have a clearly defined technical goal, its own risk and its own solution path.

Via the state of the art and the technical risk. If an established solution exists, it is routine. If a method has to be newly developed with an open outcome, it is R&D. This line should be drawn explicitly in the application.

The eligible base is reduced by that share. The remaining recognized part and, above all, the in-house work stay funded. A clean separation of engagements minimizes the risk.

Free eligibility check

See if your R&D qualifies for the Research Allowance

Tell us about your project. One of our funding advisors reviews your case by hand, then either comes back with feedback or a few follow-up questions. No obligation.

  • Whether your R&D qualifies for the allowance
  • A first read on the amount you could reclaim
  • What to prepare, including for 2022 and 2023

We reply within one working day. Your details go straight to our funding team.