Forschungszulage für Softwareentwicklung 2026:
So prüft die BSFZ IT-Projekte
Über 5.236 IT-Anträge bei der BSFZ bis März 2026 — Softwareentwicklung ist das meistbeantragte FuE-Feld der Forschungszulage. Und das meistabgelehnte. Die Abgrenzung zwischen förderfähiger FuE und nicht förderfähiger Routineentwicklung entscheidet über Erfolg oder Ablehnung.
IT-Projekt kostenlos prüfen lassenWarum IT eine Sonderrolle bei der Forschungszulage spielt
Im Bereich der IT und Softwareentwicklung wurden bei der BSFZ bis März 2026 bereits über 5.236 Anträge gestellt. Damit ist die Informationstechnologie das am häufigsten beantragte FuE-Feld der Forschungszulage. Das zeigt einerseits die Relevanz des Programms für die Branche, macht aber auch deutlich: Die BSFZ hat in diesem Bereich die schärfsten Prüfkriterien entwickelt.
Auch auf der Auszahlungsseite dominiert die Branche. Unsere Auswertung von 5.196 veröffentlichten Bewilligungen ordnet 24 Prozent aller Bewilligungen der IT zu, mehr als jeder anderen Branche.
Der Grund: Softwareentwicklung ist schwerer abzugrenzen als physische FuE. Ein neues Maschinenteil sieht man. Eine neue Software kann Routine sein oder grundlegend neu, von außen kaum zu unterscheiden. Die BSFZ prüft deshalb besonders genau ob die Frascati-Kriterien erfüllt sind.
Förderfähig oder nicht? Die entscheidende Abgrenzung
Die häufigste Ursache für Ablehnungen im IT-Bereich: Die Beschreibung trifft nicht die Sprache der BSFZ. Technisch herausragende Projekte werden abgelehnt, weil die Neuartigkeit und das technische Risiko nicht präzise formuliert wurden.
- Entwicklung neuer Algorithmen oder KI-Methoden die über den Stand der Technik hinausgehen
- Neue Softwarearchitekturen für spezialisierte Anwendungsgebiete mit technischen Risiken
- Entwicklung von Betriebssystemen oder Programmiersprachen
- Data Science / Big Data: neue Methoden zur Verarbeitung unstrukturierter Daten
- IoT / Industrie 4.0: neuartige Predictive-Maintenance-Ansätze
- Je aktiver und intelligenter die Software — desto innovativer
- Softwareentwicklung mit bekannten Methoden und existierenden Tools
- Portierung bestehender Software (z.B. Standalone zu Cloud)
- Installation und Konfiguration etablierter Server-/Cloud-Lösungen
- Einrichtung von Rechenzentren, Firewalls, Monitoring-Diensten
- Routinemäßiges Bugfixing, Testing, Dokumentation
- Hinterlegen von Inhalten in digitalen Lernplattformen
- Baukastenbasierte Zusammensetzung von Software ohne techn. Risiken
Die drei Frascati-Kriterien im IT-Kontext
Das FZulG verweist auf die Frascati-Kriterien der AGVO. Die internationale Norm für FuE-Klassifikation. Für IT-Projekte haben drei Kriterien besondere Bedeutung:
Was die BSFZ konkret in IT-Anträgen sehen will
Aus unserer Erfahrung mit IT-Projekten gibt es vier inhaltliche Anforderungen die in der BSFZ-Beschreibung explizit adressiert sein müssen:
- Ziel und Lösungsansatz: Konkrete Darstellung des angestrebten Ziels mit quantitativen Zielparametern und warum bestehende Methoden/Tools nicht ausreichen
- Stand der Technik: Welche vergleichbaren Lösungen existieren? Wie grenzt sich das Vorhaben davon ab? (Bibliotheken, Frameworks, Algorithmen explizit benennen)
- Methoden und Technologien: Genaue Beschreibung der eingesetzten Algorithmen, Architekturen, Schnittstellen, Datenbanken und deren spezifische Herausforderungen
- Technische Risiken: Wo könnte das Projekt scheitern? Welche technischen Grenzen sind zu überwinden? Konkrete Abbruchkriterien formulieren
- Arbeitsplan: Strukturierter Plan mit Arbeitspaketen, Meilensteinen und den jeweils erwarteten Zwischenergebnissen
Häufige Fehler bei IT-Anträgen und wie man sie vermeidet
Fehler 1: Zu viel Produkt, zu wenig FuE
Viele IT-Unternehmen beschreiben in ihrem Antrag was das fertige Produkt kann, statt was wissenschaftlich neu daran ist. Die BSFZ interessiert nicht das Produkt, sondern der Erkenntnisgewinn auf dem Weg dorthin.
Fehler 2: "State of the art" nicht belegt
Die Abgrenzung vom Stand der Technik muss konkret sein. Nicht "wir haben keine bestehende Lösung gefunden". Welche Frameworks, Bibliotheken, Paper wurden evaluiert? Warum reichen sie nicht aus?
Fehler 3: Agile Methodik vs. BSFZ-Planmäßigkeit
Viele IT-Teams arbeiten agil ohne klare Vorab-Planung. Das steht dem BSFZ-Kriterium der Planmäßigkeit scheinbar entgegen. Die Lösung: Sprint-Ziele in FuE-Arbeitspakete übersetzen, Meilensteine als Hypothesen formulieren ("Wenn Algorithmus X nach 3 Sprints Zielparameter nicht erreicht, wechseln wir zu Ansatz Y").
Fehler 4: Routinetätigkeiten nicht herausgerechnet
Bugfixing, Testing, Dokumentation, Anforderungsanalyse sind nicht förderfähig. Auch wenn sie im selben Projekt anfallen. Wer diese Tätigkeiten nicht aus der Stundenerfassung herausrechnet, riskiert Kürzungen bei der Betriebsprüfung.
Helmut Haimerl ist einer der führenden Experten für Technologieförderung in Deutschland. Ein besonderes Augenmerk legt er auf das systematische Vorgehen um den innovativen Kern von IT-Projekten herauszuarbeiten — präzise genug für die BSFZ, verständlich genug für die Entwicklungsteams.
LinkedIn Profil