Software Development R&D Tax Credit 2026

In software the open question decides, not the effort.

The certification body does not assess how large a release was, but whether a technical question was open before the start and was answered systematically. Software houses rarely lose an application on the technology; they lose it because delivery and development sit inside the same project.

Definition

Is software development eligible?

Yes. The FZulG does not require a physical result, it requires research and development under Section 2 FZulG. Your own algorithms, models, architectures and protocols are eligible as soon as the outcome was technically open at the start — 25 % of the assessment basis, 35 % for SMEs; for contract research commissioned after 27 March 2024, 17.5 % or 24.5 % of the fee before the additional flat rate.

Own algorithms, ML models, novel architectures, protocols, embedded systems
A failed project is just as eligible as a successful one
Using finished models and libraries through their interface falls out
The line runs inside a project, not between projects

Rates, costs and limits

The essentials on the research allowance in software development

Rate: 25 % of the assessment basis, 35 % for SMEs. For projects started after 31 December 2025, a 20 % flat rate increases the assessment basis (Section 3(3b) FZulG); the EUR 12 million cap still applies (Section 3(5) FZulG).
Eligible: Your own algorithms, ML models, novel architectures, protocols, embedded systems. What decides eligibility is not your industry but whether Novelty, Technical Risk and a Systematic Approach can be demonstrated.
Ceiling: Assessment basis of EUR 12 million per financial year, maximum research allowance EUR 4.2 million.
Own contribution: EUR 100 per working hour, exclusively for sole proprietors and co-entrepreneurs (Mitunternehmer) of partnerships (GbR, OHG, KG, GmbH & Co. KG). In a GmbH, UG or AG only the gross employer cost of salaried developers counts.
Contract research: 70 % of the cost of commissioned development work is claimable (Section 3(4) FZulG), including external development teams and university collaborations.
Retroactive: Applications for completed financial years from 2020 onwards remain possible as long as the assessment period for that year is still open.

Which activities in software development are eligible?

Your industry does not decide eligibility. The certification body tests every project against three criteria: Novelty, Technical Risk, Systematic Approach. If one fails, the application fails. Below are the activities we have encountered most often in five years, each with the finding we would expect.

Boundary case: eligibility depends on the specific project.

AI & machine learning

Training a domain-specific model on your own dataEligible
Eligible. Novelty: No model available on the market solves the task on your data at the required quality. Technical Risk: Whether the target metric is reachable at all with the data you hold is not settled before training. Systematic Approach: Hypothesis, experiment, measurement, iteration, evidenced by training runs and evaluations.
Building a training-data pipeline with labelling strategy and bias controlEligible
Eligible. Routinely overlooked because it looks like data work rather than research. It is eligible where the representativeness of the dataset is itself the open question: which selection, augmentation and correction methods measurably improve the model cannot be determined in advance. Merely collecting, reviewing and storing data is not eligible.
Fine-tuning a base model on your own datasetBorderline
Borderline. Eligible where the outcome is genuinely open beforehand and measured against a defined target metric. Not eligible where documented hyperparameters are simply set according to the vendor's guide. The line runs at whether you are working out a result or executing a known recipe.
Calling a finished language model through its API, including prompt developmentNot eligible
Not eligible. Addressing a commercial model through its interface is application, not development. The technical risk sits with the vendor. Writing and testing prompts is configuration, however laborious it may be.

Architecture & distributed systems

Developing your own consensus, replication or serialisation methodEligible
Eligible. The clearest case in this group. Anyone designing their own method must necessarily explain why the established ones fall short, which names the state of the art and evidences novelty. Record the alternatives you discarded; that is the load-bearing proof later on.
Breaking up a monolith where established patterns cannot hold the consistency requirementBorderline
Borderline. A migration by the book is routine. It becomes eligible the moment you can show that Saga, CQRS or two-phase commit do not deliver the required consistency under your load and that a bespoke mechanism had to be developed. The application must make that case with measurements, not assertions.
Performance work towards a limit no known method reachesBorderline
Borderline. Profiling and clearing obvious bottlenecks is routine. As soon as a target value is required that the available state of the art does not reach and you measured that beforehand, the investigation is eligible. The before-and-after benchmark is the key piece of evidence.
Moving to microservices or the cloud along an established playbookNot eligible
Not eligible. Effort is not a criterion. A migration can run for two years and remain routine as long as it applies known patterns to a known case. For the certification body only one thing counts: whether the outcome was technically open beforehand.

