Technische Unsicherheit erklärt

Von Marvin Vocke, Co-Founder Grantonomy · Zuletzt aktualisiert: 4. Juni 2026

Technische Unsicherheit ist eines der entscheidenden Kriterien dafür, ob ein Projekt über die Forschungszulage förderfähig ist. Sie liegt vor, wenn zu Beginn eines Vorhabens technisch nicht sicher vorhersehbar war, ob und wie ein angestrebtes Ziel mit dem vorhandenen Wissen und mit verfügbaren Standardmethoden erreichbar ist. Fehlt diese Unsicherheit – etwa bei reiner Implementierung, Migration oder Standardkonfiguration – handelt es sich in der Regel nicht um Forschung und Entwicklung im Sinne des FZulG, sondern um Routine.

Das Wichtigste in Kürze

• Technische Unsicherheit ist eines der Kernkriterien dafür, ob ein Vorhaben als Forschung und Entwicklung nach dem FZulG gilt.

• Sie besteht, wenn zu Projektbeginn technisch nicht sicher war, ob und wie ein Ziel mit dem vorhandenen Wissen erreichbar ist.

• Reine Implementierung, Migration, Wartung und Standardkonfiguration enthalten typischerweise keine technische Unsicherheit und sind nicht förderfähig.

• Das Verfahren ist zweistufig: erst FuE-Bescheinigung über die BSFZ, dann Festsetzung beim Finanzamt über ELSTER.

• Für KMU kann die Förderquote 35 % der förderfähigen Aufwendungen betragen; für ab 2026 beginnende Vorhaben kommt zusätzlich eine pauschale Berücksichtigung von Gemein- und Betriebskosten hinzu.

Was bedeutet technische Unsicherheit bei der Forschungszulage?

Technische Unsicherheit beschreibt einen Zustand zu Projektbeginn: Es ist nicht sicher vorhersehbar, ob ein technisches Ziel überhaupt erreichbar ist oder auf welchem Weg. Eine erfahrene Fachperson könnte das Ergebnis mit dem allgemein verfügbaren Wissen nicht einfach ableiten. Genau diese Ungewissheit unterscheidet ein FuE-Vorhaben von normaler Entwicklungsarbeit.

Für die Forschungszulage steht technische Unsicherheit nicht allein. Sie ist eines von mehreren Merkmalen, die zusammen ein förderfähiges Vorhaben kennzeichnen: ein klares technisches Ziel, eine technische Neuartigkeit gegenüber dem bisherigen Wissensstand, die genannte Unsicherheit über den Lösungsweg sowie eine systematische, nachvollziehbare Vorgehensweise. Erst das Zusammenspiel dieser Punkte macht ein Projekt zu Forschung und Entwicklung.

Wichtig ist die Abgrenzung zum wirtschaftlichen Erfolg. Ein Projekt kann marktwirtschaftlich hochrelevant sein, ohne technisch unsicher zu sein – und umgekehrt. Entscheidend ist die konkrete technische Unsicherheit, nicht der erwartete Umsatz oder die Bedeutung für die Roadmap. Wie das gesamte Förderinstrument grundsätzlich funktioniert, ordnet unser Überblicksbeitrag Was ist die Forschungszulage als thematischer Pillar ein; die genauen Voraussetzungen vertieft der Beitrag zu Anspruch und Kriterien.

Rechtlich verankert ist die Förderung im Forschungszulagengesetz. Der vollständige Gesetzestext des FZulG ist frei einsehbar und sollte bei der Einordnung eines Vorhabens immer als Primärquelle dienen. Konkrete Aussagen zur Förderfähigkeit eines einzelnen Projekts müssen jedoch im Einzelfall geprüft werden.

Welche Projekte sind technisch unsicher?

Es lohnt sich, zuerst zu klären, was typischerweise nicht förderfähig ist. Reine Implementierung bekannter Verfahren, Standardintegrationen, UI-Redesigns, Wartung, Bugfixing, Migrationen ohne technische Herausforderung, Baukastenlösungen und kundenspezifische Konfigurationen enthalten in der Regel keine technische Unsicherheit. Sie sind handwerklich anspruchsvoll, aber ihr Ergebnis ist von Beginn an absehbar. Bei KI-Software gilt das oft für die bloße Nutzung einer LLM-API ohne eigene technische Tiefe.

