Quandes logo

Sep 28, 2026 · 6 min read

Forschungszulage für Softwareentwicklung und KI

Welche Softwareentwicklungs- und KI-Vorhaben sind nach FZulG förderfähig? Abgrenzung gegen reguläre Entwicklung, drei Anwendungsmuster aus der KMU-Praxis, häufige Schreib-Fehler im BSFZ-Antrag.

Forschungszulage für Softwareentwicklung und KI

Softwareentwicklung und KI-Vorhaben sind im FZulG nicht pauschal förderfähig — und nicht pauschal ausgeschlossen. Entscheidend ist, ob das konkrete Vorhaben die drei BSFZ-Kriterien Neuartigkeit, technisches Risiko und Planmäßigkeit erfüllt. In der Praxis fällt die Abgrenzung zwischen förderfähiger FuE und regulärer Produktentwicklung gerade in der Software-Branche besonders schwer, weil viele Entwicklungs-Aufgaben äußerlich gleich aussehen.

Dieser Beitrag zeigt, wann Software- und KI-Vorhaben tragfähig in den FZulG-Pfad gehören, wann sie als reguläre Entwicklung gelten, und welche drei Anwendungsmuster in KMU-Beratungspraxis regelmäßig FZulG-fähig sind.

Das Wichtigste in Kürze

Warum die Abgrenzung in Software so schwer ist

Software-Entwicklung lebt im FZulG-Kontext mit einer strukturellen Eigenheit: das Endprodukt ist oft schwer von einer regulären Produktentwicklung zu unterscheiden, weil beide einen funktionierenden Code-Output erzeugen. Eine BSFZ-Begründung muss deshalb sehr klar zwischen dem Forschungsprozess (Wirkung unklar, Methodik experimentell) und dem Entwicklungsprozess (Wirkung erwartbar, Methodik bekannt) trennen.

Das fällt in der Praxis schwer, weil moderne Softwareentwicklung viele methodische Elemente teilt: Versionskontrolle, Tests, iterative Vorgehensweise. Die Abgrenzung liegt nicht im Vorgehen, sondern in der inhaltlichen Frage „war vor Beginn unklar, ob das gewählte Verfahren das Ziel erreichen kann". Wer in einem Software-Vorhaben diese Frage nicht klar beantworten kann, hat in der Regel ein Entwicklungs-Vorhaben, kein Forschungs-Vorhaben.

Drei förderfähige Anwendungsmuster

Muster 1 — Neue Algorithmen oder Modell-Architekturen. Ein KMU entwickelt einen Algorithmus, dessen Wirksamkeit für die konkrete Problemstellung vor Beginn nicht belegt ist. Beispiel: ein Maschinenbau-KMU entwickelt einen neuen Optimierungs-Algorithmus für Sondermaschinen-Steuerungen, bei dem nicht klar ist, ob die mathematische Modellierung die Genauigkeits-Anforderungen erfüllt. Das ist klassische FuE — die offene Frage ist inhaltlich, die Methodik experimentell.

Muster 2 — Etablierte Methoden auf neue Domänen-Daten. Ein KMU wendet eine etablierte Methode (z. B. transformerbasiertes Sprachmodell) auf eine bisher nicht erschlossene Domänen-Datenquelle an — und es ist vor Beginn unklar, ob die Methode auf diese Daten überhaupt sinnvoll transferiert. Diese Konstellation ist FZulG-fähig, wenn die Domänen-spezifische Wirksamkeit ein genuines Risiko trägt. Klassisches Beispiel: NLP-Verfahren auf spezialisierte Fach-Korpora aus regulierten Branchen, bei denen Sprache, Begriffe und Strukturen erheblich vom Trainings-Korpus abweichen.

Muster 3 — Neue Architekturen für nicht-funktionale Anforderungen. Eine KMU-Anwendung muss spezifische Anforderungen erfüllen — Latenz, Datenschutz-Architektur, Edge-Verarbeitung — für die keine etablierte Architektur existiert. Beispiel: eine Echtzeit-Bildanalyse, die vollständig auf einem Embedded-Gerät ohne Cloud-Anbindung läuft, mit Genauigkeits-Anforderungen über dem Stand der Technik für vergleichbare Geräte-Klassen. Hier liegt das Risiko in der Architektur-Frage, nicht in einzelnen Code-Stellen.

In allen drei Mustern liegt die Förderfähigkeit nicht im Software-Charakter, sondern in der inhaltlichen Unklarheit vor Beginn. Wer das Muster sauber im BSFZ-Antrag herausarbeitet, hat eine stabile Begründung.

Was nicht förderfähig ist

Drei Konstellationen, die häufig fälschlich als FuE eingereicht werden:

Reguläre Anwendung etablierter Frameworks. Ein neues CRM-System, eine neue Web-Anwendung, eine Migration auf eine neue Cloud-Infrastruktur. Auch wenn das Vorhaben groß und technisch anspruchsvoll ist — solange bekannte Methoden auf bekannte Anforderungen treffen, fehlt das genuine FuE-Risiko.

KI-Tool-Einführung. Die Implementierung eines bestehenden KI-Tools (ChatGPT-API-Integration, vortrainiertes Bilderkennungs-Modell, kommerzielles Sprachmodell) in einen Geschäftsprozess. Das ist Adoption, nicht Forschung. Die methodische Tiefe der Tool-Entwicklung sitzt beim Hersteller, nicht beim anwendenden KMU.

EU-AI-Act-Compliance. Die organisatorische und technische Anpassung an die Anforderungen des EU-AI-Acts (Verordnung 2024/1689) ist regulatorische Pflicht-Arbeit, nicht FuE — auch wenn sie aufwändig ist. Wer Compliance-Arbeit als Forschung deklariert, verfehlt das Kriterium der Neuartigkeit. Der Hub-Beitrag Agentisches Arbeiten KMU (H3) behandelt AI-Act-Pflichten separat.

Drei häufige Schreib-Fehler im BSFZ-Antrag für Software-Vorhaben

Fehler 1 — „State of the Art" wird nicht recherchiert. Eine Neuartigkeits-Behauptung ohne Bezug zu existierenden Tools, Bibliotheken oder Forschungspublikationen wirkt schwach. Korrektur: explizite Bezugnahme auf vergleichbare Open-Source-Projekte, kommerzielle Lösungen, oder Forschungsarbeiten, mit kurzer Begründung, warum sie nicht ausreichen.

Fehler 2 — Risiko wird als „Lernkurve" beschrieben. „Wir müssen uns in die Technologie einarbeiten" ist kein FuE-Risiko. Korrektur: das Risiko inhaltlich formulieren — welche Eigenschaft des Verfahrens ist vor Beginn unklar?

Fehler 3 — Planmäßigkeit als Sprint-Plan. Ein Scrum-Backlog ist keine FuE-Methodik. Korrektur: zumindest skizzieren, welche experimentellen Verfahren eingesetzt werden — Vergleichs-Experimente, Ablations-Studien, Validierungs-Methoden.

Diese drei Fehler treten in Software-Anträgen besonders häufig auf, weil die Branche eigene Methodik-Vokabular hat (Sprints, MVPs, Tickets), das in der BSFZ-Prüfung nicht trägt.

Verbindung zu den anderen E-Spokes und dem H3-Hub

Dieser Beitrag ist der domänen-spezifische Ableger des Spokes BSFZ-Kriterien (E2) für Software und KI. Wer die drei Kriterien generell verstehen will, beginnt dort. Für den Antragsprozess insgesamt: Forschungszulage beantragen (E1). Für die Stundenaufzeichnung in Software-Teams (oft die Stelle, an der schiefgeht, weil Sprint-Tickets keine FuE-Stunden sind): Stundenzettel Forschungszulage (E3).

Cross-Hub: Wer KI-Vorhaben aus der Quandes-agentic-Perspektive plant, findet die organisatorischen Voraussetzungen im Hub Agentisches Arbeiten KMU (H3) und in den Spokes KI-Agenten erstellen (C1) sowie Agentic Readiness KMU (C3). Die FZulG-Frage ist davon unabhängig — wer in den AI-Act-Compliance-Modus geht, ist nicht im FZulG-Pfad.

CTA

Wenn Sie ein Software- oder KI-Vorhaben planen und unsicher sind, ob es in den FZulG-Pfad oder den AI-Act-Compliance-Pfad gehört — oder wie die Neuartigkeits- und Risiko-Begründung für ein technisch ambitioniertes Vorhaben tragfähig formuliert wird — klärt der Forschungszulage-Check pro Teilvorhaben die FuE-Tragfähigkeit und schneidet den BSFZ-Antrag entsprechend.

CTA-Ziel: Forschungszulage-Check (Zielpfad /kontakt/forschungszulage-check/, bis Live-Schaltung Fallback /kontakt/).

Häufige Fragen

Ist Softwareentwicklung im KMU nach FZulG förderfähig?

Nur dann, wenn sie die drei BSFZ-Kriterien (Neuartigkeit, technisches Risiko, Planmäßigkeit) erfüllt. Reguläre Produktentwicklung mit bekannten Frameworks und Patterns ist nicht förderfähig, auch wenn sie technisch anspruchsvoll ist. Förderfähig sind in der Praxis vor allem neue Algorithmen, Domänen-Transfers etablierter Methoden und neuartige Architekturen für nicht-funktionale Anforderungen.

Sind KI-Vorhaben automatisch FZulG-fähig?

Nein. Die KI-Komponente an sich macht ein Vorhaben nicht förderfähig. Entscheidend ist, ob vor Beginn unklar war, ob die gewählte Methodik das Ziel erreichen kann. Die Integration eines bestehenden KI-Tools (z. B. ChatGPT-API) ist Adoption, nicht Forschung — und damit nicht förderfähig.

Was zählt als FuE in der Softwareentwicklung?

Vorhaben, in denen die Wirksamkeit eines Algorithmus, einer Modell-Architektur oder einer technischen Verfahrensweise vor Beginn nicht belegt ist. Die offene Frage muss inhaltlich sein („funktioniert die Methode überhaupt"), nicht nur zeitlich oder organisatorisch („wann sind wir fertig").

Sind AI-Act-Compliance-Arbeiten FZulG-fähig?

Nein. Regulatorische Anpassung an den EU-AI-Act (Verordnung 2024/1689) ist Pflicht-Arbeit, keine Forschung. Sie kann aufwändig sein, erfüllt aber nicht das Neuartigkeits-Kriterium. AI-Act-Compliance wird über reguläre Beratung oder ggf. BAFA-Beratungsförderung abgedeckt.

Wie unterscheide ich Forschungs- von Entwicklungsarbeit?

Über die Frage „war vor Beginn unklar, ob das gewählte Verfahren das Ziel erreichen kann". Wenn ja: Forschung. Wenn nein (nur zeitliche oder organisatorische Unklarheit): Entwicklung. Die methodischen Praktiken (Sprints, Tickets, Versionskontrolle) sind oft identisch — die inhaltliche Unklarheit ist der Unterschied.

Welche Schreib-Fehler vermeiden im BSFZ-Antrag?

Drei: Neuartigkeit ohne Bezug zu State of the Art, Risiko als „Lernkurve" beschrieben, Planmäßigkeit als bloßer Sprint-Plan. Software-Anträge fallen besonders häufig in diese drei Fehler, weil die Branchen-Vokabular im FZulG-Kontext nicht trägt.

Quellen