Data & platform

Your own query engine, index or storage structureEligible
Eligible. Anyone developing their own index or storage structure does so almost invariably because existing databases fail on one concrete property, access pattern, cardinality, write load. That exact property belongs in the project description.
Real-time processing under a latency limit that available systems cannot holdBorderline
Borderline. Eligible as soon as you can show the limit was measurably missed with standard tooling. Without that measurement the certification body only reads a demanding requirement and demanding is not a criterion under the FZulG.
Building a data warehouse or ETL routes with standard toolingNot eligible
Not eligible. Even demanding integration work remains integration. The tools are built for exactly this purpose, the path is documented, the outcome predictable.

Embedded & IoT

Radio or mesh protocol for new range or energy requirementsEligible
Eligible. Range, packet loss and power draw are measurable and in conflict with one another. That makes the technical risk quantifiable, the strongest starting position an application can have.
On-device inference under hard memory and energy limitsEligible
Eligible. Quantisation, pruning and distillation against a fixed memory budget: whether accuracy holds up is open beforehand. Your measurement series across the compression steps is the evidence of systematic work.
Porting a real-time operating system to new hardwareBorderline
Borderline. Eligible where the timing behaviour of the target hardware is unresolved and scheduling or drivers have to be worked out anew. Routine where the manufacturer supplies a board support package and the port follows its instructions.
Connecting a sensor via the documented vendor libraryNot eligible
Not eligible. Intended use of a component. Only when the sensor has to run outside its specification, or its signal corrected by methods of your own, does an open technical question arise.

Security & cryptography

Behaviour-based anomaly detection on encrypted trafficEligible
Eligible. Without visibility into the payload only metadata remains, whether a workable detection rate emerges from it cannot be determined before the investigation. False-positive rate against detection rate is the target metric here.
Fitting a post-quantum scheme into an existing protocolBorderline
Borderline. The schemes are standardised; fitting them in is not. Larger keys and signatures break packet sizes, handshakes and latency budgets. Investigating that interaction is eligible; implementing the algorithm to spec is not.
Rolling out a commercial SIEM, penetration testing, certification preparationNot eligible
Not eligible. Necessary and demanding work, but no gain in knowledge within the meaning of the FZulG. You are testing and hardening a system against known classes of attack with tools built for that purpose.

What gets rejected again and again

Business applications, web shops, portals, company websitesNot eligible
Not eligible. Forms, records, roles, payment integration: scope and effort can be enormous, yet the technical outcome is predictable. The exception is a clearly separable part that solves an open question, a bespoke search logic, say. Then we apply for that part, not for the application.
Version upgrades, refactoring, technical debt without an open technical questionNot eligible
Not eligible. The outcome is fixed in advance: the same functionality on a newer foundation. A vendor migration guide is practically proof that the outcome was not open.
Adapting a standard system within its intended scope (ERP, CRM, shop)Not eligible
Not eligible. Using the extension points the vendor provides is intended use. It is a different matter where the system demonstrably cannot represent the requirement and a method of your own has to be built alongside it.
Interface redesign, content migration, accessibility work, localisationNot eligible
Not eligible. Design and transfer work without technical gain in knowledge. Consultants occasionally file it along with the rest, which then drags the whole project into review, one of the reasons why professionally supported applications get rejected too.

What evidence does the BSFZ expect in software development?

Software companies practically never introduce an additional system for the research allowance, they have held the evidence all along. We evaluate what is there and assign every source to the criterion it supports.

