Softwareentwicklung ist nach dem FZulG förderfähig, wenn zu Projektbeginn eine echte technische Ungewissheit bestand – also unklar war, ob und wie sich ein Ziel erreichen lässt. Förderfähig sind typischerweise neuartige Algorithmen, Architekturen für extreme Skalierungs- oder Latenzanforderungen, Verfahren ohne bekannte Lösung und Machine-Learning-Ansätze mit offenem Ergebnis. Nicht förderfähig sind die Anwendung etablierter Frameworks, Konfiguration von Standardsoftware, Schnittstellenanbindung nach Dokumentation, Wartung, Fehlerbehebung und reine Oberflächenüberarbeitungen.
Das Wichtigste in Kürze
- Nicht das Produkt ist förderfähig, sondern einzelne Entwicklungsanteile mit technischer Ungewissheit.
- Der Zuschnitt des Vorhabens entscheidet über den Umfang der Bescheinigung.
- Agile Entwicklung ist kein Nachteil – Tickets und Sprint-Doku belegen Planmäßigkeit gut.
- Ein gescheiterter Ansatz ist förderfähig und belegt die Ungewissheit sogar.
- Laufende Cloud-Kosten zählen nicht direkt, sind ab 2026 aber über die 20 %-Gemeinkostenpauschale abgegolten.
Was zählt – und was nicht
Die Bescheinigungsstelle Forschungszulage fragt nicht, wie aufwendig eine Entwicklung war, sondern ob das Ergebnis zu Beginn offen war. Genau daran scheitern die meisten Softwareanträge: Sie beschreiben, was gebaut wurde, statt was unklar war.
| Förderfähig | Nicht förderfähig |
|---|---|
| Neuartige Algorithmen ohne bekannte Referenzlösung | Einsatz etablierter Bibliotheken und Frameworks |
| Architekturen für extreme Last-, Latenz- oder Konsistenzanforderungen | Skalierung mit bewährten Standardmitteln |
| Eigene ML-Verfahren, Trainingsstrategien bei knapper Datenlage | Anbindung fertiger Modell-APIs |
| Echtzeitsynchronisation mit offenem Lösungsweg | Schnittstellenanbindung nach vorhandener Dokumentation |
| Neue Verfahren zur Verifikation oder Fehlererkennung | Testautomatisierung mit Standardwerkzeugen |
| Prototypen zur Klärung technischer Machbarkeit | Wartung, Bugfixing, Refactoring, Migration |
| — | Benutzerverwaltung, Abrechnung, UI-Redesign, Lokalisierung |
Der Zuschnitt entscheidet
Ein häufiger und teurer Fehler ist es, das gesamte Produkt als ein „Vorhaben" einzureichen. In einem SaaS-Produkt überwiegen anteilig fast immer Routinearbeiten – Benutzerverwaltung, Billing, Oberfläche, Integrationen. Reicht man alles zusammen ein, verschwindet der forschende Kern im Gesamtbild, und die BSFZ sieht überwiegend Standardentwicklung.
Richtig ist der umgekehrte Weg: die technisch ungewissen Teile als eigenständige Vorhaben abgrenzen und getrennt beschreiben. Das reduziert zwar die eingereichte Kostenbasis, erhöht aber die Aussicht auf eine vollständige Bescheinigung deutlich – und hält der späteren Prüfung durch das Finanzamt stand.
Zwei Formulierungen desselben Projekts
Beispiel · Formulierung
Empfehlungsfunktion in einem SaaS-Produkt
Schwach: „Wir haben eine Empfehlungsfunktion entwickelt, die Nutzern passende Inhalte vorschlägt, und dafür ein Machine-Learning-Modell trainiert und in unsere Plattform integriert."
Tragfähig: „Zu Projektbeginn war offen, ob sich für Mandanten mit weniger als 500 historischen Interaktionen überhaupt eine Empfehlungsgüte oberhalb der Zufallsbasislinie erreichen lässt, da etablierte kollaborative Verfahren in diesem Datenbereich nachweislich versagen. Erprobt wurden in systematischen Versuchsreihen drei Ansätze zur Übertragung von Mustern zwischen Mandanten sowie zwei Verfahren zur synthetischen Datenanreicherung; zwei davon wurden nach Messung verworfen."
Derselbe Sachverhalt. Nur die zweite Fassung beantwortet die Fragen der BSFZ: Was war offen? Warum reichte vorhandenes Wissen nicht? Wie systematisch wurde vorgegangen?
Agile Entwicklung ist kein Hindernis
Die Sorge, iteratives Arbeiten widerspreche dem Kriterium der Planmäßigkeit, ist unbegründet. Verlangt wird ein systematisches Vorgehen, kein Wasserfallplan. Tickets, Sprint-Ziele, Experiment-Protokolle, Messreihen und Retrospektiven sind sogar besonders gute Nachweise, weil sie Zielsetzung, Vorgehen und Zwischenergebnisse dokumentieren.
Nützlich ist eine Konvention: Versehen Sie Tickets, die zu einem FuE-Vorhaben gehören, mit einem eigenen Label. Damit lässt sich der Aufwand später sauber zuordnen — das ist in der Praxis der größte Engpass, besonders bei rückwirkenden Anträgen.
Was dabei herauskommt
Modellrechnung
KI-gestützter HR-Chatbot
Ein mittelständisches Softwareunternehmen entwickelt einen Chatbot zur Automatisierung interner HR-Prozesse auf Basis von NLP und selbstlernenden Algorithmen. Drei Vollzeitäquivalente Entwicklung, 70.000 € Jahresgehalt inklusive Arbeitgeberanteil, zwölf Monate Laufzeit. Förderfähige Personalkosten: 210.000 €.
Beim KMU-Satz von 35 %: 73.500 €
Mit Gemeinkostenpauschale (Start ab 2026): 88.200 €
Modellrechnung zur Veranschaulichung, kein abgerechnetes Mandat. Details zur Berechnung unter Höhe der Forschungszulage 2026.
Welche Ihrer Entwicklungen tragen?
Wir sichten Ihre Projekte und sagen Ihnen konkret, welche Anteile die FuE-Kriterien erfüllen und welche nicht. Kostenlos, unverbindlich und mit einer klaren Aussage in beide Richtungen.
Projekte prüfen lassenHäufige Fragen
Softwareentwicklung ist förderfähig, wenn zu Projektbeginn eine echte technische Ungewissheit bestand – also unklar war, ob und wie sich ein Ziel erreichen lässt. Typische Beispiele sind neuartige Algorithmen, Architekturen für extreme Skalierung oder Latenz, Verfahren ohne bekannte Lösung sowie Machine-Learning-Ansätze mit offenem Ergebnis. Nicht förderfähig sind die Anwendung etablierter Frameworks, Konfiguration von Standardsoftware, Schnittstellenanbindung nach Dokumentation, Wartung, Fehlerbehebung und reine Oberflächenüberarbeitungen.
Nein, im Gegenteil. Das Kriterium der Planmäßigkeit verlangt ein systematisches Vorgehen, keinen Wasserfallplan. Sprint-Planungen, Tickets, Experiment-Dokumentation und Retrospektiven eignen sich gut als Nachweis, weil sie Zielsetzung, Vorgehen und Zwischenergebnisse belegen. Wichtig ist, dass die technische Fragestellung erkennbar bleibt und nicht in reiner Feature-Beschreibung untergeht.
Laufende Cloud-Entgelte sind keine Personalkosten und zählen nicht unmittelbar zur Bemessungsgrundlage. Für Vorhaben mit Beginn nach dem 31. Dezember 2025 werden Gemein- und sonstige Betriebskosten jedoch pauschal mit 20 % der übrigen förderfähigen Aufwendungen berücksichtigt, wodurch solche Kosten indirekt abgegolten sind. Abschreibungen auf ausschließlich für FuE genutzte Hardware sind gesondert ansetzbar.
Nicht das Produkt als Ganzes, wohl aber einzelne Entwicklungsanteile mit technischer Ungewissheit. Förderfähig sind typischerweise Kernkomponenten wie Mandantentrennung bei extremen Lastanforderungen, eigene Such- oder Empfehlungsverfahren oder Echtzeitsynchronisation. Nicht förderfähig sind Benutzerverwaltung, Abrechnungslogik, Standardintegrationen und Oberflächengestaltung. Der Zuschnitt des Vorhabens entscheidet daher über den Umfang der Bescheinigung.
Stand: 14.08.2026. Rechtsgrundlage: Forschungszulagengesetz (FZulG), Bescheinigungsstelle Forschungszulage. Beispiele dienen der Veranschaulichung. Die Förderfähigkeit ist im Einzelfall zu prüfen.