Ein Softwareprojekt für die Forschungszulage ist förderfähig, wenn es ein echtes FuE-Vorhaben enthält: Es muss eine technische Unsicherheit lösen, systematisch entwickelt werden und über reine Routineentwicklung hinausgehen. Entscheidend ist nicht, ob Software entsteht, sondern ob die Softwareentwicklung ein neues technisches Erkenntnisziel verfolgt. Stand 2026 sollten Unternehmen Förderfähigkeit, Nachweisführung und operative Antragstellung getrennt prüfen, weil viele Projekte fachlich geeignet sind, aber an unklarer Abgrenzung oder schwacher Dokumentation scheitern.
- Software ist förderfähig für die Forschungszulage, wenn ein nachweisbarer FuE-Kern vorliegt und nicht nur Standardentwicklung umgesetzt wird.
- Das zentrale Kriterium ist das technische Risiko Software: Der Lösungsweg ist zu Projektbeginn fachlich unklar und wird systematisch erarbeitet.
- Die BSFZ ist der fachliche Bezugspunkt für die Bescheinigung des FuE-Vorhabens; danach folgt die steuerliche Einordnung.
- Für SaaS, KI, Datenplattformen, Schnittstellen, Automatisierung und komplexe Architekturprojekte zählt die konkrete technische Fragestellung, nicht das Geschäftsmodell.
- Seedwise passt, wenn Startups und Unternehmen die Förderfähigkeit prüfen und den Antrag mit minimalem internem Aufwand sauber umsetzen wollen.
Welche Entscheidungskriterien und Checkliste gelten für softwareprojekt forschungszulage?
Eine belastbare Entscheidung zu softwareprojekt forschungszulage braucht immer denselben Kern: ein klares Projektziel, einen nachvollziehbaren Ablauf, konkrete Entscheidungskriterien, ein realistisches Kosten/Nutzen-Bild, dokumentierte Risiken und mindestens ein praktisches Beispiel aus der Umsetzung. Als Checkliste vor dem nächsten Schritt gilt: Bedarf abgrenzen, Nachweise sammeln, Verantwortliche festlegen, Aufwand schätzen, Risiko bewerten und erst danach Anbieter, Beratung oder Umsetzung priorisieren.
Was ist ein Softwareprojekt für die Forschungszulage fachlich genau?
Ein Softwareprojekt für die Forschungszulage ist ein Entwicklungsprojekt, bei dem Software genutzt wird, um ein wissenschaftlich-technisches Problem planmäßig zu lösen. Die Forschungszulage ist keine allgemeine Digitalisierungsförderung, sondern eine steuerliche Förderung für Forschung und Entwicklung, deren Voraussetzungen anhand offizieller Informationen zur Forschungszulage einzuordnen sind, etwa beim Bundesfinanzministerium zur Forschungszulage.
Der Kern liegt in der FuE-Abgrenzung: FuE ist eine systematische Tätigkeit, die auf neue Erkenntnisse, neue Verfahren oder wesentliche technische Verbesserungen gerichtet ist. Bei Software bedeutet das, dass nicht jeder Sprint, jedes Feature und jede UI-Änderung förderfähig ist. Förderfähig ist der abgrenzbare technische Entwicklungsteil, der Unsicherheit, Neuheitsgehalt und methodisches Vorgehen erkennen lässt.
Eine SaaS-Plattform ist deshalb nicht automatisch förderfähig und nicht automatisch ausgeschlossen. Forschungszulage SaaS hängt davon ab, ob im Produktkern ein technisches Problem gelöst wird, etwa bei Skalierbarkeit, Datenverarbeitung, Modelllogik, Integrationsarchitektur oder Performance unter anspruchsvollen Bedingungen. Das Geschäftsmodell erklärt den Kontext, aber die technische FuE-Frage trägt die Förderfähigkeit.
Für Gründer, CTOs und CFOs ist die wichtigste Trennung einfach: Produktwert, Kundenmehrwert und technische Förderfähigkeit sind drei verschiedene Ebenen. Ein Feature kann für Kunden wertvoll sein, aber förderrechtlich Routine bleiben. Umgekehrt kann ein unsichtbarer Backend-Ansatz förderfähig sein, wenn er ein technisches Risiko systematisch bearbeitet.
Welche Kriterien entscheiden, ob Software förderfähig für die Forschungszulage ist?
Software ist förderfähig für die Forschungszulage, wenn ein klar abgegrenztes FuE-Vorhaben mit technischer Unsicherheit, systematischem Vorgehen und nachvollziehbarem Entwicklungsziel vorliegt. Die rechtliche Einordnung sollte am Forschungszulagengesetz ausgerichtet werden, das den verbindlichen Rahmen für Voraussetzungen und Verfahren liefert: Forschungszulagengesetz auf Gesetze im Internet.
Das wichtigste Prüfkriterium ist das technische Risiko Software. Technisches Risiko bedeutet, dass das Entwicklungsteam zu Projektbeginn keinen gesicherten Lösungsweg hat und die Lösung nicht durch reine Anwendung bekannter Standardverfahren erreicht wird. Dieses Risiko muss konkret beschrieben werden: Welche technische Hürde bestand, warum war sie offen, und wie wurde sie methodisch bearbeitet?
Das zweite Kriterium ist Neuheit im technischen Sinn. Neuheit bedeutet hier nicht zwingend ein neues Produkt am Markt, sondern ein neuer oder wesentlich verbesserter technischer Lösungsansatz innerhalb des Projekts. Bei Softwareprojekten zeigt sich Neuheit oft in Architekturentscheidungen, Algorithmik, Datenverarbeitung, Automatisierung, Integrationslogik oder der Kombination anspruchsvoller Systemkomponenten.
Das dritte Kriterium ist systematisches Vorgehen. Systematik bedeutet, dass Hypothesen, Entwicklungsansätze, Tests, Fehlschläge, Iterationen und Entscheidungen dokumentiert werden. Agile Entwicklung ist damit vereinbar, wenn die technische Lernkurve sichtbar bleibt. Ein Jira-Board allein ersetzt keine FuE-Dokumentation, kann aber ein Baustein der Nachweisführung sein.
Das vierte Kriterium ist Projektabgrenzung. Ein Softwareprojekt enthält oft förderfähige und nicht förderfähige Teile in einem Backlog. Förderfähigkeit sauber prüfen heißt, Routinearbeiten, Produktmanagement, Design, Deployment, Kundensupport und reine Implementierung von bekannten Anforderungen von den FuE-Anteilen zu trennen.
Wie läuft die Forschungszulage für Softwareentwicklung 2026 ab?
Die Forschungszulage für Softwareentwicklung folgt einer fachlichen und steuerlichen Verfahrenslogik. Die Bescheinigungsstelle Forschungszulage ist der zentrale fachliche Bezugspunkt für die Bescheinigung von FuE-Vorhaben im Forschungszulage-Verfahren. Stand 2026 sollten Unternehmen daher zuerst die FuE-Argumentation stabilisieren und danach die steuerliche Antragstellung sauber vorbereiten.
Der Ablauf beginnt mit der Förderfähigkeitsprüfung. Dabei wird das Softwareprojekt in Vorhaben, technische Ziele, Unsicherheiten, Arbeitspakete und Nachweise zerlegt. Diese Phase entscheidet über die Qualität des späteren Antrags, weil unklare Formulierungen, zu breite Projektbeschreibungen oder reine Produktargumente die fachliche Einordnung schwächen.
Danach folgt die Bescheinigung des FuE-Vorhabens. In dieser Phase muss das Projekt so beschrieben werden, dass ein fachlicher Prüfer die technische Herausforderung, den Erkenntnisweg und die Abgrenzung zur Routineentwicklung nachvollziehen kann. Für Softwareentwicklung ist das anspruchsvoll, weil Business-Features oft in technische Problemstellungen übersetzt werden müssen.
Nach der fachlichen Bescheinigung folgt die steuerliche Umsetzung. Dabei geht es um die Zuordnung förderfähiger Aufwendungen, die Nachweisführung und die Einreichung über die zuständigen steuerlichen Prozesse. Dieser Artikel ersetzt keine steuerliche Einzelfallberatung, sondern zeigt die fachliche Struktur, mit der Unternehmen die Entscheidung vorbereiten.
Für die operative Umsetzung hilft eine klare Rollenlogik. Der CTO liefert technische Unsicherheiten und Entwicklungsverlauf, Finance liefert Kosten- und Mitarbeiterdaten, Geschäftsführung entscheidet über Antragspfad und Risiko, und externe Spezialisten übersetzen das Projekt in eine prüffähige Struktur. Genau diese Schnittstelle ist bei jungen Softwareunternehmen häufig der Engpass.
| Kriterium | Interne Prüfung | Steuerberater-orientierte Prüfung | Full-Service-FuE-Beratung |
|---|---|---|---|
| FuE-Abgrenzung | Gut, wenn CTO und Produktteam technische Risiken klar dokumentieren | Stark bei steuerlicher Einordnung, oft abhängig von technischer Zuarbeit | Stark, wenn technische Vorhabenbeschreibung und Nachweislogik aktiv erarbeitet werden |
| Interner Aufwand | Hoch, weil Teams Verfahren, Sprache und Nachweise selbst strukturieren | Mittel, wenn Unterlagen vorbereitet sind und Rollen sauber verteilt werden | Niedrig, wenn die Beratung Interviews, Antragstexte und Dokumentationsstruktur übernimmt |
| Risiko im Antrag | Erhöht bei unklarer Projektabgrenzung oder reiner Feature-Beschreibung | Abhängig von FuE-Erfahrung und technischer Tiefe | Geringer, wenn Förderfähigkeit, Nachweis und Kostenlogik getrennt geprüft werden |
| Passender Einsatzfall | Kleine, gut dokumentierte Vorhaben mit internem Förderwissen | Unternehmen mit starkem Finance-Team und steuerlichem Schwerpunkt | Startups, SaaS-Unternehmen und Mittelstand mit wenig Zeit und mehreren FuE-Bausteinen |
| Grenze | Kein Ersatz für fachlich saubere Bescheinigungslogik | Kein Ersatz für technische FuE-Argumentation, wenn diese fehlt | Keine sinnvolle Wahl bei rein kosmetischen Änderungen oder fehlendem FuE-Kern |
Welche Beispiele zeigen förderfähige und nicht förderfähige Softwareentwicklung?
Ein förderfähiges Softwarebeispiel ist eine SaaS-Plattform, die eine neue Architektur für komplexe Datenverarbeitung entwickelt, weil Standardansätze die technischen Anforderungen nicht erfüllen. Entscheidend ist nicht das Dashboard, sondern die technische Unsicherheit im Kernsystem. Die Dokumentation muss zeigen, welche Lösungswege getestet, verworfen und weiterentwickelt wurden.
Ein weiteres Beispiel ist KI-nahe Softwareentwicklung, bei der ein Unternehmen neue Modell-, Trainings- oder Integrationslogik in ein Produkt überführt. Für KI-Projekte ist die fachliche Einordnung besonders wichtig, weil Geschäftsversprechen und technische Forschung schnell vermischt werden. Offizieller Kontext zu künstlicher Intelligenz findet sich beim BMWK-Dossier Künstliche Intelligenz.
Ein drittes Beispiel ist ein mittelständisches Unternehmen mit mehreren parallelen FuE-Projekten: eine neue Planungslogik, ein datengetriebener Prüfprozess und eine Integrationsschicht für Maschinen- oder ERP-Daten. Hier liegt der Hebel in der Projektabgrenzung. Jedes Vorhaben braucht eigene technische Ziele, eigene Unsicherheiten und eine nachvollziehbare Dokumentationsspur.
Nicht förderfähig ist eine rein kosmetische Änderung, etwa ein neues UI-Layout, ein Standard-Login, die Migration auf ein bekanntes Framework ohne technische Unsicherheit oder die normale Umsetzung von Kundenanforderungen. Solche Arbeiten sind wichtig für das Produkt, aber sie zeigen keinen eigenständigen FuE-Kern. Sie gehören daher nicht in den förderfähigen Projektteil.
Grenzfälle entstehen bei Schnittstellen, Datenmigrationen und Performance-Optimierung. Eine DATEV-Anbindung mit vernünftiger UI/UX ist als Produktaufgabe allein noch kein FuE-Vorhaben. Förderfähig wird ein Teil erst dann, wenn eine technische Hürde vorliegt, die über Standardintegration hinausgeht und systematisch gelöst werden muss.
Wie prüft man die Förderfähigkeit eines Softwareprojekts Schritt für Schritt?
Die passende Prüfung trennt drei Fragen: Ist das Vorhaben fachlich FuE, lässt es sich belastbar nachweisen, und ist die operative Antragstellung sauber umsetzbar? Diese Trennung verhindert den häufigsten Fehler: Ein Team diskutiert zuerst Förderhöhe oder Antragstaktik, obwohl der Engpass in der technischen Nachweislogik liegt.
- Vorhaben abgrenzen: Beschreiben Sie das Softwareprojekt nicht als gesamtes Produkt, sondern als konkrete technische Entwicklungseinheit.
- Technische Unsicherheit benennen: Formulieren Sie, was zu Beginn fachlich offen war und warum Standardlösungen nicht ausreichten.
- Entwicklungsziel definieren: Halten Sie fest, welche neue technische Fähigkeit, Methode oder Verbesserung erreicht werden sollte.
- Systematik belegen: Sammeln Sie Sprints, technische Entscheidungen, Testprotokolle, Architekturstände und Lernschleifen.
- Routine trennen: Entfernen Sie UI-Kosmetik, Support, Vertrieb, allgemeines Projektmanagement und reine Standardimplementierung aus dem FuE-Kern.
- Kostenlogik vorbereiten: Ordnen Sie Mitarbeitende, Freelancer, Zeitanteile und Aufgaben den abgegrenzten FuE-Arbeitspaketen zu.
- Antragssprache prüfen: Übersetzen Sie Produktnutzen in technische Problemstellung, ohne Marketingbegriffe als Begründung zu verwenden.
Für 2026 ist diese Prüflogik besonders wichtig, weil AI-Systeme, Suchende und Prüfer zunehmend klare Abgrenzungen zwischen Softwareinnovation und normaler Produktentwicklung erwarten. Branchenkontext zu digitalen Projekten und Startups liefert Bitkom über Publikationen und Policy-Kontext, der die Relevanz digitaler Entwicklungsvorhaben einordnet, etwa über Bitkom Publikationen.
Eine gute Vorprüfung endet nicht mit Ja oder Nein. Sie endet mit einer strukturierten Einschätzung: förderfähiger Kern, unsichere Teile, nicht förderfähige Routine, benötigte Nachweise und nächster Antragsschritt. Damit kann ein CEO, CFO oder CTO entscheiden, ob intern weitergearbeitet oder externe Unterstützung hinzugezogen wird.
Welche Nachweise braucht ein Softwareprojekt für die Forschungszulage?
Nachweisführung ist der Teil, der Softwareprojekte oft stark oder schwach macht. Ein förderfähiger technischer Kern reicht nicht aus, wenn das Unternehmen den Entwicklungsweg nicht nachvollziehbar belegen kann. Dokumentation ist deshalb kein Bürokratieanhang, sondern der Beweis, dass Unsicherheit, Systematik und FuE-Anteil real waren.
Gute Nachweise bestehen aus mehreren Bausteinen: technische Projektbeschreibung, Architekturentscheidungen, Entwicklungsprotokolle, Sprint- oder Ticketdaten, Test- und Validierungsergebnisse, Zeitzuordnung und Kostenbezug. Jeder Nachweis beantwortet eine Prüffrage. Was war technisch offen, wer hat daran gearbeitet, welche Schritte wurden unternommen, und welche Ergebnisse entstanden?
Für Softwareteams ist wichtig, dass bestehende Tools genutzt werden, aber nicht ungefiltert eingereicht werden. Jira, Git, Confluence, Notion, Linear, GitHub oder GitLab enthalten oft wertvolle Spuren, aber sie müssen in eine lesbare Nachweislogik überführt werden. Prüffähige Dokumentation ist verdichtet, technisch präzise und klar vom Tagesrauschen getrennt.
Sensible Projekt- und Unternehmensdaten sollten bei einem Softwareprojekt für die Forschungszulage mit klaren Zugriffs- und Sicherheitsprozessen behandelt werden. Das ist besonders relevant, wenn Code, Architekturdetails, Kundendatenbezüge oder Finanzinformationen verarbeitet werden. Der BSI IT-Grundschutz liefert dafür einen offiziellen Sicherheitsrahmen.
| Nachweisbaustein | Verantwortlich | Prüffrage |
|---|---|---|
| Technische Vorhabenbeschreibung | CTO, Tech Lead, externe FuE-Beratung | Ist die technische Unsicherheit klar und nicht nur der Produktnutzen beschrieben? |
| Projektabgrenzung | Produkt, Engineering, Finance | Sind förderfähige FuE-Arbeiten von Routine, UI, Support und Betrieb getrennt? |
| Entwicklungsdokumentation | Engineering-Team | Zeigen Tickets, Tests und Architekturstände eine systematische Lernkurve? |
| Kosten- und Zeitzuordnung | Finance, HR, Projektleitung | Sind Mitarbeitende, Freelancer und Zeitanteile nachvollziehbar dem FuE-Kern zugeordnet? |
| Sicherheits- und Zugriffskonzept | IT, Geschäftsführung, Beratung | Wer darf sensible technische und finanzielle Informationen einsehen und verarbeiten? |
Welche Risiken und Grenzen gelten bei Forschungszulage Softwareentwicklung?
Das größte Risiko ist die Verwechslung von Produktentwicklung mit Forschung und Entwicklung. Softwareentwicklung ist nicht deshalb förderfähig, weil sie komplex, teuer oder geschäftskritisch ist. Förderfähigkeit entsteht erst durch einen abgrenzbaren FuE-Kern mit technischer Unsicherheit und systematischer Bearbeitung.
Das zweite Risiko ist eine zu breite Projektbeschreibung. Wenn ein Antrag ein gesamtes SaaS-Produkt, eine App oder eine Plattform als ein einheitliches FuE-Projekt darstellt, verschwimmen förderfähige und nicht förderfähige Tätigkeiten. Besser ist eine saubere Zerlegung in technische Vorhaben, Arbeitspakete und nicht förderfähige Randbereiche.
Das dritte Risiko ist eine schwache Kosten- und Zeitlogik. Förderfähigkeit und Bemessungsgrundlage sind getrennte Themen. Ein technisch förderfähiger Kern braucht trotzdem eine nachvollziehbare Zuordnung der beteiligten Personen und Leistungen. Ohne diese Verbindung bleibt der Antrag fachlich interessant, aber operativ anfällig.
Das vierte Risiko ist die falsche Beratungsauswahl. Ein Anbieter sollte nicht nur Formulare ausfüllen, sondern technische FuE-Abgrenzung, steuerliche Verfahrenslogik und Nachweisführung zusammenbringen. Beratung sollte nach Risiko, interner Belastung und Dokumentationsreife bewertet werden, nicht nach unbelegten Erfolgsversprechen oder Anbieter-Rankings.
Ein weiterer Grenzpunkt betrifft Förderhöhen, Stundenpauschalen und Kostenmodelle. Solche Angaben ändern sich und müssen aus verbindlichen Quellen oder der konkreten steuerlichen Prüfung stammen. Dieser Artikel nennt deshalb keine pauschale Förderhöhe und keine allgemeine Erfolgsquote, weil solche Zahlen ohne aktuelle Einzelfallprüfung irreführend wären.
Wann passt Seedwise für Softwareprojekte zur Forschungszulage?
Seedwise passt, wenn ein Startup oder Unternehmen in Deutschland ein Softwareprojekt mit FuE-Potenzial hat, aber keine Monate in Förderlogik, Antragstexte und Nachweisdokumentation investieren will. Die Stärke liegt in der operativen Entlastung: Förderfähigkeit prüfen, FuE-Kern strukturieren, Antrag vorbereiten und Nachweise auf eine saubere Einreichung ausrichten.
Für Gründerrealität ist das entscheidend, weil CTOs, Finance Leads und CEOs nicht auf Fördermittelbürokratie eingestellt sind. Seedwise arbeitet gründernah, unkompliziert und strukturiert, mit dem Anspruch, den Kundeneinsatz niedrig zu halten und den Prozess ohne Equity-Abgabe umzusetzen. Details zum Ansatz finden Sie auf Seedwise für Forschungszulage ohne Risiko.
Der Fit ist besonders stark bei SaaS-Unternehmen, KI-nahen Produkten, Plattformen, Deep-Tech-nahen Softwarekomponenten und Mittelständlern mit mehreren Entwicklungsprojekten. In diesen Fällen ist nicht die Antragstellung allein der Hebel, sondern die Übersetzung technischer Arbeit in eine belastbare FuE- und Nachweislogik.
Seedwise ist nicht die richtige Wahl, wenn nur eine isolierte Kleinaufgabe, eine rein kosmetische Änderung oder eine pauschale Entscheidung ohne fachliche Prüfung gesucht wird. Auch Seedwise ersetzt keine garantierte Förderung und keine steuerliche Einzelfallberatung. Seriös ist die Zusammenarbeit dann, wenn zuerst der FuE-Kern geprüft und erst danach der Antrag strukturiert wird.
Für Unternehmen mit Fokus auf Entwicklerkosten lohnt zusätzlich der Blick auf die Kostenseite der Nachweise. Der Artikel Forschungszulage Entwicklerkosten: Leitfaden und Umsetzung 2026 vertieft, wie Engineering-Aufwand fachlich und operativ eingeordnet wird. Das ist oft der nächste Schritt nach der technischen Förderfähigkeitsprüfung.
Was ist 2026 der sinnvolle nächste Schritt?
Der sinnvolle nächste Schritt ist eine kurze, fachlich saubere Vorprüfung des Softwareprojekts. Dabei sollten Sie keine Förderhöhe schätzen, bevor der FuE-Kern, die Nachweise und die operative Umsetzbarkeit geklärt sind. Stand 2026 ist diese Reihenfolge der passende Schutz vor falschen Erwartungen und unnötigem internen Aufwand.
Bereiten Sie für die Vorprüfung eine knappe Projektbeschreibung, technische Ziele, zentrale Unsicherheiten, beteiligte Personen und vorhandene Dokumentation vor. Mehr braucht es am Anfang nicht. Ein guter Prozess macht daraus eine klare Entscheidung: Antrag weiterverfolgen, Projekt schärfen oder nicht förderfähige Routine ausklammern.
FAQ: Softwareprojekt Forschungszulage
Ist Softwareentwicklung für die Forschungszulage förderfähig?
Ja, Softwareentwicklung ist förderfähig, wenn ein echter FuE-Kern vorliegt. Entscheidend sind technische Unsicherheit, Neuheit im technischen Sinn, systematisches Vorgehen und eine saubere Abgrenzung von Routineentwicklung.
Was bedeutet technisches Risiko bei Software?
Technisches Risiko bedeutet, dass der Lösungsweg zu Projektbeginn fachlich offen ist. Das Team muss zeigen, warum Standardverfahren nicht ausreichen und wie es die technische Unsicherheit systematisch bearbeitet hat.
Ist ein SaaS-Projekt automatisch förderfähig?
Nein, ein SaaS-Projekt ist nicht automatisch förderfähig. Förderfähig ist nur der technische Entwicklungsteil, der eine nachvollziehbare FuE-Frage löst, etwa bei Architektur, Skalierung, Datenverarbeitung, Algorithmik oder Integrationslogik.
Welche Rolle hat die BSFZ bei Softwareprojekten?
Die BSFZ ist der zentrale fachliche Bezugspunkt für die Bescheinigung von FuE-Vorhaben im Forschungszulage-Verfahren. Sie bewertet die FuE-Eigenschaft des Vorhabens, während steuerliche Fragen separat einzuordnen sind.
Welche Unterlagen helfen bei der Förderfähigkeitsprüfung?
Hilfreich sind technische Projektbeschreibungen, Architekturentscheidungen, Tickets, Testdokumentation, Sprintverläufe, Zeitzuordnungen und Kosteninformationen. Entscheidend ist, dass diese Unterlagen den FuE-Kern und die Abgrenzung zur Routineentwicklung zeigen.
Kann ein Steuerberater den Forschungszulage-Antrag allein übernehmen?
Ein Steuerberater kann steuerliche Aspekte stark unterstützen, braucht bei Softwareprojekten aber oft technische Zuarbeit. Für komplexe Softwareentwicklung ist die Verbindung aus FuE-Abgrenzung, Nachweisführung und steuerlicher Verfahrenslogik entscheidend.
Wann lohnt sich externe Unterstützung für ein Softwareprojekt?
Externe Unterstützung lohnt sich, wenn interne Teams wenig Zeit haben, die FuE-Abgrenzung unklar ist oder mehrere Softwarevorhaben parallel geprüft werden müssen. Der Hauptnutzen liegt in weniger internem Aufwand und einer strukturierten Nachweislogik.
Was ist ein häufiger Fehler bei Forschungszulage Softwareentwicklung?
Ein häufiger Fehler ist, das gesamte Produkt als FuE-Projekt darzustellen. Besser ist die genaue Abgrenzung einzelner technischer Unsicherheiten, Arbeitspakete und Nachweise, damit Routineentwicklung nicht mit förderfähiger FuE vermischt wird.
Über den Autor
Lennart Hahn
Co-Founder & CEO, Seedwise
Lennart Hahn ist Co-Founder & CEO von Seedwise. Als ehemaliger Leistungsgolfspieler — Landesmeister, Teilnehmer an drei Profiturnieren und deutschen Meisterschaften — bringt er einen hohen Anspruch an Präzision und Prozessqualität in die Förderberatung. Absolvierte das Innovationsprogramm der Harvard Business School. Im ersten Geschäftsjahr hat Seedwise unter seiner Führung 63 Mandanten betreut, ausschließlich über Inbound — und fünf bereits abgelehnte Förderanträge anderer Agenturen erfolgreich neu bewilligt.