Forschungs­zulage Software­entwicklung: 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
Beispiel: Dokumentabgleich

Software & IT: Zuordnungen prüfen

Software & IT: Zuordnungen prüfenAB

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

  • Fördersatz
    25 % der Bemessungsgrundlage, 35 % für KMU. Bei Vorhaben mit Beginn nach dem 31.12.2025 erhöht eine 20-%-Pauschale die Bemessungsgrundlage (§ 3 Abs. 3b FZulG); die Obergrenze von 12 Mio. € bleibt bestehen (§ 3 Abs. 5 FZulG).
  • Förderfähig
    Eigene Algorithmen, ML-Modelle, neuartige Architekturen, Protokolle, Embedded-Systeme. Entscheidend ist nicht die Branche, sondern ob Neuheit, Technisches Risiko und Systematik nachweisbar sind.
  • Obergrenze
    Bemessungsgrundlage 12 Mio. € pro Wirtschaftsjahr, maximale Forschungszulage 4,2 Mio. €.
  • Eigenleistung
    100 € je Arbeitsstunde, ausschließlich für Einzelunternehmer und Mitunternehmer von Personengesellschaften (GbR, OHG, KG, GmbH & Co. KG). Bei GmbH, UG oder AG zählt allein das Arbeitgeberbrutto angestellter Entwickler.
  • Auftragsforschung
    70 % der Kosten vergebener Entwicklungsaufträge sind ansetzbar (§ 3 Abs. 4 FZulG), auch bei externen Entwicklungsteams und Hochschulkooperationen.
  • Rückwirkend
    Anträge für abgeschlossene Wirtschaftsjahre ab 2022 sind möglich, solange die Festsetzungsfrist des jeweiligen Jahres offen ist.
  • 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.

    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.

    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
    „Wir haben das Matching neu gebaut, weil die alte Suche einfach zu schlecht getroffen hat. Der erste Ansatz war viel zu langsam, also haben wir das Modell verkleinert."

    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."

    Das ist die Arbeit. Derselbe Sachverhalt, vier Formulierungen und nur eine davon ist ein Antrag. Diese Übersetzung ist unsere eigentliche Leistung: aus dem, was Ihr Team ohnehin produziert, die Aussage zu bauen, die die Bescheinigungsstelle prüfen kann.
    Software-Haus mit 40 Entwicklern · Entwicklerstunden im Wirtschaftsjahr
    TätigkeitStunden
    Entwicklerstunden im Jahr64.000 h
    Entwicklung mit offenem Ergebnis35.200 h
    Auslieferung, Wartung, Konfiguration28.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.

    So machen wir es. Wir benennen konkret die Bibliotheken, Produkte und Veröffentlichungen, die geprüft und verworfen wurden, jeweils mit der technischen Eigenschaft, an der sie scheitern.
    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.

    So machen wir es. Wir formulieren das Risiko als offene technische Frage: welche Eigenschaft war vor Beginn nicht vorhersagbar, und woran genau wäre das Vorhaben gescheitert.
    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.

    So machen wir es. Wir leiten die Systematik aus Ihren eigenen Artefakten ab: Hypothese im Ticket, Experiment im Branch, Messung im Testlauf, Entscheidung im Review.
    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.

    So machen wir es. Wir schneiden das Vorhaben auf den Teil zu, der die drei Kriterien trägt, und trennen den Rest sauber ab. Das erhöht Bewilligungswahrscheinlichkeit und anrechenbare Summe zugleich.
    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.

    So machen wir es. Wir führen Vorhabenbeschreibung, Zeiterfassung und Antrag auf Forschungszulage von Anfang an gegen dieselbe Abgrenzung. Die Kostenseite entsteht nicht nachträglich.

    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.

    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 vereinbaren
    Max Nodes

    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