Die Abgrenzung
Wo Entwicklung aufhört und Forschung anfängt.
Softwareunternehmen bauen über Jahre an einem Produkt. Für die Forschungszulage zählt davon nur der Teil, der technische Unsicherheit enthält. Login, Rollenrechte, Billing und Admin-Bereiche gehören fast nie dazu – nicht weil sie einfach wären, sondern weil der Lösungsweg bekannt ist.
Interessant wird es dort, wo eine Anforderung mit verfügbaren Mitteln nicht erfüllbar war. Eine Datenarchitektur, die heterogene Quellen in Echtzeit verarbeitet, mandantenfähig bleibt, Ausfälle isoliert und unter Last stabil bleibt, ist ein anderes Problem als die Anbindung einer dokumentierten Schnittstelle.
Bei KI-Komponenten ist die Grenze besonders scharf. Die Nutzung einer LLM-API einschließlich Prompt-Engineering ist Implementierung. Eigene Evaluationslogik, Absicherung gegen Halluzination, Quellenpriorisierung oder agentische Steuerung können technische Unsicherheit enthalten.
Eine gute Abgrenzung heißt auch, bewusst nicht alles zu beantragen. Ein Antrag, der nur die echten Unsicherheiten enthält, ist prüffähiger als ein Sammelantrag, der Produktarbeit, Support und Kundenanpassung mit einrechnet.
Die drei Kriterien in der Software
Neuheit
Keine verfügbare Bibliothek, kein etabliertes Muster erfüllt die Anforderung. Der Stand der Technik ist benannt.
Technische Unsicherheit
Ob der Zielwert erreichbar ist, steht vor der Umsetzung nicht fest. Termindruck zählt nicht.
Systematik
Hypothese, Implementierung, Messung, Iteration – nachvollziehbar in Versionsständen und Testergebnissen.
Achtzehn Tätigkeiten
Was in der Softwareentwicklung wie eingeordnet wird.
Die folgende Einordnung beschreibt typische Fälle. Maßgeblich ist immer das konkrete Vorhaben.
Tätigkeit
Befund
Worauf es ankommt
Nachweis
Entwurf und Erprobung einer mandantenfähigen Datenarchitektur, deren Isolations- und Lastverhalten vorab nicht bestimmbar war
Förderfähig
Verfügbare Architekturmuster müssen nachweislich an der Anforderung gescheitert sein
Architekturentscheidungen, Lasttests, verworfene Entwürfe
Verfahren zur Echtzeitverarbeitung heterogener Datenströme unter fester Latenzvorgabe
Förderfähig
Die Latenz- oder Durchsatzgrenze muss vorab benannt und unsicher gewesen sein
Messreihen, Zielwert gegen Ist, Iterationsstände
Verfahren für Konsistenz und Ausfallisolierung in verteilten Systemen
Förderfähig
Standardmuster müssen an einer konkreten Eigenschaft gescheitert sein
Fehlerinjektionstests, Konsistenzprotokolle
Entwicklung eigener Modell- oder Scoring-Komponenten im Produkt
Förderfähig
Eigene Trainings-, Evaluations- oder Absicherungslogik, nicht nur Modellauswahl
Experiment Logs, Metriken, Datensatzversionen
Offline-Fähigkeit mit eigener Konfliktauflösung
Förderfähig
Die Konfliktlogik muss über bekannte Verfahren hinausgehen
Spezifikation, Testfälle, Fehlerraten
Machbarkeitsstudie oder Prototyp, der nach Erprobung verworfen wurde
Förderfähig
Scheitern schadet nicht – entscheidend sind Systematik und Dokumentation
Versuchsplan, Ergebnis, Abbruchentscheidung
Entwicklung einer eigenen Such- und Indexierungslogik
Einzelfall
Nur wenn belegt ist, dass vorhandene Engines die Anforderung nicht erfüllen
Vergleichsmessungen gegen Standardlösungen
Performance-Optimierung unter realen Lastbedingungen
Einzelfall
Nur wenn der Zielwert zu Beginn als nicht sicher erreichbar galt
Ausgangs- und Zielwerte, Optimierungsschritte
Datenpipeline mit eigener Qualitäts- und Deduplizierungslogik
Einzelfall
Die Logik muss über Regelwerke und bekannte Verfahren hinausgehen
Fehlerquoten vorher und nachher, Verfahrensbeschreibung
Sicherheits- oder Verschlüsselungsarchitektur
Einzelfall
Kritisch bei Einsatz etablierter Bibliotheken, relevant bei neuartigen Anforderungen
Bedrohungsmodell, Prüfberichte, Entwurfsalternativen
Testautomatisierung und CI-Infrastruktur
Einzelfall
Interne Werkzeuge nur, wenn sie selbst technische Unsicherheit enthalten
Anforderungsprofil, Entwicklungsstände
Migration einer Anwendung in die Cloud
Nicht förderfähig
Relevant nur, wenn die Migration selbst ein ungelöstes technisches Problem enthält
—
Login, Rollen und Rechte, Billing, Admin-Oberflächen
Nicht förderfähig
Etablierte Muster, technischer Erfolg von Beginn an absehbar
—
Anbindung einer Drittanbieter-Schnittstelle nach dokumentierter Spezifikation
Nicht förderfähig
Integration ist Implementierung, keine Forschung
—
Neuimplementierung bestehender Funktionalität in anderer Sprache oder Framework
Nicht förderfähig
Refactoring ohne neue technische Frage
—
Nutzung einer LLM-API einschließlich Prompt-Engineering
Nicht förderfähig
Relevant wird erst eigene Evaluations- oder Steuerungslogik
—
Redesign der Oberfläche, Aufbau eines Designsystems
Nicht förderfähig
Gestaltung ist keine technische Unsicherheit
—
Wartung, Bugfixing, Support, Sicherheitsupdates, kundenspezifische Konfiguration
Nicht förderfähig
Laufender Betrieb im Rahmen bekannter Lösungswege
—
Dieselbe Tätigkeit kann in einem Vorhaben förderfähig und in einem anderen Routine sein. Entscheidend ist nicht, was gemacht wurde, sondern ob zu Beginn offen war, ob es funktioniert.
Häufige Ablehnungsgründe
Woran Softwareanträge typischerweise scheitern.
Produktbeschreibung statt Problembeschreibung
Der Antrag erklärt, was die Software kann, nicht welche technische Frage offen war. Die BSFZ liest daraus eine Produktentwicklung.
Zu breiter Projektzuschnitt
Das gesamte Release wird als ein Vorhaben eingereicht. Sobald Support, UI-Arbeit und Konfiguration enthalten sind, gerät der förderfähige Kern unter Verdacht.
Unsicherheit erst nachträglich konstruiert
Die technische Unsicherheit taucht nur im Antragstext auf, nicht in Tickets, Architekturentscheidungen oder Testergebnissen aus dem Projektzeitraum.
Stundenverteilung ohne Realitätsbezug
Gleichmäßige Anteile über Monate und Jahre hinweg sind ein bekanntes Prüfmuster. Die Zeiterfassung muss den tatsächlichen Verlauf abbilden.
Dokumentation
Die Belege liegen meist schon vor.
Softwareteams arbeiten in der Regel systematisch – nur nicht auf die Forschungszulage hin. Commits, Pull Requests, Architekturentscheidungen, Tickets, Benchmarks und Testprotokolle enthalten fast immer die Information, die BSFZ und Finanzamt brauchen.
Was fehlt, ist die Übersetzung. Die BSFZ will wissen, welches technische Ziel verfolgt wurde, worin die Neuartigkeit lag, welche Unsicherheit bestand und wie systematisch daran gearbeitet wurde. Das Finanzamt fragt später nach Kosten, Zeiträumen, Rollen und möglicher Doppelförderung.
Für rückwirkende Jahre gilt: Rekonstruktion ist möglich, aber sie braucht Anker in vorhandenen Artefakten und eine dokumentierte Methodik. Frei geschätzte Stunden halten einer Prüfung nicht stand.
Was wir typischerweise auswerten
Versionsverläufe und Architekturentscheidungen
Tickets, Epics und Sprint-Historie
Benchmarks, Lasttests und Experiment Logs
Rollen, Stundensätze und Personalstammdaten
Rechenbeispiel
Was ein Softwareteam typischerweise erreicht.
Beispielrechnung zur Veranschaulichung. Der FuE-Anteil ergibt sich aus der konkreten Abgrenzung und der Zeiterfassung, nicht aus einer Pauschale. 42 % ist kein gesetzlicher Satz, sondern der rechnerische Effektivwert aus 35 % Fördersatz und dem Gemeinkostenzuschlag.
Branchenlogik allein reicht nicht.
GrantonomyOS
Die Einordnung ist der Anfang. Belastbar wird ein Antrag erst, wenn Projektstruktur, Stunden, Kosten und Dokumentation über Jahre zusammenpassen — und einer Prüfung standhalten.
Vorprüfung
Vorprüfung der Vorhaben gegen die drei Kriterien, bevor Aufwand entsteht.
Antrags-Copilot
Projektbeschreibungen für die BSFZ, aus euren technischen Artefakten hergeleitet.
Zeiterfassung
Stunden und Rollen nach GoBD-Grundsätzen, monatlich festgeschrieben.
Audit-Ready AI
Simulierte Prüfung vor der Einreichung: wo die Argumentation noch nicht trägt.
FAQ
Fragen zur Forschungszulage in der Softwareentwicklung.
Ist Softwareentwicklung überhaupt förderfähig?
Ja, aber nicht pauschal. Förderfähig ist der Teil der Entwicklung, in dem technische Unsicherheit bestand. Das FZulG unterscheidet nicht nach Branche, sondern nach der Art der Tätigkeit.