Are you currently preparing an application for a research allowance for your software project, or have you received a rejection for your submitted application? The tax research allowance (in German "steuerliche Forschungszulage") is one of the most attractive instruments for promoting R&D projects in Germany and also offers opportunities for software development projects. Nevertheless, rejection of applications is not uncommon, especially for software projects. Why is this the case and what needs to be considered?

In the following article, we would like to focus on the specific hurdles, common sources of error and content requirements when applying for tax research allowances for software projects. Especially in the case of intangible, non-tangible research objects such as software, it is important to draft the application precisely and pay particular attention to the delimitation and wording in the application.

Research allowances for software projects: the challenges

a) Distinction between routine and adaptation developments and novelty

An essential task is to make a clear distinction between eligible research or experimental development and routine software development.

Classic further developments or pure adaptation programming are generally not eligible for funding. These include, for example, the configuration of established software or hardware, the porting of software (e.g. on-premise to the cloud) or the modular assembly or application of software solutions. Activities such as debugging or documentation in software development are also not eligible for funding.

 


Tip

A clear description and definition of the research or development nature is required. The descriptions must show the extent to which the content differs from established IT solutions in terms of comparable problems and solution approaches. Ask yourself the following question: Where are we breaking new technological ground in software development or in the project?

 

b) Identification of scientific and technical risks

In connection with the novelty of the project, there are technical risks along the solution path that leave the outcome of the project open. However, uncertainties are often more difficult to grasp in software projects than in physical products.

Examples of risks that are typically too unspecific or too general:
  • Algorithms are new and therefore risky to implement.
  • There is no programming language for the functions.
  • The system complexity is too high.
  • AI models deliver ‘hallucinated’ results.

 

 


Tip

Technical risks are best identified and presented along the solution path. There are no universal technical risks for all software projects; instead, they must be identified individually and for the specific project. Technical target parameters can help to make the project-specific risk more understandable and the uncertainties more comprehensible.

 

 

c) Scheduling and comprehensible solution path

The criterion of scheduling for the research allowance requires that the work involves precisely defined tasks of a scientific or technical nature with clearly defined objectives. The activities to be carried out are planned, for example, using a time or work schedule. In many cases, the criterion of planning is met in software projects using Scrum. Although this process model is widely used in software development, it is not very effective for demonstrating planning.

Furthermore, experimental development does not include routine or regular changes to existing products, production lines, processes, services or other ongoing operational processes, even if these changes represent improvements. The further development, maintenance and support of software are therefore not part of the eligible activities within the scope of the research allowance. Applicants for software development projects are often faced with the question of when a functional prototype has been achieved.

 


Tip

It is therefore advisable to draw up a classic work plan for the application, defining successive work packages. In doing so, determine the clear end of the project with the development of a functional prototype of the software in accordance with the definition of experimental development.

 

Take advantage of our expert support

Experience has shown that software projects are more challenging to apply for than traditional industrial or hardware projects when it comes to research allowance. However, with clear demarcation, comprehensible technical risks and an understandable solution, you can successfully apply for and receive funding here as well. A structured approach at an early stage avoids queries and significantly increases the likelihood of success.

Our expertise and experience in information and communication technologies is particularly valuable when it comes to complex software projects and applying for research grants. We have already applied for numerous software projects, successfully appealed against the rejection of tax research allowances, or carried out revisions following rejection – with the result that eligibility for funding was subsequently recognised. Benefit from our wealth of experience to avoid pitfalls in your arguments and documentation, or contact us if you need assistance with your appeal.

 

Text: Fabian Balle

 

Fabian Balle

Your contact person
Fabian Balle

Do you want to learn more about this topic? Schedule a meeting with an expert.

As a Project and Network Manager at EurA I support companies in topics related to funding for innovations. I understand the high dynamics in the IT sector with many novel technologies, especially in the field of artificial intelligence, as a challenge, at least demonstrated by the great potential of ChatGPT. I see it as particularly exciting to identify specific funding opportunities for clients' technological research and development projects and to support them throughout the entire process.
chat-icon

EurA AG
Max-Eyth-Straße 2
73479 Ellwangen

T- 079619256-0
info@eura-ag.com