Forschungszulage für Softwareprojekte: Was technische Teams nachvollziehbar belegen müssen
Eine Software funktioniert, die Architektur steht und im Ticketsystem sind zahlreiche Aufgaben abgeschlossen. Für einen Forschungszulagenantrag bleibt trotzdem eine entscheidende Frage offen: Welche wissenschaftliche oder technische Ungewissheit wurde untersucht und wie ist das Team dabei vorgegangen?
Diese Lücke begegnet mir in meiner Beratung zur Forschungszulage. In einer Nachforderung wollte die Bescheinigungsstelle Forschungszulage, kurz BSFZ, wissen, welche Tätigkeiten hinter mehreren Arbeitspaketen steckten. In den nachgefragten Paketen standen Arbeitsziele. Die konkreten Schritte dahin blieben zu wenig deutlich.
Die Arbeit war erfolgt. Wir mussten genauer erklären, welche Schritte dazugehörten und wie sie zusammenhingen.
Solche Probleme beginnen häufig schon vor der Einreichung. Eine Vorführung zeigt, was ein System kann. Die Architektur erklärt, wie es aufgebaut ist. Beides beschreibt aber noch nicht ausreichend, welche technische Frage offen war und wie sie bearbeitet wurde.
Die folgenden Beobachtungen stammen aus unterschiedlichen Projektgesprächen, fachlichen Vorprüfungen und der Bearbeitung einer Nachforderung. Sie zeigen, wie sich technische Teams vorbereiten können, bevor eine Rückfrage zum Suchauftrag im eigenen Projektarchiv wird.
Das Wichtigste zur Vorbereitung
Die Entwicklungsarbeit muss nachvollziehbar sein. Eine Produktbeschreibung oder Liste eingesetzter Technologien reicht dafür nicht.
Kennzahlen brauchen einen Kontext. Messgrösse, Vergleichsbasis, Testbedingungen und Datenherkunft bestimmen ihre Aussagekraft.
Geplante Arbeit bleibt als geplant erkennbar. Zielwerte dürfen nicht wie bereits erreichte Ergebnisse erscheinen.
Zeitablauf und Arbeitsaufwand brauchen eigene Grundlagen. Aus einem Commit lassen sich keine verlässlichen Arbeitsstunden ableiten.
Die technische Rückprüfung gehört dazu. Eine fachlich verantwortliche Person sollte den vollständigen Entwurf prüfen.
Was die Forschungszulage mit Software-entwicklung zu tun hat
Die Forschungszulage ist eine steuerliche Förderung für Forschung und Entwicklung in Deutschland. Das Verfahren besteht aus zwei Stufen: Bei der BSFZ wird die Bescheinigung für das Vorhaben beantragt, beim Finanzamt anschliessend die Forschungszulage.
Für die fachliche Prüfung müssen drei Kriterien gemeinsam erfüllt sein:
Kriterium | Die zentrale Frage |
|---|---|
Neuartigkeit | Welche Erkenntnisse sollen gewonnen oder welche vorhandenen Kenntnisse auf neue Weise genutzt werden? |
Wissenschaftliches oder technisches Risiko | Welche Hindernisse könnten dazu führen, dass der Lösungsansatz scheitert oder verändert werden muss? |
Planmässigkeit | Mit welchen Aufgaben, Methoden und Arbeitsschritten wird die offene Frage untersucht? |
Der BSFZ-Prüfleitfaden verlangt die Einordnung gegenüber dem Wissen im Unternehmen und im betreffenden Wirtschaftszweig. Ein für das eigene Unternehmen neues Produkt genügt nicht automatisch. Auch eine neue Kombination vorhandener Technologien kann dazugehören, sofern die Anforderungen an Forschung und Entwicklung erfüllt sind.
Für Softwareteams bedeutet das: Die eingesetzte Technologie allein beantwortet die Förderfrage nicht. Auch bei KI-Anwendungen muss nachvollziehbar werden, worin die technische Ungewissheit besteht und wie sie untersucht wird.
Eine präzise Beschreibung kann fehlende Forschungssubstanz nicht ersetzen. Das Ergebnis einer fachlichen Klärung kann deshalb auch sein, dass ein Vorhaben für die Forschungszulage nicht infrage kommt.
Der erste Entwurf kann am eigentlichen Problem vorbeigehen
Ich habe selbst einen Teilaspekt einer Entwicklung zu früh in den Mittelpunkt gestellt. Die fachliche Rückmeldung war eindeutig: Dieser Zuschnitt traf das eigentliche Problem nicht ausreichend.
Einzelne Aussagen im Entwurf konnten stimmen, während die Beschreibung des Vorhabens insgesamt zu kurz griff.
Es folgte eine Entscheidung über den Arbeitsumfang. Die Wahl fiel auf einen enger begrenzten Ansatz, der erst noch bearbeitet werden sollte. Die grössere Aufgabe war damit nicht gelöst. Im Entwurf musste dieser Ansatz deshalb als geplante Arbeit erscheinen.
An solchen Stellen muss ich mit dem Team noch einmal zurückgehen:
Welche Aufgabe soll das Gesamtsystem lösen?
Welcher zunächst gewählte Weg reicht dafür nicht aus?
Was müsste geändert oder untersucht werden?
Erst dann lässt sich prüfen, welcher Arbeitsumfang fachlich zusammengehört und wie er sich vom Stand der Technik abgrenzt.
Bringt zum Projektgespräch deshalb einen konkreten Problemfall mit. Erklärt den versuchten Lösungsweg und die Beobachtung, die gegen ihn sprach. Eine Liste eingesetzter Technologien hilft dabei weniger als die Erklärung, weshalb ein verfügbares Verfahren die Anforderung unter den konkreten Bedingungen nicht erfüllte.
Wenn daraus eine zusätzliche Untersuchung entsteht, müsst ihr entscheiden, ob ihr sie tatsächlich leisten wollt und könnt. Eine neue Forschungsaufgabe verändert auch den Aufwand.
Eine Kennzahl kann mehr versprechen, als gemessen wurde
Bei einer eigenen fachlichen Vorprüfung vor einem möglichen Antrag musste ich klären, worauf sich eine genannte Leistungszahl bezog.
Sie beschrieb den Zusatzaufwand einer Funktion gegenüber einem Betrieb ohne diese Funktion. Einen Leistungsvorsprung gegenüber einer gleichwertigen alternativen Lösung belegte sie nicht.
Die Bezugsgrösse änderte damit, welche Aussage sich aus der Zahl ableiten liess.
In einem anderen Vorgang widersprachen sich zunächst die genannten Zielwerte. Nach einer Rückfrage korrigierte der technische Verantwortliche die abweichende Angabe.
Ausserdem klärten wir, welche Fälle zur Verbesserung des Verfahrens dienen sollten und welche erst für die anschliessende Prüfung vorgesehen waren. Die Zielwerte waren damit eindeutig beschrieben. Ein Ergebnis belegten sie nicht.
Auch die Herkunft der Testfälle musste erläutert werden: Stammen sie aus tatsächlich aufgetretenen Fehlern, wurden historische Fälle nachgestellt oder wurden Fälle eigens für den Test konstruiert?
Diese Unterscheidung verändert, was ein Ergebnis aussagen kann.
Diese Angaben gehören zu einer technischen Kennzahl
Angabe | Was nachvollziehbar bleiben sollte |
|---|---|
Messgrösse | Was wurde tatsächlich gemessen? |
Bezugsgrösse | Womit wird der Wert verglichen? |
Testbedingungen | Unter welchen Bedingungen entstand das Ergebnis? |
Datenherkunft | Woher stammen die untersuchten Fälle? |
Status | Ist es ein Messwert, ein Zielwert oder eine Annahme? |
Verwendung | Dienten die Fälle der Entwicklung oder der anschliessenden Prüfung? |
Wenn ihr euer Verfahren an bestimmten Fällen verbessert, kennzeichnet diese als Entwicklungsbestand. Ein separater Prüfbestand kann anschliessend zeigen, wie es mit unbekannten Fällen umgeht.
Fehlen solche Angaben, beginnt die Arbeit mit einer fachlichen Rückfrage. Weitere Nachkommastellen machen den Wert nicht belastbarer.
Manchmal lässt sich nur eine qualitative Beobachtung vertreten. Das sollte im Entwurf sichtbar bleiben.
Die Zeitachse muss zur tatsächlichen Entwicklungsarbeit passen
In einer Vorprüfung reichten die datierten Einträge im Versionsverlauf nicht aus, um den Beginn einzelner Tätigkeiten sicher festzustellen.
Sie lieferten zeitliche Anhaltspunkte. Wann die betreffende Arbeit begonnen hatte, blieb daraus unklar. Ich habe deshalb nach der tatsächlich neu hinzugekommenen technischen Aufgabe und ihrer zeitlichen Einordnung gefragt. Der Beginn blieb in dieser Klärung zunächst offen.
Für einen Arbeitsplan braucht ihr Zeiträume, die sich erklären lassen. Dabei hilft eine kurze Entwicklungschronik:
Welche Frage kam hinzu?
Welcher Versuch oder welche Entscheidung folgte?
Welche Aufzeichnung stützt die zeitliche Einordnung?
Verknüpft dafür vorhandene Tickets, Versionsstände und Versuchsnotizen. Wo sich ein Beginn nur eingrenzen lässt, sollte diese Unsicherheit erhalten bleiben.
Zeitliche Abfolge und geleisteter Aufwand brauchen jeweils eine eigene Grundlage. Aus einem Commit lassen sich keine verlässlichen Arbeitsstunden ableiten. Fachliche Notizen können Zeitaufzeichnungen ergänzen, ersetzen sie aber nicht.
BSFZ-Nachforderung: Wenn hinter Arbeitspaketen die Tätigkeiten fehlen
Damit zurück zur Nachforderung vom Anfang. Gefragt waren Tätigkeiten in bestimmten Arbeitspaketen.
Die überarbeitete Antwort beschrieb, welche Varianten verändert, welche Prüfungen durchgeführt und wie die Beobachtungen gegenübergestellt worden waren.
Ein Vergleich blieb qualitativ, weil die unterschiedlichen Bedingungen keine isolierte Zuordnung einzelner Wirkungen erlaubten. Auch diese Grenze blieb in der Antwort erhalten.
Beim Überarbeiten kam ein zweiter Punkt hinzu. Mein erster Vorschlag stellte die Tätigkeiten zu stark als getrennte Zeitblöcke dar. Die fachliche Rückmeldung zeigte, dass Arbeiten weiterliefen, wiederholt wurden und sich überschnitten.
Ich habe die Zeiträume daraufhin als Arbeitsschwerpunkte mit Überschneidungen beschrieben und den Zusammenhang des Vorhabens deutlicher gemacht. Die Arbeitsstunden wurden aus dieser Textänderung nicht neu abgeleitet.
Der fachliche Ansprechpartner prüfte und bestätigte die vollständige Endfassung. Anschliessend wurde sie über das Portal an die BSFZ übermittelt.
Damit war die Nachforderung beantwortet. Über den späteren Bescheid sagt dieser Bearbeitungsschritt nichts aus.
Rückfragen einzeln beantworten
Für eine solche Antwort hilft es, die Nachforderung in einzelne Fragen zu zerlegen. Ordnet jeder Frage die fachlich verantwortliche Person und die vorhandenen Belege zu.
Klärt dabei auch, ob Angaben aus dem Antrag berichtigt werden müssen. So fällt eher auf, wenn ein langer neuer Text die eigentliche Frage weiterhin offenlässt.
Die BSFZ-Hinweise zu Nachforderungen bitten ausdrücklich darum, die Antwort von Fachpersonen geben zu lassen, die mit dem Vorhaben betraut sind. Zur Beantwortung stehen erneut 4’000 Zeichen zur Verfügung.
Das spricht für eine genaue Auswahl: Ein erläutertes Vorgehen im nachgefragten Arbeitspaket hilft mehr als eine weitere allgemeine Beschreibung des Produkts.
Checkliste: So bereiten sich technische Teams vor
Aus diesen Erfahrungen würde ich vor einem Projektgespräch vier Dinge zusammenstellen:
Vorbereitung | Was konkret vorliegen sollte |
|---|---|
Technischer Problemfall | Versuchter Lösungsweg, beobachtete Grenze und daraus folgende Entscheidung. |
Fachliche Belege | Unterlagen, in denen Messwerte, Zielwerte, Annahmen und offene Aussagen unterscheidbar sind. |
Entwicklungschronik | Zeitliche Einordnung mit nachvollziehbaren Quellen sowie gesondert belegte Aufwandsangaben. |
Fachliche Verantwortung | Eine Person, die die technische Arbeit erklären und den vollständigen Entwurf auf Richtigkeit prüfen kann. |
Die Unterlagen können im vorhandenen Repository oder Projektordner bleiben.
Entscheidend ist, dass die Person, die eine Aussage prüft, ihren Ursprung findet.
Für die fachlichen Angaben zur Vorhabenbeschreibung nennt die BSFZ ein Limit von insgesamt 4’000 Zeichen. Weitere Angaben, etwa der tabellarische Arbeitsplan, kommen hinzu. Was in den kurzen Beschreibungstext gehört, sollte deshalb auf einer ausführlicheren fachlichen Grundlage beruhen.
Plant für die technische Rückprüfung Zeit ein. Die dafür verantwortliche Person muss beurteilen können, ob Entwicklungsziel, Untersuchungen und Arbeitsstand richtig wiedergegeben sind. Eine Zustimmung zu einzelnen Fachbegriffen reicht dafür nicht.
Die Nachforderung vom Anfang bezog sich auf Arbeit, die längst erledigt war. Die Antwort entstand aus vorhandenen Angaben und den fachlichen Korrekturen.
Genau diese Übersetzung verdient vor der Einreichung Aufmerksamkeit: Kann jemand, der das Projekt nicht kennt, nachvollziehen, was untersucht wurde und wie die Schritte zusammenhingen?
Über den Autor
Martin Meng berät Unternehmen zur Forschungszulage und begleitet die fachliche Klärung und Antragstellung von Entwicklungsprojekten. Zu seiner Arbeit gehören die Vorbereitung von BSFZ-Anträgen und die Begleitung fachlicher Rückfragen. Die beschriebenen Erfahrungen stammen aus seiner Beratungspraxis.