Technisch unsicher und damit potenziell förderfähig wird es dort, wo der Ausgang offen ist. In der Softwareentwicklung betrifft das etwa hochskalierbare Datenarchitekturen, die heterogene Datenquellen in Echtzeit verarbeiten, mandantenfähig bleiben und unter Last stabile Ergebnisse liefern müssen. In der KI sind eigene Systeme zur Halluzinationsreduktion, zur Quellenpriorisierung, zur Evaluationslogik oder zur agentischen Entscheidungssteuerung relevant. Im Maschinenbau geht es häufig um Steuerungslogiken, Simulationen oder Sensorik, bei denen unklar ist, ob Datenqualität, Latenz, Robustheit oder Modellgenauigkeit unter realen Betriebsbedingungen erreichbar sind.

Die folgende Übersicht zeigt den Unterschied an typischen Beispielen. Die Zuordnung ist eine Orientierung, keine Garantie – maßgeblich bleibt die konkrete technische Unsicherheit im Einzelfall.

„Software ist nicht deshalb förderfähig, weil sie entwickelt wird. Sie wird dann interessant, wenn technische Unsicherheit systematisch gelöst wird und das Projekt sauber von Routineentwicklung abgegrenzt ist“, sagt Marvin Vocke, Co-Founder von Grantonomy.

Eine gute Abgrenzung bedeutet auch, bewusst nicht alles einzureichen. Ein Antrag, der nur die wirklich unsicheren Teile eines Projekts enthält, ist prüfbarer als ein Sammelantrag, der Produktarbeit, Support und Forschung vermischt. Wie diese Abgrenzung speziell für Software gelingt, zeigt der Leitfaden Software richtig fördern.

Wie weist man technische Unsicherheit nach?

Technische Unsicherheit wird zuerst gegenüber der BSFZ nachgewiesen, der Bescheinigungsstelle Forschungszulage. Sie prüft die fachliche FuE-Eigenschaft eines Vorhabens und interessiert sich vor allem dafür, welches technische Ziel verfolgt wurde, worin die Neuartigkeit lag, welche technische Unsicherheit bestand und wie systematisch daran gearbeitet wurde. Erst nach der FuE-Bescheinigung erfolgt der eigentliche Antrag beim Finanzamt über ELSTER.

Der häufigste Fehler ist eine zu unscharfe Formulierung. „Weiterentwicklung unserer Plattform“ beschreibt kein FuE-Vorhaben. Stark ist eine präzise technische Beschreibung, etwa die Entwicklung einer mandantenfähigen Echtzeitarchitektur zur Verarbeitung heterogener Datenströme mit stabiler Fehlerisolation und niedriger Latenz. Diese Formulierung zeigt, worin die Unsicherheit konkret liegen könnte.

Wichtig ist außerdem, technische Unsicherheiten nicht nachträglich zu erfinden, sondern bestehende Entscheidungen sauber zu rekonstruieren. Wenn ein Team verschiedene Architekturen getestet, Performance-Grenzen analysiert, Modellvarianten verglichen oder Lösungswege verworfen hat, sollte diese Logik sichtbar gemacht werden. Bestehende Unterlagen wie Architektur-Skizzen, technische Beschreibungen, Testprotokolle oder Experiment-Logs reichen dafür im ersten Schritt meist aus.

Genau an dieser Übersetzung setzt Grantonomy als technischer Partner an: bei der Vorqualifizierung, der Projektstrukturierung, der BSFZ-Antragstellung und der Dokumentation gegenüber Finanzamt und Steuerberater. Der Mehrwert liegt nicht im Ausfüllen eines Formulars, sondern darin, echte technische Arbeit in eine prüffähige FuE-Logik zu überführen.

Welche Kosten sind dabei förderfähig?

Steht fest, dass ein Vorhaben technische Unsicherheit enthält, folgt die Kostenseite. Förderfähig sind insbesondere Personalkosten der Mitarbeitenden, die an den unsicheren Arbeitspaketen gearbeitet haben, sowie Auftragsforschung. Nicht jede Entwicklerstunde zählt automatisch: Entscheidend ist, welche Rollen in welchem Zeitraum an förderfähigen Teilen mitgewirkt haben. Relevant können Backend-, Data-, Platform- oder AI-Engineers ebenso sein wie Gründer mit operativer technischer Arbeit.

Für die Höhe gilt: Für KMU kann die Förderquote 35 % der Bemessungsgrundlage betragen. Für ab 2026 beginnende FuE-Vorhaben kommt eine pauschale Berücksichtigung von Gemein- und Betriebskosten hinzu, wodurch die effektive Förderung höher liegen kann. Die Forschungszulage ist dabei gewinnunabhängig und lässt sich rückwirkend für mehrere Jahre sowie für künftige Jahre nutzen. Konkrete Beträge sind typischerweise im Einzelfall zu prüfen.

Auch externe Entwicklung verdient Aufmerksamkeit. Leistungen von Freelancern, Nearshore-Teams oder Agenturen können unter Voraussetzungen relevant sein, müssen aber sauber von klassischer Dienstleistung und reiner Implementierung abgegrenzt werden. Wer Auftraggeber ist und wo die Leistung erbracht wurde, sollte früh geklärt werden, damit die Kostenzuordnung später belastbar bleibt.

Welche Fehler kosten die Förderung?

Der erste Fehler ist eine zu breite Antragslogik. Wer die gesamte Produktentwicklung statt klar abgegrenzter Vorhaben beschreibt, macht den Antrag angreifbar. Die BSFZ bewertet konkrete Vorhaben mit Ziel, Unsicherheit, Arbeitspaketen und systematischer Vorgehensweise – nicht eine pauschale Roadmap.

Der zweite Fehler ist die Business-Perspektive im falschen Dokument. Aussagen wie „neues Marktsegment“, „bessere Conversion“ oder „höhere Umsatzpotenziale“ sind wirtschaftlich nachvollziehbar, beantworten aber nicht die fachliche Kernfrage. Für die Forschungszulage muss erklärt werden, was technisch unklar war und wie diese Unsicherheit gelöst werden sollte.

Der dritte Fehler ist zu späte Struktur. Müssen Teams Jahre später rekonstruieren, wer wann an welcher technischen Unsicherheit gearbeitet hat, steigt der Aufwand erheblich. Eine einfache, früh aufgebaute FuE-Dokumentationslogik genügt oft, um diesen Aufwand zu vermeiden. Grantonomy arbeitet ausschließlich erfolgsbasiert – die Vergütung fällt nur bei tatsächlicher Auszahlung an – und beginnt deshalb bewusst beim technischen Kern, nicht beim Formular.

Fazit

Technische Unsicherheit ist der Dreh- und Angelpunkt der Forschungszulage. Sie entscheidet darüber, ob ein Vorhaben als Forschung und Entwicklung gilt – und liegt nur dann vor, wenn zu Projektbeginn nicht sicher war, ob und wie ein technisches Ziel erreichbar ist. Reine Implementierung, Migration, Wartung und Standardkonfiguration scheiden in der Regel aus, während offene Architektur-, KI- oder Steuerungsfragen potenziell förderfähig sein können.

Wer die Förderung sichern will, sollte drei Dinge zusammen denken: die saubere fachliche Abgrenzung der unsicheren Teile, deren systematische Dokumentation und die nachvollziehbare Kostenzuordnung. Der Weg führt zweistufig über die FuE-Bescheinigung der BSFZ und anschließend über das Finanzamt. Maßgeblich bleibt immer die konkrete technische Unsicherheit im Einzelfall – sie ist im Zweifel fachlich zu prüfen.

Häufige Fragen zur technischen Unsicherheit

Was ist technische Unsicherheit bei der Forschungszulage?

Technische Unsicherheit bedeutet, dass zu Projektbeginn nicht sicher vorhersehbar war, ob und wie ein technisches Ziel mit dem vorhandenen Wissen erreichbar ist. Sie ist eines der Kernkriterien für ein förderfähiges FuE-Vorhaben nach dem FZulG. Fehlt sie, liegt in der Regel Routine vor.

Ist Software ohne technische Unsicherheit förderfähig?

Nein. Software ist nicht allein deshalb förderfähig, weil sie neu entwickelt wird. Reine Implementierung, Standardintegration, Wartung oder Migration ohne technische Unsicherheit sind typischerweise nicht förderfähig; entscheidend ist ein technisch unsicherer, neuartiger Kern.

Wer prüft die technische Unsicherheit?

Die fachliche Prüfung übernimmt die BSFZ, die Bescheinigungsstelle Forschungszulage. Sie stellt die FuE-Bescheinigung aus, bevor die Förderung beim Finanzamt über ELSTER festgesetzt wird. Das Verfahren ist also zweistufig.

Muss technische Unsicherheit dokumentiert werden?

Ja. Die BSFZ will nachvollziehen, welches Ziel verfolgt wurde, worin die Neuartigkeit lag, welche Unsicherheit bestand und wie systematisch gearbeitet wurde. Bestehende Unterlagen wie Architektur-Skizzen, Testprotokolle oder Experiment-Logs reichen im ersten Schritt meist aus.

Zählt die Nutzung einer LLM-API als technische Unsicherheit?

Die bloße Nutzung einer LLM-API ist in der Regel kritisch und enthält selten technische Unsicherheit. Anders kann es bei eigenen Systemen zur Halluzinationsreduktion, Quellenpriorisierung, Evaluationslogik oder agentischen Steuerung aussehen. Maßgeblich ist die konkrete technische Tiefe, die im Einzelfall zu prüfen ist.