What Does the Criterion "Uncertainty" Mean for the Forschungszulage?
TL;DR – Summary
- "Uncertain" means: at the start of a project it is not certain whether (and how) the technical objective can be achieved.
- What matters are technical/scientific risks (not: pure market or financial risks).
- If the solution is obviously or routinely achievable, uncertainty is usually absent – and with it, often, eligibility for funding.
- Anyone who describes uncertainty clearly (hurdles, hypotheses, tests, iterations) increases the chances of a BSFZ certificate – and thus of the Forschungszulage as an innovation incentive.
Links for context: Requirements, BSFZ, tax-based innovation incentive.
Why the Criterion "Uncertain" Is So Important
Many innovation projects look from the outside like "normal product development". But what is central to the Forschungszulage is whether your project has to resolve technical uncertainties. This is exactly where the BSFZ typically distinguishes routine (not eligible for funding) from genuine innovation with technical risk (often eligible for funding).
In short: without uncertainty, there is no eligible innovation in the sense of the Forschungszulage.
More context:
What Does "Uncertain" Mean Concretely?
In the sense of the Forschungszulage, a project is "uncertain" if at the outset there is no precise prediction about:
- Feasibility (does the approach work at all?)
- exact outcome (what level of performance/accuracy/stability will be achievable?)
- often also time and cost (because technical knowledge must first be acquired)
Time/costs (context on expenditures):
Important: In practice, the BSFZ groups the individual aspects (novel, creative, uncertain, systematic, reproducible) into three overarching criteria: novelty, risk/uncertainty and systematic approach. "Uncertain" is primarily captured in the risk/uncertainty criterion.
Risk/uncertainty (requirements):
Uncertain = Technical Risk, Not Commercial Risk
Technical risk (context):
Typical misconceptions:
- "We don't know whether customers will buy it" → commercial risk, does not count.
- "We don't know whether the technology can meet the requirements" → technical risk, does count.
Rule of thumb: Uncertainty must relate to scientific/technical obstacles that could in extreme cases lead to failure.
Practical Examples: When "Uncertain" Is More Likely Met
Practical examples:
1) Software & AI (Innovation Rather Than Standard IT)
Software/AI context:
More likely uncertain (eligible for funding possible):
- Development of an AI-powered real-time analysis at the production line, where it is unclear whether detection + latency + robustness under real conditions can be achieved simultaneously.
- Development of reproducible prompting strategies for consistent image series, when stability and transferability are not technically assured (e.g. drift across models/versions).
- Development of a low-latency platform with synchronisation technology, when it is unclear whether the architecture can handle scaling and consistency under high load.
More likely not uncertain (usually not eligible for funding):
- Standard software development with known frameworks without a technical hurdle
- pure integration/customising of known tools
- routine debugging after the development phase has concluded
2) Prototypes, Pilot and Test Systems
Uncertainty usually met, as long as the prototype/system serves to:
- test technical hypotheses,
- validate parameters,
- and develop further improvements.
Once the testing phase is complete and it is "only" moving towards production/zero series, the eligible part often ends.
3) Data Collection & Analysis
Can be uncertain, if data collection/analysis is an integral part of the technical solution, e.g.:
- Development of new methods for data collection or evaluation
- new measurement/labelling methods that first make the technical innovation possible
Usually not uncertain, if:
- data is only collected for market analyses (known methods, no technical knowledge gain)
How to Demonstrate Uncertainty Effectively in Your Project Description
Help with the project description:
Describe not only "what you are building", but why it is technically uncertain:
- Technical obstacles: What prevents a direct solution?
- Hypotheses/approaches: Which solution paths are you testing – and why are they not obvious?
- Experiment/test design: How do you verify whether an approach works?
- Metrics & conflicting objectives: e.g. accuracy vs. latency vs. robustness
- Iterations: What happens if approach A fails?
If you wish, you can often structure your uncertainty in 2–3 sentences like this:
- Starting point/state of the art (what is certainly achievable today?)
- Technical gap (what is unresolved?)
- Risk/uncertainty (why is the outcome open?)
- Validation plan (how do you proceed methodically?)
Why the Forschungszulage Is a Strong Option for Innovation Projects
The Forschungszulage is a tax-based innovation incentive for companies – technology-neutral and close to practice. The process is typically two-stage:
- BSFZ certificate (substantive eligibility of the project)
- Application to the tax office via ELSTER (assessment/offset)
If you clearly work out the criterion "uncertain", the path to the certificate often becomes considerably easier.
More on this (internal):
Official information: