Zum Inhalt springen
BlogFörderung

Wann ist Softwareentwicklung F&E? Die Abgrenzung für die Forschungszulage

Tobias Schütz

Tobias Schütz

Co-Founder, Seedwise

24. Juni 20263 Min. Lesezeit

Softwareprojekte gehören zu den häufigsten Anträgen auf Forschungszulage – und zu denen, die am häufigsten an einer Stelle scheitern: der Abgrenzung. Die Bescheinigungsstelle Forschungszulage (BSFZ) lehnt nicht ab, weil zu wenig entwickelt wurde, sondern weil die Beschreibung wie „normale Softwareentwicklung“ klingt. Dieser Beitrag zeigt, ab wann ein Softwarevorhaben als Forschung und Entwicklung gilt und wie du die förderfähigen Teile sauber herausarbeitest.

Das Kernkriterium: technische Unsicherheit

Entscheidend ist nicht, wie aufwändig oder teuer die Entwicklung war, sondern ob sie eine technische Unsicherheit überwindet. Das bedeutet: Zu Projektbeginn war fachlich nicht klar, ob und wie das technische Ziel erreichbar ist. Es gab keine offensichtliche Lösung, die ein erfahrener Entwickler einfach hätte umsetzen können. Genau diese Ungewissheit unterscheidet F&E von Routine.

Ein Vorhaben ist förderfähig, wenn es zugleich neuartig, schöpferisch, mit ungewissem Ergebnis, systematisch geplant und übertragbar ist. Bei Software liegt der Knackpunkt fast immer beim ungewissen Ergebnis – also der Frage, ob das Problem mit bekannten Mitteln überhaupt lösbar war.

Was bei Software als F&E zählt – und was nicht

Förderfähig (F&E)Nicht förderfähig (Routine)
Neuer Algorithmus, dessen Funktionieren offen warUmsetzung bekannter Algorithmen
Performance-/Skalierungsproblem ohne bekannte LösungStandard-Optimierung mit etablierten Mustern
Neuartige Architektur unter widersprüchlichen AnforderungenKonfiguration vorhandener Frameworks
ML-Modell, dessen Eignung experimentell erprobt wurdeAnbindung einer fertigen KI-API
Integration unter ungelösten technischen KonfliktenRoutine-Schnittstellen nach Doku

Die Trennlinie verläuft also nicht zwischen „einfach“ und „komplex“, sondern zwischen „Ergebnis war absehbar“ und „Ergebnis war offen“. Auch ein kleines Teilproblem kann förderfähig sein, wenn der Lösungsweg echt ungewiss war.

Wie schneide ich F&E-Teilprojekte sauber ab?

Die häufigste Ursache für Ablehnungen ist, dass ein ganzes Produkt als „Forschung“ dargestellt wird. Besser ist, gezielt die Teilprobleme herauszuschneiden, in denen echte technische Unsicherheit steckt:

  • Trenne Produkt von Vorhaben. Das Produkt insgesamt ist selten F&E – einzelne technische Herausforderungen darin schon. Beschreibe diese als eigenes Vorhaben.
  • Benenne die konkrete Unsicherheit. Was war zu Beginn unklar? Welche Lösung gab es noch nicht von der Stange? Warum hätte ein erfahrenes Team das nicht einfach umsetzen können?
  • Lass Routine weg. UI-Bau, CRUD, Standard-Integrationen, Konfiguration und Wartung gehören nicht ins Vorhaben – ihre Aufnahme schwächt den Antrag, statt ihn zu stärken.
  • Zeige den systematischen Weg. Hypothese, Experimente, verworfene Ansätze, Erkenntnis. Genau das macht aus „wir haben programmiert“ ein nachvollziehbares F&E-Vorhaben.

Wie detailliert muss die BSFZ-Projektbeschreibung sein?

Die Beschreibung muss nicht lang sein, aber spezifisch. Eine schlüssige Struktur beantwortet vier Fragen: Was war das technische Ziel? Worin lag die Unsicherheit (warum war die Lösung nicht offensichtlich)? Wie seid ihr systematisch vorgegangen? Was war neuartig am Ergebnis? Wer hier konkret wird – mit dem eigentlichen technischen Problem statt mit Marketing-Sprache – kommt deutlich seltener in Rückfragen.

Häufige Fehler bei der Abgrenzung

  • Das gesamte Produkt als Forschung darstellen statt der unsicheren Teilprobleme.
  • Aufwand und Komplexität betonen, aber die technische Unsicherheit nicht benennen.
  • Routine-Tätigkeiten mit aufnehmen und damit den F&E-Anteil verwässern.
  • In Produkt- und Nutzensprache schreiben statt in technischer Problemsprache.

Häufige Fragen

Ab wann gilt ein Softwareprojekt als F&E im Sinne der Forschungszulage?

Sobald es eine technische Unsicherheit überwindet: Zu Projektbeginn war fachlich nicht klar, ob und wie das Ziel mit bekannten Mitteln erreichbar ist. Reine Anwendung etablierter Verfahren, Konfiguration oder Routine-Entwicklung erfüllt das Kriterium nicht.

Wie verhindere ich, dass mein Antrag wie normale Softwareentwicklung wirkt?

Indem du nicht das Produkt, sondern die unsicheren Teilprobleme beschreibst – mit der konkreten technischen Unsicherheit, dem systematischen Vorgehen und dem Neuheitsgrad. Routine-Anteile gehören nicht ins Vorhaben.

Ist die Nutzung von KI-APIs oder Open-Source-Bibliotheken förderfähig?

Die bloße Anbindung fertiger APIs oder Bibliotheken ist Routine und nicht förderfähig. Förderfähig wird es, wenn darüber hinaus eine eigene, ergebnisoffene technische Entwicklung stattfindet – etwa wenn die Eignung eines Modells experimentell erprobt oder ein neues Verfahren darauf aufgebaut wird.

Dieser Beitrag ersetzt keine individuelle Beratung. Ob deine Entwicklungsarbeit förderfähig ist und wie sich die Vorhaben sauber abgrenzen lassen, klären wir im kostenlosen Erstgespräch. Hintergrund zu den Begriffen findest du im Glossar.

Forschungszulage mit Seedwise

Unsere Forschungszulage Beratung übernimmt den kompletten Antrag — rein erfolgsbasiert, unter 10 Stunden Aufwand für dein Team. Wie viel Förderung für dich drin ist, zeigt dir der Forschungszulage Rechner in zwei Minuten.

Zur Forschungszulage Beratung
#Forschungszulage#Softwareentwicklung#BSFZ#F&E
Tobias Schütz

Über den Autor

Tobias Schütz

Co-Founder, Seedwise

LinkedIn

Tobias Schütz ist Serienunternehmer und Co-Founder von Seedwise. Er hat fünf Unternehmen aufgebaut — darunter ein Health-Tech-Startup mit siebenstelliger Finanzierung und über 50.000 Kunden. Absolvierte das Innovationsprogramm der Harvard Business School. Die eigene Erfahrung mit einer Förderagentur, die Monate brauchte und kaum kommunizierte, hat ihn bewogen, Seedwise zu gründen: Innovationsförderung, die so funktioniert, wie Gründer es sich wünschen.

Weitere Artikel