What evidence does the BSFZ expect in software development?
Source	What it proves	Criterion
git log · git blame	Commit histories show attempt, discard and fresh start, the strongest evidence of experimental development that software can possibly supply.	Systematic Approach · Technical Risk
CI pipelines · test runs	Failed builds and benchmark series are measurement series. They date what was tried when, and against what it was measured.	Systematic Approach
Jira · Linear · Issues	Tickets carry the delineation: which part of a sprint was open development and which was delivery. The assignment runs at ticket or epic level.	Systematic Approach · Delineation
ADRs · design documents	Architecture decision records name the alternatives that were discarded, precisely the information that evidences the state of the art.	Novelty
Code reviews · pull requests	Review discussions record where a solution was uncertain and which assumption had to be tested. Rarely read, often decisive.	Technical Risk
Benchmarks · profiling	Measurements before and after the change evidence that a target value was not trivially attainable, the hard part of technical risk.	Technical Risk
Time records	For the tax office application the hour is what counts. We map an existing time record onto the projects rather than introducing a parallel system.	Cost side
Sprint reviews · retros	Minutes show the decision points: what was done differently after the measurement? That is precisely what a systematic approach looks like.	Systematic Approach

Constructing waterfall phases that never existed at your company is the most common mistake in professionally supported applications. Agile work is the better evidence, it yields a complete, time-stamped record of how you proceeded.

What software companies ask us most often

Is software development eligible when no physical product results?+

Yes. The FZulG does not require a physical result; it requires research and development within the meaning of Section 2 FZulG. Software is expressly covered as long as Novelty, Technical Risk and a Systematic Approach are present. Neither a patent nor a prototype nor commercial success is a precondition, a failed project is just as eligible as a successful one.

How does the BSFZ separate routine development from eligible development?+

What decides it is whether the outcome was technically open before the work began. Applying a known solution to a new use case is routine. Not knowing whether the desired property is attainable at all with the available state of the art is development. That line runs inside a project, not between projects, eligible and non-eligible work can sit side by side in the same sprint.

We work in an agile way. How are we supposed to evidence R&D hours?+

Agile work is the better evidence, not the worse. Tickets, sprint goals, commits and reviews form a complete, time-stamped record of how you proceeded, exactly what evidences a systematic approach. We assign the eligible shares at ticket or epic level rather than constructing waterfall phases that never existed at your company.

Are open-source contributions and internal frameworks eligible?+

Yes. The licence of the result is irrelevant. An internal framework no customer ever sees is eligible too, provided its development carried technical risk. Conversely, releasing something as open source does not make a routine project eligible.

Can I claim my own development time as a GmbH managing director?+

No. The flat rate of EUR 100 per working hour under Section 3(3) FZulG applies exclusively to sole proprietors and co-entrepreneurs (Mitunternehmer) of partnerships (GbR, OHG, KG, GmbH & Co. KG). In a GmbH, UG or AG only the gross employer cost of salaried staff counts, including for the managing director, and only where a legally effective employment contract exists and salary is actually paid. More on own contributions

What happens if our application has already been rejected?+

A rejection does not rule out a new application. In most cases the project was eligible and only the description fell short, because the state of the art was not named, the technical risk was framed as project risk, or the systematic approach was not set out at all. We examine the decision issued, identify the reason that carries it, and then choose between an appeal and a fresh application.

How far back can software and IT companies apply?+

Applications for completed financial years from 2020 onwards remain possible; what governs is the assessment period for the year in question. For many software companies the largest single amount sits in exactly those earlier years, because several development cycles there were never claimed. Retroactive applications

How much work does this create for our team?+

For a typical software project we reckon on two to four hours on the engineering lead's side: one technical conversation in which we record the project, and one approval round on the finished project description. Evaluating the repository, the ticket system and the time records, as well as both applications, is on us.

How does your documentation become an application?

Your team already documents everything the certification body wants to see, only in a different language. Here is the same set of facts in four registers, from the commit to the sentence in the application.

In the repository — What gets written anyway

commit 8f2a1c4
feat(matcher): learned re-ranker
  // recall@10 stuck at 0.61

