BSFZ-Antrag für Software: Die drei Gründe, warum er abgelehnt wird

Software-Vorhaben werden bei der Forschungszulage öfter abgelehnt als der Durchschnitt. Selten, weil die Arbeit nicht förderfähig wäre. Meistens, weil der Antrag die falsche Geschichte erzählt. Drei Muster tauchen immer wieder auf. Sie haben alle dieselbe Wurzel: Entwickler beschreiben, was sie gebaut haben, und die Bescheinigungsstelle will wissen, was daran ungewiss war.

Grund 1: Du beschreibst das Produkt statt die technische Unsicherheit

Das ist der häufigste Fehler. Der Antrag liest sich wie eine Feature-Liste oder ein Pitch an Investoren. Er erklärt, was die Software kann und für wen sie nützlich ist. Über die technische Frage, die zu Beginn offen war, steht nichts.

Die BSFZ interessiert nicht, ob dein Produkt am Markt neu ist. Sie fragt, ob die Entwicklung ein technisches Problem gelöst hat, dessen Lösung nicht von vornherein klar war.

So nicht:

Wir haben eine Plattform entwickelt, mit der Nutzer ihre Belege automatisch erfassen. Die Anwendung nutzt moderne KI und ist besonders benutzerfreundlich.

Besser:

Zu Beginn war unklar, ob sich Belege aus heterogenen Quellen (Foto, PDF, Scan) zuverlässig strukturieren lassen, ohne pro Lieferant eine eigene Vorlage zu pflegen. Bestehende OCR-Verfahren ordneten Tabellenpositionen in unseren Tests nur unzureichend zu. Wir haben untersucht, ob eine Kombination aus Layout-Erkennung und einem eigens trainierten Modell die Fehlerquote unter einen praktikablen Wert senkt. Ob das erreichbar ist, stand am Anfang nicht fest.

Die zweite Version sagt nichts über Benutzerfreundlichkeit. Sie sagt, was offen war.

Grund 2: Du grenzt nicht zum Stand der Technik ab

Wenn es für dein Problem eine bekannte, dokumentierte Lösung gibt, ist es keine Forschung. Die Prüfstelle erwartet deshalb, dass du zeigst, warum vorhandene Methoden, Bibliotheken oder Produkte nicht ausgereicht haben.

Viele Anträge überspringen das. Sie behaupten Neuartigkeit, ohne den Bezugspunkt zu nennen. Dann bleibt offen, gegenüber was das Vorhaben neu sein soll.

Konkret heißt das: Nenne, was es schon gab, und warum du damit nicht ans Ziel kamst. "Wir haben Bibliothek X und Ansatz Y geprüft. X skaliert bis Z, darüber bricht die Latenz ein. Y setzt Annahme A voraus, die in unserem Fall nicht gilt." Solche Sätze belegen, dass du nicht das Rad neu erfunden, sondern an einer echten Grenze gearbeitet hast.

Grund 3: Du zeigst die Systematik nicht

Das Gesetz verlangt ein planmäßiges Vorgehen. Ein Antrag, der nur ein Ergebnis präsentiert, lässt offen, ob dahinter Forschung oder Zufall stand.

Die Bescheinigungsstelle will einen roten Faden sehen: Welche Hypothese stand am Anfang? Wie bist du vorgegangen? Welche Ansätze hast du verworfen, und warum? Welche Meilensteine gab es?

Gerade verworfene Ansätze sind wertvoll. Wenn du beschreibst, dass du drei Wege probiert hast und zwei an einer konkreten technischen Hürde gescheitert sind, belegst du Unsicherheit und Systematik in einem Satz. Viele Entwickler lassen das weg, weil Fehlschläge sich im Antrag falsch anfühlen. Im BSFZ-Kontext sind sie ein Pluspunkt.

Das Muster dahinter

Alle drei Gründe laufen auf dasselbe hinaus. Du hast die Arbeit gemacht, aber du erzählst sie aus der Produktperspektive. Der Antrag braucht die Forschungsperspektive: Was war offen, gegenüber welchem Stand der Technik, und wie bist du systematisch vorgegangen.

Das ist Übersetzungsarbeit, keine neue Arbeit. Die technische Unsicherheit war ja da, sonst hättest du nicht so lange daran gesessen. Du musst sie nur sichtbar machen.

Softwarezulage führt dich genau durch diese Übersetzung. Statt eines leeren Formulars bekommst du Fragen, die deine Arbeit in die drei Punkte zerlegen, auf die die BSFZ achtet.

Allgemeine Information, keine Steuer- oder Rechtsberatung. Maßgeblich sind das FZulG und die Prüfung der BSFZ im Einzelfall. Stand 2026.