Technische Unsicherheit beschreiben: BSFZ-Beispiele für Software-Projekte

Wenn ein Software-Antrag auf die Forschungszulage durchfällt, liegt es fast immer an einem Punkt: Die technische Unsicherheit ist nicht klar benannt. Sie ist das Herzstück der Bescheinigung. Wer sie sauber beschreibt, hat den schwersten Teil hinter sich.

Was die Prüfstelle unter technischer Unsicherheit versteht

Technische Unsicherheit heißt nicht Marktrisiko. "Wir wussten nicht, ob sich das verkauft" zählt nicht. Auch nicht "wir wussten nicht, ob wir es rechtzeitig schaffen". Gemeint ist eine fachliche Frage: Zu Beginn war offen, ob sich ein technisches Ziel mit den verfügbaren Methoden überhaupt erreichen lässt, oder auf welchem Weg.

Die Probe aufs Exempel: Hätte ein kompetenter Entwickler die Lösung vorher aus vorhandenem Wissen ableiten können? Wenn ja, fehlt die Unsicherheit. Wenn nein, weil eine Antwort erst durch Ausprobieren, Messen und Verwerfen entstand, bist du im förderfähigen Bereich.

Eine Formel, die hilft

Ein Satzgerüst, das die wichtigen Teile erzwingt:

Zu Beginn war unklar, ob [technisches Ziel] mit [verfügbaren Methoden] erreichbar ist, weil [konkrete Grenze des Stands der Technik]. Wir haben untersucht, ob [Hypothese oder Ansatz] das Problem löst.

Wenn du diesen Satz nicht ausfüllen kannst, ohne über dein Produkt statt über ein technisches Problem zu reden, ist das ein Warnsignal.

Drei Beispiele

Jeweils eine schwache und eine starke Formulierung für dasselbe Projekt.

Beispiel 1, Suche über große Datenmengen.

Schwach: "Wir haben eine schnelle Suchfunktion entwickelt, die auch bei vielen Daten gut funktioniert."

Stark: "Offen war, ob sich relevante Treffer über mehrere Millionen Dokumente in unter 100 Millisekunden liefern lassen, ohne die Trefferqualität zu verlieren. Klassische Volltextsuche war zu langsam, reine Vektorsuche lieferte zu viele falsche Treffer. Wir haben geprüft, ob ein hybrider Ansatz beide Grenzen gleichzeitig einhält."

Beispiel 2, Datenextraktion.

Schwach: "Unsere KI erkennt automatisch die wichtigen Felder in Dokumenten."

Stark: "Unklar war, ob sich Felder aus uneinheitlich aufgebauten Dokumenten ohne lieferantenspezifische Vorlagen zuverlässig zuordnen lassen. Verfügbare OCR- und Layout-Modelle lagen bei verschachtelten Tabellen unter einer brauchbaren Genauigkeit. Wir haben untersucht, ob ein eigenes Trainingsverfahren die Fehlerquote ausreichend senkt."

Beispiel 3, Echtzeit-Synchronisation.

Schwach: "Mehrere Nutzer können gleichzeitig am selben Dokument arbeiten."

Stark: "Offen war, ob sich gleichzeitige Bearbeitung durch viele Clients ohne sichtbare Konflikte und ohne zentralen Engpass umsetzen lässt. Bekannte Verfahren zur Konfliktauflösung skalierten in unseren Tests nicht über eine bestimmte Nutzerzahl hinaus. Wir haben geprüft, ob eine angepasste Datenstruktur die Konsistenz unter Last hält."

In allen drei Fällen verschwindet das Produktversprechen, und es bleibt: Was war offen, gegenüber welchem Stand der Technik, und was habt ihr untersucht.

Was du dafür festhalten solltest

Die beste technische Unsicherheit nützt nichts, wenn du sie ein Jahr später aus dem Gedächtnis rekonstruieren musst. Halte während der Arbeit ein paar Dinge fest: die Frage, die am Anfang offen war, die Ansätze, die du verworfen hast, und die Messungen, die den jeweiligen Weg gestützt oder gekippt haben.

Verworfene Ansätze sind dabei am wertvollsten. Sie belegen Unsicherheit und systematisches Vorgehen zugleich. Ein Commit-Verlauf, ein paar Notizen oder ein Entscheidungsdokument reichen oft schon.

Softwarezulage stellt dir genau diese Fragen, während die Erinnerung noch frisch ist, und formt deine Antworten in eine Beschreibung, die die BSFZ-Kriterien trifft.

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