Software and AI don't count as research in themselves, but they can be. The Research Allowance Act (FZulG) ties funding to the categories of basic research, industrial research and experimental development within the meaning of the OECD Frascati Manual. In practice software projects often fall under experimental development, where the criteria are met.
When software and AI projects are R&D
The BSFZ assesses software projects against three criteria named in its assessment guide (version 10/2025) and derived directly from the Frascati Manual: novelty, technical and scientific uncertainty, and systematic method.
- Novelty means the project goes beyond the generally accessible state of science and technology. A new product built on known frameworks isn't novel within the meaning of the FZulG. A process whose existence or superiority isn't yet evidenced in the literature, by contrast, is.
- Uncertainty requires the technical result to be unforeseeable at the start of the project. The risk has to lie in the project itself, not in the market or in user behaviour.
- Systematic method means a planned, documented process: hypotheses, experiments, evaluation. A ticket backlog is no substitute for a research plan.
The same logic applies to AI projects. Developing new model architectures, learning methods or optimisation algorithms with an open technical question can be eligible. Fine-tuning an existing language model on company data, or wiring an LLM API into a product, is not, because there is no technical novelty and the result is foreseeable.
What isn't eligible
In its assessment guide, the BSFZ draws a clear line between qualifying R&D and non-qualifying routine development. Not eligible are:
- Product maintenance and bug fixing on existing code
- Migration to new frameworks or cloud platforms with no scientific question
- Implementing known algorithms with no research contribution of your own
- UX optimisation, A/B testing and conversion rate work
- Integrating third-party systems, APIs and SaaS services
- Data maintenance, ETL processes and reporting systems with no research element
What decides the boundary isn't the subject area but the question. A database project can be R&D if it develops a novel indexing method with an open outcome. The same project isn't R&D if it migrates and optimises an existing database.
Staff costs: how the assessment base is built
Staff expenditure is the largest item in the assessment base of software companies. Under § 3 (1) FZulG that means gross wages plus the employer's social security contributions, but only for the hours in which the employees worked on the qualifying R&D project.
From financial year 2026 two changes noticeably raise the assessment base for software teams. First the 20 per cent overhead flat rate: operating costs such as development environments, server costs for R&D systems or a share of office rent may be claimed as a flat 20 per cent on the remaining eligible expenditure, with no itemised evidence. Second the higher own-work rate for founders as sole traders or actively involved co-entrepreneurs: from 2026 it is €100 per working hour at a maximum of 40 hours a week, up from €70.
A worked example for a software SME: 6 developers on €85,000 gross each, all working 80 per cent on an eligible R&D project. Eligible staff expenditure: 6 × €85,000 × 1.20 (social security) × 0.80 = €489,600. Overhead flat rate (20 per cent): €97,920. Assessment base: €587,520. Forschungszulage with SME status (35 per cent under § 4 FZulG): around €205,600 a year.
SME status under Annex I of the General Block Exemption Regulation (GBER) requires fewer than 250 employees plus either annual turnover up to €50 million or a balance sheet total up to €43 million. For VC-funded companies the group view is decisive: an investor's majority holding can remove the portfolio company's SME status.
External development and contract research
Many software companies contract development work out to freelancers or external teams. Only a genuine research contract counts, not a service. Under § 3 (4) FZulG, 70 per cent of the contract value is eligible where the contractor is based in an EU or EEA state and the contract was awarded after 27 March 2024.
The boundary between contract research and a service: the external partner has to make an independent research contribution, meaning producing findings, not just writing code. Implementation contracts to a supplied specification aren't contract research. Invoices with no project-related description of the work showing a research link are regularly rejected during assessment.
Writing the BSFZ application properly
The most common failure pattern in software applications: the description sets out the product, not the research project. The BSFZ assesses whether a technical problem with an open outcome is being tackled systematically, not whether the result is innovative in the market.
A BSFZ application for a software project should name the following points clearly:
- The state of the art: which methods or approaches already exist, and why aren't they enough for the task at hand?
- The research question: what is the specific technical or scientific question the project answers?
- Uncertainty: why is the result unforeseeable at the start of the project? What technical risks exist?
- Method: how is the approach structured — hypotheses, experiments, evaluation metrics, iteration steps?
- Delimitation: what is expressly not part of the R&D project, meaning which routine work is being done in parallel?
Processing time at the BSFZ is typically 2 to 4 months. The BSFZ decision is a basic assessment notice under § 171 (10) AO and binds the tax office on the substance.
Time records in software practice
During assessment the tax office checks which person-hours actually relate to the R&D project. Without robust time records the assessment base is reduced or rejected, regardless of whether the BSFZ certified the project.
In software practice the following evidence works:
- A time tracking system with project attribution at project level
- A ticket system export (Jira, Linear) with time estimates and attribution
- Git commit history with authors and timestamps, combined with project branches
- Pull request review data attributed to the R&D project
Reconstruction after the fact is possible but demanding. The tax office requires a robust derivation, not an estimate. Keeping time records continuously avoids the risk that the whole evidence base fails in an audit. The same requirement applies to retroactive claims under § 169 AO: Git history and ticket systems are the most important sources for reconstructing past years.
FAQ
Is software development eligible for the Forschungszulage in principle?
Yes, where the project evidences novelty, technical and scientific uncertainty and a systematic method. Routine implementation, product maintenance and plain integration of known frameworks are not eligible.
Are AI projects eligible under the FZulG?
AI projects can be eligible where new model architectures, learning methods or algorithms are developed whose result is technically uncertain at the start. Training an existing language model on your own data generally doesn't meet that requirement.
How are developer salaries treated in the Forschungszulage?
Gross wages plus the employer's social security contributions, apportioned to R&D hours. From 2026 a flat 20 per cent overhead uplift is added to eligible staff expenditure, with no itemised evidence.
What is the difference between the BSFZ assessment and the tax office assessment for software projects?
The BSFZ assesses only whether the project meets the Frascati criteria. The tax office assesses the level of the assessment base: staff costs, time records, attribution to the project. A positive BSFZ decision is a necessary but not sufficient condition for payment.
Can I claim the Forschungszulage retroactively for past software projects?
Yes, within the four-year assessment period under § 169 (2) no. 2 AO. The conditions are a BSFZ certificate per financial year and robust evidence of the staff costs: time records or reconstructable development artefacts such as Git history and ticket exports.
Forschungszulage 2026: the complete guide
A €12m assessment base, a 35% SME rate, a two-stage procedure: an overview of the Forschungszulage in 2026, and where to find the detail.
Forschungszulage: which staff costs are eligible
Which pay components feed into the assessment base, how the 20% overhead flat rate works from 2026, and why time records decide the payout.
The BSFZ certificate: process, criteria and processing time
No Forschungszulage without a BSFZ certificate. What the certification body assesses, how the application works, and why many descriptions start from the wrong point.
Forschungszulage: keeping time records properly
Without complete time records the tax office won't accept the staff costs. How the documentation has to be structured, which formats work, and what a tax audit looks for.
All the detail, eligibility and pitfalls:
- [1]Act on tax incentives for research and development (FZulG)— Federal Ministry of Justice · gesetze-im-internet.de, 2026 Source
- [2]Assessment guide of the Bescheinigungsstelle Forschungszulage (as at October 2025)— Bescheinigungsstelle Forschungszulage (BSFZ), 2025 Source
- [3]The immediate tax investment programme and its effect on the Forschungszulage— Bescheinigungsstelle Forschungszulage (BSFZ), 2026 Source
- [4]Fiscal Code § 169 — limitation of assessment— Federal Ministry of Justice · gesetze-im-internet.de, 2024 Source
- [5]Frascati Manual 2015 — Guidelines for Collecting and Reporting Data on Research and Experimental Development— OECD, 2015 Source