- baseline bm25+cosine .. 0.61
- cross-encoder ....... 3.2s p95
- distilled bi-encoder 0.79 / 180ms

In conversation — What the team says about it

„We rebuilt the matching because the old search simply returned poor hits. The first approach was far too slow, so we shrank the model."

Technically complete and worthless as application text. Every reference to the state of the art and to the metric is missing.

At the BSFZ — What actually gets examined

Novelty
Technical Risk
Systematic Approach

For each of the three criteria the application must contain a testable statement. What has to be described is the gain in knowledge along the way, not the result itself.

In the application — What we formulate from it

„The available methods did not reach the required hit rate within the latency limit. Which ratio of model size to hit rate is attainable below that limit could not be determined in advance. The project established this in measurable iterations against a defined target metric."

This is the work. The same set of facts, four formulations and only one of them is an application. That translation is our actual service: building, out of what your team produces anyway, the statement the certification body can examine.

Software house with 40 developers · developer hours in a financial year
Activity	Hours
Developer hours per year	64,000 h
Development with an open outcome	35,200 h
Delivery, maintenance, configuration	28,800 h

55 % — the same share the worked example below documents via ticket allocation.

Why do applications fail in software development?

Rejected projects that came to us did not fail on their engineering. They failed on five recurring patterns and we see those in self-filed applications exactly as often as in professionally supported ones.

The state of the art is missing

The application describes what was built, not why it could not be done with what was available. Without a named state of the art the certification body cannot establish novelty. This is by far the most common reason.

How we do it. We name specifically the libraries, products and publications that were examined and discarded, each with the technical property on which they fail.

Project risk instead of technical risk

Deadline pressure, a tight budget and missing staff are not technical risks. Anyone arguing that way is describing a management problem and gets a decision that treats it as one.

How we do it. We frame the risk as an open technical question: which property was not predictable before the work began, and on what exactly would the project have failed.

The systematic approach is asserted, not evidenced

„We proceeded systematically" appears in almost every rejected application. In software the evidence sits in the repository, it is just hardly ever brought out.

How we do it. We derive the systematic approach from your own artefacts: hypothesis in the ticket, experiment in the branch, measurement in the test run, decision in the review.

The project is cut too broadly

An application covering „the platform" forces the certification body to assess routine work along with the rest and that drags the whole project down. This is exactly where professionally supported applications lose as well.

How we do it. We cut the project down to the part that carries the three criteria and separate the rest cleanly. That raises both the likelihood of approval and the claimable sum.

Cost side and facts do not match

The BSFZ certifies the project, the tax office examines the costs. Anyone claiming hours in the tax office application that contradict the project description loses at the second step, after the certificate has already been issued.

How we do it. We run the project description, the time records and the research allowance application (ELSTER) against the same delineation from the outset. The cost side is not assembled after the fact.

If you are already holding a rejection, the first step is to analyse the decision: which of the five points carries it. That determines whether an appeal or a fresh application is the right route.

Which other industries use the research allowance?

The sector never decides eligibility — Section 2 FZulG does. These pages show the same three criteria against the activities of each field.

Mechanical engineering — Design, testing, commissioning
Automotive — Drivetrain, battery, driving function
Medical technology — Operating principle, SaMD, pre-approval
Pharma & life sciences — Compound, formulation, bioprocess
Construction — Methods, materials, component tests
Energy & cleantech — Cell, storage, grid control
Aerospace — Structure, propulsion, avionics
Agriculture & FoodTech — Process, formulation, field trial

Send us a project, not a questionnaire

In the first call we talk about your architecture, not your legal form. After thirty minutes you will know which part of your development is eligible, at roughly what scale, and whether a retroactive application is worth it. Success-based, if nothing is approved, you incur no cost.

Arrange an initial call

Official sources

Read on

Max Nodes

Founder and Managing Director of NOVARIS Consulting. Specialised in the German R&D tax credit (FZulG) since 2021; 25 of 25 accompanied BSFZ applications approved (as of 09/2026). Max Nodes

R&D tax credit for software development: where development ends and use begins

Software & IT: test matching