Forschungszulage Softwareentwicklung: wo Entwicklung aufhört und Anwendung beginnt
Eigene Algorithmen entwickeln, die mit vorhandenen Verfahren nicht lösbare Probleme bearbeiten? Die Forschungszulage kann Ihre Entwicklungsarbeit fördern, wenn Neuheit, technisches Risiko und systematisches Vorgehen nachweisbar sind. Prüfen Sie unten die Tätigkeiten und ihre Abgrenzung zur Routine.
- Förderquote bis 35 %
- Löhne & Auftragnehmer förderfähig
- Rückwirkend für offene Jahre
Software & IT: Zuordnungen prüfen
A: feste Regeln. B: eigener Matching-Ansatz. Dieselben Dokumente, offene Zuordnung im Vergleich.
Neuer AnsatzEine Matching-Pipeline für komplexe Dokumente
Offene FrageWelches Verfahren liefert die nachvollziehbarere Zuordnung?
VersuchDokumente gegen zwei Regeln prüfen
In der Software entscheidet die offene Frage, nicht der Aufwand.
Die Bescheinigungsstelle bewertet nicht, wie groß ein Release war, sondern ob eine technische Frage vor Beginn offen war und systematisch beantwortet wurde. Softwarehäuser verlieren ihren Antrag selten an der Technik, meistens daran, dass Auslieferung und Entwicklung im selben Vorhaben stehen.
Fördersätze, Kosten und Grenzen
Das Wichtigste zur Forschungszulage in der Softwareentwicklung
Welche Tätigkeiten in der Softwareentwicklung sind förderfähig?
Die Branche entscheidet nicht über die Förderfähigkeit. Die Bescheinigungsstelle prüft jedes Vorhaben gegen drei Kriterien: Neuheit, Technisches Risiko, Systematik. Fällt eines aus, fällt der Antrag. Unten stehen die Tätigkeiten, die uns in fünf Jahren am häufigsten begegnet sind, mit dem Befund, den wir dazu erwarten.
Abgrenzung: Die Förderfähigkeit hängt vom konkreten Vorhaben ab.
22 / 22 Tätigkeiten angezeigt
KI & maschinelles Lernen
-
Training eines domänenspezifischen Modells auf eigenem DatenbestandFörderfähig
Förderfähig. Neuheit: Kein am Markt verfügbares Modell löst die Aufgabe auf Ihrer Datenbasis in der geforderten Güte. Technisches Risiko: Ob die Zielmetrik mit den vorhandenen Daten überhaupt erreichbar ist, steht vor dem Training nicht fest. Systematik: Hypothese, Experiment, Messung, Iteration, belegt durch Trainingsläufe und Auswertungen.
-
Aufbau einer Trainingsdaten-Pipeline mit Labeling-Strategie und Bias-KontrolleFörderfähig
Förderfähig. Wird regelmäßig übersehen, weil es nach Datenarbeit aussieht und nicht nach Forschung. Förderfähig ist es dort, wo die Repräsentativität des Datensatzes selbst die offene Frage ist: welche Auswahl-, Augmentierungs- und Korrekturverfahren das Modell messbar besser machen, lässt sich vorab nicht bestimmen. Nicht förderfähig ist das reine Erheben, Sichten und Ablegen von Daten.
-
Fine-Tuning eines Basismodells mit eigenem DatensatzAbgrenzung
Abgrenzung. Förderfähig, wenn der Erfolg vorab offen ist und gegen eine definierte Zielmetrik gemessen wird. Nicht förderfähig, wenn lediglich dokumentierte Hyperparameter nach Anleitung des Anbieters gesetzt werden. Die Grenze verläuft an der Frage, ob Sie ein Ergebnis erarbeiten oder ein bekanntes Rezept ausführen.
-
Anbindung eines fertigen Sprachmodells per Schnittstelle, inklusive Prompt-EntwicklungNicht förderfähig
Nicht förderfähig. Ein kommerzielles Modell über seine Schnittstelle anzusprechen ist Anwendung, nicht Entwicklung. Das technische Risiko trägt der Anbieter. Prompts zu formulieren und zu testen ist Konfiguration, auch wenn es aufwendig ist.
Architektur & verteilte Systeme
-
Entwicklung eines eigenen Konsens-, Replikations- oder SerialisierungsverfahrensFörderfähig
Förderfähig. Der klarste Fall in dieser Gruppe. Wer ein eigenes Verfahren entwirft, muss zwangsläufig begründen, warum die etablierten Verfahren nicht ausreichen, damit ist der Stand der Technik benannt und die Neuheit belegt. Halten Sie die verworfenen Alternativen fest, das ist später der tragende Nachweis.
-
Zerlegung eines Monolithen, bei der etablierte Muster die Konsistenzanforderung nicht haltenAbgrenzung
Abgrenzung. Eine Migration nach Lehrbuch ist Routine. Förderfähig wird sie in dem Moment, in dem sich zeigen lässt, dass Saga, CQRS oder Zwei-Phasen-Commit die geforderte Konsistenz unter Ihrer Last nicht liefern und ein eigener Mechanismus entwickelt werden musste. Diesen Nachweis muss der Antrag mit Messwerten führen, nicht mit Behauptungen.
-
Performance-Optimierung an eine Grenze, für die kein bekanntes Verfahren ausreichtAbgrenzung
Abgrenzung. Profiling und das Beseitigen offensichtlicher Engpässe sind Routine. Sobald ein Zielwert gefordert ist, den der verfügbare Stand der Technik nicht erreicht und Sie das vorher gemessen haben, ist die Untersuchung förderfähig. Der Vorher-Nachher-Benchmark ist hier der wichtigste Beleg.
-
Umstellung auf Microservices oder Cloud nach etabliertem VorgehensmodellNicht förderfähig
Nicht förderfähig. Aufwand ist kein Kriterium. Eine Migration kann zwei Jahre dauern und bleibt Routine, solange sie bekannte Muster auf einen bekannten Fall anwendet. Für die Bescheinigungsstelle zählt allein, ob das Ergebnis vorher technisch offen war.
Daten & Plattform
-
Eigene Abfrage-Engine, Index- oder SpeicherstrukturFörderfähig
Förderfähig. Wer eine eigene Index- oder Speicherstruktur entwickelt, tut das praktisch immer, weil vorhandene Datenbanken an einer konkreten Eigenschaft scheitern. Zugriffsmuster, Kardinalität, Schreiblast. Genau diese Eigenschaft gehört in die Vorhabenbeschreibung.
-
Echtzeit-Verarbeitung unter einer Latenzgrenze, die verfügbare Systeme nicht haltenAbgrenzung
Abgrenzung. Förderfähig, sobald belegt ist, dass die Grenze mit Standardwerkzeugen gemessen verfehlt wurde. Ohne diese Messung liest die Bescheinigungsstelle nur eine anspruchsvolle Anforderung und anspruchsvoll ist kein Kriterium des FZulG.
-
Aufbau eines Data Warehouse oder ETL-Strecken mit StandardwerkzeugenNicht förderfähig
Nicht förderfähig. Auch anspruchsvolle Integrationsarbeit bleibt Integration. Die Werkzeuge sind für genau diesen Zweck gebaut, der Weg ist dokumentiert, das Ergebnis vorhersagbar.
Embedded & IoT
-
Funk- oder Mesh-Protokoll für neue Reichweiten- oder EnergieanforderungenFörderfähig
Förderfähig. Reichweite, Paketverlust und Stromverbrauch sind messbar und stehen in Zielkonflikt. Damit ist das technische Risiko quantifizierbar, die stärkste Ausgangslage, die ein Antrag haben kann.
-
Inferenz auf dem Endgerät unter harten Speicher- und EnergiegrenzenFörderfähig
Förderfähig. Quantisierung, Pruning und Distillation gegen ein festes Speicherbudget: ob die Genauigkeit dabei hält, ist vorab offen. Die Messreihe über die Kompressionsstufen ist Ihr Systematik-Nachweis.
-
Portierung eines Echtzeitbetriebssystems auf neue HardwareAbgrenzung
Abgrenzung. Förderfähig, wenn das Timing-Verhalten der Zielhardware ungeklärt ist und Scheduling oder Treiber neu erarbeitet werden müssen. Routine, wenn der Hersteller ein Board-Support-Paket liefert und die Portierung dessen Anleitung folgt.
-
Anbindung eines Sensors über die dokumentierte HerstellerbibliothekNicht förderfähig
Nicht förderfähig. Vorgesehener Gebrauch eines Bauteils. Erst wenn der Sensor außerhalb seiner Spezifikation betrieben oder sein Signal mit eigenen Verfahren korrigiert werden muss, entsteht eine offene technische Frage.
Sicherheit & Kryptografie
-
Verhaltensbasierte Anomalieerkennung auf verschlüsseltem VerkehrFörderfähig
Förderfähig. Ohne Einblick in den Inhalt bleiben nur Metadaten, ob daraus eine tragfähige Erkennungsrate entsteht, ist vor der Untersuchung nicht bestimmbar. Falsch-Positiv-Rate gegen Erkennungsrate ist hier die Zielmetrik.
-
Einbau eines Post-Quanten-Verfahrens in ein bestehendes ProtokollAbgrenzung
Abgrenzung. Die Verfahren sind standardisiert, ihr Einbau ist es nicht: größere Schlüssel und Signaturen brechen Paketgrößen, Handshakes und Latenzbudgets. Förderfähig ist die Untersuchung dieser Wechselwirkung, nicht die Implementierung des Algorithmus nach Spezifikation.
-
Einführung eines kommerziellen SIEM, Penetrationstests, ZertifizierungsvorbereitungNicht förderfähig
Nicht förderfähig. Notwendige und anspruchsvolle Arbeit, aber kein Erkenntnisgewinn im Sinne des FZulG. Sie prüfen und härten ein System gegen bekannte Angriffsklassen mit dafür gebauten Werkzeugen.
Was regelmäßig abgelehnt wird
-
Geschäftsanwendungen, Webshops, Portale, FirmenauftritteNicht förderfähig
Nicht förderfähig. Formulare, Datensätze, Rollen, Zahlungsanbindung: Umfang und Aufwand können enorm sein, das technische Ergebnis ist vorhersagbar. Ausnahme ist ein klar abgrenzbarer Teil, der eine offene Frage löst, etwa eine eigene Suchlogik. Dann beantragen wir diesen Teil, nicht die Anwendung.
-
Versions-Updates, Refactoring, technische Schuld ohne offene technische FrageNicht förderfähig
Nicht förderfähig. Das Ergebnis steht vorher fest: derselbe Funktionsumfang auf neuerer Grundlage. Ein Migrationsleitfaden des Herstellers ist praktisch ein Beweis dafür, dass das Ergebnis nicht offen war.
-
Anpassung eines Standardsystems im vorgesehenen Rahmen (ERP, CRM, Shop)Nicht förderfähig
Nicht förderfähig. Erweiterungspunkte, die der Hersteller vorsieht, zu nutzen ist bestimmungsgemäßer Gebrauch. Anders liegt der Fall, wenn das System die Anforderung nachweislich nicht abbilden kann und ein eigenes Verfahren daneben entsteht.
-
Oberflächen-Redesign, Inhaltsmigration, Barrierefreiheits-Anpassung, LokalisierungNicht förderfähig
Nicht förderfähig. Gestaltungs- und Übertragungsarbeit ohne technischen Erkenntnisgewinn. Wird von Beratern gelegentlich mit eingereicht und zieht dann das ganze Vorhaben in die Prüfung, einer der Gründe, warum auch begleitete Anträge abgelehnt werden.
Welche Nachweise verlangt die BSFZ in der Softwareentwicklung?
Softwareunternehmen führen für die Forschungszulage praktisch nie ein zusätzliches System ein, sie haben die Belege längst. Wir werten aus, was da ist, und ordnen jede Quelle dem Kriterium zu, das sie trägt.
| Quelle | Was sie belegt | Kriterium |
|---|---|---|
| git log · git blame | Commit-Verläufe zeigen Versuch, Verwerfen und Neuansatz, der stärkste Beleg für experimentelle Entwicklung, den Software überhaupt liefern kann. | Systematik · Technisches Risiko |
| CI-Pipelines · Testläufe | Fehlgeschlagene Builds und Benchmark-Reihen sind Messreihen. Sie datieren, was wann versucht und woran es gemessen wurde. | Systematik |
| Jira · Linear · Issues | Tickets tragen die Abgrenzung: welcher Teil eines Sprints war offene Entwicklung, welcher war Auslieferung. Die Zuordnung läuft auf Ticket- oder Epic-Ebene. | Systematik · Abgrenzung |
| ADRs · Entwurfsdokumente | Architecture Decision Records benennen die verworfenen Alternativen, genau die Information, mit der sich der Stand der Technik belegen lässt. | Neuheit |
| Code-Reviews · Pull Requests | Review-Diskussionen halten fest, wo eine Lösung unsicher war und welche Annahme geprüft werden musste. Selten gelesen, oft entscheidend. | Technisches Risiko |
| Benchmarks · Profiling | Messwerte vor und nach dem Eingriff belegen, dass ein Zielwert nicht selbstverständlich erreichbar war, der harte Teil des technischen Risikos. | Technisches Risiko |
| Zeiterfassung | Für den Finanzamtsantrag zählt die Stunde. Wir legen eine vorhandene Erfassung auf die Vorhaben um, statt ein Parallelsystem einzuführen. | Kostenseite |
| Sprint-Reviews · Retros | Protokolle zeigen die Entscheidungspunkte: Was wurde nach der Messung anders gemacht? Genau das ist systematisches Vorgehen. | Systematik |
Wasserfall-Phasen zu konstruieren, die es bei Ihnen nie gab, ist der häufigste Fehler in begleiteten Anträgen. Agile Arbeit ist der bessere Nachweis, sie liefert ein lückenloses, zeitgestempeltes Protokoll der Vorgehensweise.
Was kommt dabei heraus?
Zwei gerechnete Fälle für Vorhaben, die nach dem 31.12.2025 begonnen haben, einmal zum KMU-Satz von 35 %, einmal zum Regelsatz von 25 % mit voll ausgeschöpfter Bemessungsgrundlage.
Software-Haus, 40 Entwickler · KMU
Arbeitgeberbrutto, 40 Entwickler: 4.000.000 €. Eigenes Ranking- und Matching-Verfahren, F&E-Anteil über Ticket-Zuordnung belegt, dazu ein vergebener Forschungsauftrag
Konzern-Entwicklung, 100 Entwickler
Arbeitgeberbrutto, 100 Entwickler: 12.500.000 €. Plattform- und Modellentwicklung über mehrere Standorte, kein KMU. Regelsatz 25 %, Bemessungsgrundlage am Deckel
Als Faustzahl: Ein Entwickler mit 90.000 € Arbeitgeberbrutto, der zu 60 % an förderfähigen Vorhaben arbeitet, bringt rund 22.700 € Forschungszulage im Jahr (KMU-Satz, mit Gemeinkostenpauschale — das Vorhaben beginnt nach dem 31.12.2025). Gedeckelt ist das Ganze bei einer Bemessungsgrundlage von 12 Mio. € und einer Zulage von 4,2 Mio. € pro Jahr. Für Vorhaben, die vor 2026 begonnen haben, entfällt die Pauschale. Zum Rechner Welche Beträge dabei bewilligt wurden, steht bei den bewilligten Vorhaben.
Die Abgrenzungsregeln, die Nachweisquellen und eine Vorlage für die Vorhabenbeschreibung, als PDF.
Was Software-Unternehmen uns am häufigsten fragen
Wie wird aus Ihrer Dokumentation ein Antrag?
Ihr Team dokumentiert bereits alles, was die Bescheinigungsstelle sehen will, nur in einer anderen Sprache. Hier ist derselbe Sachverhalt in vier Registern, vom Commit bis zum Antragssatz.
Im Repository — Was ohnehin geschrieben wird
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
Im Gespräch — Was das Team dazu sagt
Fachlich vollständig und als Antragstext wertlos. Es fehlt jeder Bezug zum Stand der Technik und zur Messgröße.
Bei der BSFZ — Was tatsächlich geprüft wird
- Neuheit
- Technisches Risiko
- Systematik
Zu jedem der drei Kriterien muss der Antrag eine prüfbare Aussage enthalten. Zu beschreiben ist der Erkenntnisgewinn auf dem Weg zum Ergebnis, nicht das Ergebnis selbst.
Im Antrag — Was wir daraus formulieren
„Die verfügbaren Verfahren erreichten die geforderte Trefferquote nicht innerhalb der Latenzgrenze. Welches Verhältnis von Modellgröße zu Trefferquote unterhalb dieser Grenze erreichbar ist, war vorab nicht bestimmbar. Das Vorhaben ermittelte dies in messbaren Iterationen gegen eine definierte Zielmetrik."
| Tätigkeit | Stunden |
|---|---|
| Entwicklerstunden im Jahr | 64.000 h |
| Entwicklung mit offenem Ergebnis | 35.200 h |
| Auslieferung, Wartung, Konfiguration | 28.800 h |
55 % — derselbe Anteil, den der Rechenfall unten über die Ticket-Zuordnung belegt.
Woran scheitern Anträge in der Softwareentwicklung?
Abgelehnte Vorhaben, die zu uns kamen, sind nicht an ihrer Technik gescheitert. Sie sind an fünf wiederkehrenden Mustern gescheitert und die sehen wir bei Eigenanträgen genauso wie bei extern begleiteten.
Der Stand der Technik fehlt
Der Antrag beschreibt, was gebaut wurde, nicht, warum es mit dem Verfügbaren nicht ging. Ohne benannten Stand der Technik kann die Bescheinigungsstelle keine Neuheit feststellen. Das ist der mit Abstand häufigste Grund.
Projektrisiko statt technisches Risiko
Termindruck, knappes Budget und fehlendes Personal sind keine technischen Risiken. Wer so argumentiert, beschreibt ein Managementproblem und bekommt es als solches beschieden.
Die Systematik wird behauptet, nicht belegt
„Wir sind systematisch vorgegangen" steht in fast jedem abgelehnten Antrag. Bei Software liegt der Beleg im Repository, er wird nur so gut wie nie gehoben.
Das Vorhaben ist zu weit geschnitten
Ein Antrag über „die Plattform" zwingt die Bescheinigungsstelle, Routineanteile mitzubewerten und die ziehen das gesamte Vorhaben herunter. Genau hier verlieren auch extern begleitete Anträge.
Kostenseite und Sachverhalt passen nicht zusammen
Die BSFZ bescheinigt das Vorhaben, das Finanzamt prüft die Kosten. Wer im Finanzamtsantrag Stunden ansetzt, die der Vorhabenbeschreibung widersprechen, verliert im zweiten Schritt, nach bereits erteilter Bescheinigung.
Liegt bei Ihnen bereits eine Ablehnung vor, ist der erste Schritt die Analyse des Bescheids: welcher der fünf Punkte trägt die Entscheidung. Davon hängt ab, ob Einspruch oder Neuantrag der richtige Weg ist.
Welche weiteren Branchen nutzen die Forschungszulage?
Die Branche entscheidet nie über die Förderfähigkeit, § 2 FZulG tut das. Diese Seiten zeigen dieselben drei Kriterien an den Tätigkeiten des jeweiligen Fachs.
- Maschinenbau — Konstruktion, Versuch, Inbetriebnahme
- Automotive — Antrieb, Batterie, Fahrfunktion
- Medizintechnik — Wirkprinzip, SaMD, vor der Zulassung
- Pharma & Life Sciences — Wirkstoff, Formulierung, Bioprozess
- Bauindustrie — Bauverfahren, Baustoff, Bauteilversuch
- Energie & Cleantech — Zelle, Speicher, Netzregelung
- Luft- & Raumfahrt — Struktur, Antrieb, Avionik
- Agrar & FoodTech — Verfahren, Rezeptur, Feldversuch
Schicken Sie uns ein Vorhaben, keinen Fragebogen
Im Erstgespräch reden wir über Ihre Architektur, nicht über Ihre Rechtsform. Nach dreißig Minuten wissen Sie, welcher Teil Ihrer Entwicklung förderfähig ist, in welcher Größenordnung, und ob sich ein rückwirkender Antrag lohnt. Das Erstgespräch ist kostenlos; 30 % des Honorars werden mit dem BSFZ-Bescheid fällig, 70 % erst nach der Auszahlung.
Erstgespräch vereinbarenWeiterlesen
- Der FZulG-Antrag in zwei SchrittenBSFZ-Antrag und Finanzamtsantrag: Reihenfolge, Fristen, Bearbeitungsdauer.
- Forschungszulage berechnenPersonalkosten, F&E-Anteil und Auftragsforschung eingeben, Betrag ablesen.
- Welche Personalkosten zählenArbeitgeberbrutto, anteilige Zuordnung und was bei Werkstudenten und Freelancern gilt.
- Zeiterfassung für F&E-StundenWie eine vorhandene Erfassung finanzamtsfest auf Vorhaben umgelegt wird.
- BSFZ-Ablehnung erhaltenBescheid lesen, Ablehnungsgrund bestimmen, zwischen Einspruch und Neuantrag entscheiden.
- Bewilligte VorhabenAnonymisierte Fälle aus Software, Maschinenbau und Medizintechnik mit Beträgen.
- Software als MedizinproduktWenn Ihre Software unter die MDR fällt: Abgrenzung von Entwicklung und Zulassung.
- Embedded Software im FahrzeugSteuergeräte, Bussysteme und funktionale Sicherheit als F&E-Vorhaben.
Max Nodes
Gründer und Geschäftsführer von NOVARIS Consulting. Spezialisiert auf die steuerliche Forschungsförderung (FZulG) seit 2021; 25 von 25 begleiteten BSFZ-Anträgen bewilligt (Stand 09/2026). Max Nodes