Kurzfassung: Eigene Algorithmen und Architekturen können FuE sein, wenn sie einen neuen technologischen Ansatz verfolgen und der Lösungsweg ungewiss ist. Standard-Websites, API-Konfiguration, Migration und Bug-Fixing sind Routine. Förderbeträge hängen von anerkannten Stunden, Zeitraum und KMU-Status ab.

Softwareentwicklung und Forschungszulage. Für viele Entwickler klingt das widersprüchlich. „Ich forsche doch nicht, ich programmiere.“ Viele Entwickler beschreiben ihre Arbeit so. Viele typische Entwickler-Tätigkeiten erfüllen die FuE-Kriterien des Forschungszulagengesetzes (FZulG). Auf der Seite Forschungszulage für Software-Entwicklung findest du eine ausführliche Übersicht mit förderfähigen und nicht förderfähigen Beispielen. Speziell für Freelance-Softwareentwickler gibt es einen eigenen Beitrag mit FuE-Anteil-Tabelle nach Profil.

Die Abgrenzung: FuE vs. Routinearbeit

Nicht jede Zeile Code ist FuE. Die entscheidende Frage: Arbeitest du an etwas Neuartigem, dessen Ausgang technisch unsicher ist?

Das ist FuE:

• Du entwickelst einen eigenen Algorithmus für ein spezifisches Problem
• Du baust eine neue Software-Architektur, die es so nicht gibt
• Du trainierst eigene KI/ML-Modelle mit ungewissem Ergebnis
• Du entwirfst ein neues Framework oder eine Bibliothek
• Du implementierst Echtzeit-Funktionalität mit neuen Ansätzen
• Du entwickelst neue Datenstrukturen für spezifische Anforderungen
• Du löst Skalierungsprobleme mit neuartigen Methoden

Das ist keine FuE:

• Standard-Website auf Basis von WordPress oder Shopify
• Konfiguration von SaaS-Produkten (Salesforce, HubSpot)
• Bug-Fixing und Wartung bestehender Software
• Migration auf eine neue Plattform ohne eigene Entwicklung
• UI-Redesign ohne technische Innovation
• Standard-API-Integration
• Deployment und DevOps-Routinearbeit

Weitere konkrete Beispiele aus der Praxis

KI und Machine Learning

Eigenes Modelltraining kann FuE sein, wenn Architektur, Trainingsverfahren oder Messmethode einen neuen technologischen Kern bilden und das Ergebnis vorab ungewiss ist. Fine-Tuning, Hyperparameter-Suche oder die Anwendung vortrainierter Modelle reichen allein regelmäßig nicht.

• Fine-Tuning von LLMs für domänenspezifische Aufgaben (juristisch, medizinisch, technisch)
• Computer-Vision-Pipelines mit eigener Vorverarbeitung und Modellarchitektur
• Empfehlungssysteme mit neuartigen Scoring-Algorithmen
• NLP-Verarbeitung für Sprachen oder Domänen mit wenig Trainingsdaten
• Anomalieerkennung mit selbstentwickelten Schwellenwert-Logiken

SaaS und Plattformen

Bei einem SaaS-Produkt muss der FuE-Anteil anhand der konkreten Arbeit getrennt werden. Multi-Tenancy, Echtzeit-Synchronisation oder Event-Systeme sind keine FuE-Kriterien an sich. Entscheidend ist, ob hierfür ein eigener, nicht durch den Stand der Technik vorgezeichneter Lösungsweg systematisch untersucht wird.

APIs und Integrationen

Standard-API-Anbindungen sind keine FuE. Aber wenn du eine eigene API-Abstraktionsschicht entwickelst, die heterogene Datenquellen in ein einheitliches Schema überführt, oder einen eigenen Protokoll-Adapter baust, der inkompatible Systeme verbindet, kann das durchaus als FuE qualifizieren.

Mobile Apps

Eine App mit Flutter oder React Native zusammenzuklicken ist keine FuE. Aber eigene Algorithmen für Offline-Sync, neuartige Interaktionskonzepte (Gestensteuerung, AR-Integration) oder ein selbstentwickeltes State-Management-System können förderfähig sein. Wenn du an Hardware-naher Entwicklung arbeitest, findest du auch auf den Seiten Elektronik und Automatisierung relevante Beispiele.

Fünf konkrete Szenarien

Die folgenden Beträge sind Modellrechnungen. Sie setzen vollständige Anerkennung, KMU-Status und bei Einbeziehung der Gemeinkostenpauschale einen Vorhabensbeginn nach dem 31.12.2025 voraus.

Szenario 1: SaaS-Entwickler mit eigenem Produkt

Du baust eine Projektmanagement-App mit Echtzeit-Kollaboration. Du entwickelst einen eigenen CRDT-Algorithmus für Offline-Sync und ein neues Permission-System auf Basis von Capability-Tokens.

FuE-Anteil: Hoch. Der CRDT-Algorithmus und das Permission-System sind neuartig und technisch unsicher. Geschätzte Förderung (1.800h, 35% KMU, ab 2026): ca. 75.600 EUR/Jahr. Wie sich die Förderhöhe mit deinen Stunden ergibt, zeigt der Beitrag Eigenleistung berechnen.

Szenario 2: Freelance-Entwickler mit Kundenprojekten

Du entwickelst für einen Kunden eine Analyseplattform. Die Herausforderung: Verarbeitung von 10 Mio. Datensätzen in unter 2 Sekunden. Du entwickelst eine eigene Indexing-Strategie und optimierst die Query-Engine.

FuE-Anteil: Mittel. Die Indexing-Strategie und Query-Optimierung sind FuE. Standard-Frontend und API-Anbindung nicht. Geschätzte Förderung (800h FuE, 35% KMU, ab 2026): ca. 33.600 EUR/Jahr.

Szenario 3: Agentur-GbR mit eigenen Tools

Zwei Entwickler in einer GbR bauen interne Tools: ein eigenes CMS mit visueller Drag-and-Drop-Editierung und ein automatisiertes Testframework für Cross-Browser-Kompatibilität.

FuE-Anteil: Hoch. Beide Tools sind Eigenentwicklungen mit technischen Risiken. Geschätzte Förderung (2 x 1.200h, 35% KMU, ab 2026): ca. 100.800 EUR/Jahr.

Szenario 4: KI-Entwickler mit Fine-Tuning-Pipeline

Du entwickelst eine Pipeline für domänenspezifisches Fine-Tuning von Sprachmodellen. Dazu gehören eigene Datenaufbereitung, Evaluierungsmetriken und ein Benchmarking-Framework, das die Modellqualität über verschiedene Domänen vergleicht.

FuE-Anteil: Sehr hoch. Modelltraining, Evaluierung und die Pipeline selbst sind technisch unsicher. Geschätzte Förderung (1.600h, 35% KMU, ab 2026): ca. 67.200 EUR/Jahr.

Szenario 5: IT-Berater mit eigenem Automatisierungstool

Du baust ein Automatisierungstool, das Geschäftsprozesse analysiert und Workflow-Vorschläge generiert. Die Herausforderung: natürliche Sprache in strukturierte Prozessmodelle umwandeln, mit Validierung gegen Geschäftsregeln.

FuE-Anteil: Hoch. Die NLP-Komponente und die Prozessmodellierung sind neuartige Kombinationen. Geschätzte Förderung (1.400h, 35% KMU, ab 2026): ca. 58.800 EUR/Jahr.

Was zählt NICHT als FuE?

Die Abgrenzung ist wichtig, weil die BSFZ genau hinschaut. Diese Tätigkeiten sind grundsätzlich nicht förderfähig:

• Konfiguration und Customizing: Salesforce-Flows einrichten, HubSpot-Workflows konfigurieren, Shopify-Themes anpassen. Auch wenn es komplex ist, es ist keine Eigenentwicklung.
• Standard-Webentwicklung: WordPress-Sites, Landing Pages mit Page Buildern, statische Websites mit Templates.
• Bug-Fixing und Wartung: Fehlerbehebung in bestehender Software, Security-Patches, Dependency-Updates.
• Migration und Portierung: Ein bestehendes System auf eine neue Plattform migrieren, ohne eigene Entwicklungsleistung.
• Testing und QA: Standard-Testautomatisierung mit bestehenden Frameworks (Selenium, Cypress). Ein eigenes Testframework mit neuartigem Ansatz wäre dagegen FuE.
• DevOps-Routine: CI/CD-Pipelines mit Standard-Tools, Container-Orchestrierung nach bekannten Patterns.

Die Grenze verläuft bei der Frage: Gibt es eine technische Unsicherheit, die du mit einem neuartigen Ansatz löst? Wenn ja, ist es FuE. Wenn du nur bekannte Lösungen anwendest, ist es Routine.

Open-Source-Entwicklung als FuE?

Open-Source-Projekte können förderfähig sein, wenn ihre Entwicklungsarbeit die FuE-Kriterien erfüllt. Ein öffentlich verfügbares Framework mit eigenem neuartigen technologischen Kern wird nach denselben Kriterien geprüft wie proprietäre Software.

Auch Beiträge zu bestehenden Open-Source-Projekten können qualifizieren, wenn du eigene, neuartige Erweiterungen entwickelst. Reine Bug-Fixes oder Dokumentationsarbeit zählen nicht.

Praktisch ist Open-Source sogar vorteilhaft für den BSFZ-Antrag: Die Neuartigkeit lässt sich anhand des öffentlichen Codes und der Commit-History nachvollziehbar belegen.

Git als Nachweis

Git-Commits sind ein ergänzender Nachweis für Entwicklungsverlauf und Inhalt. Die Commit-History dokumentiert:

• Wann du gearbeitet hast (Zeitstempel)
• Woran du gearbeitet hast (Commit-Messages, Branches)
• Wie sich die Lösung entwickelt hat (Diff-History)

In Kombination mit einer Stundendokumentation bilden Git-Commits eine solide Nachweisbasis für die Forschungszulage. Das gilt besonders für Freelancer mit rückwirkenden Anträgen, bei denen die Commit-History als Nachweis dient. Mehr zu den aktuellen Fördersätzen und der Reform 2026 findest du im separaten Beitrag.

Typische Fehler bei IT-Anträgen

1. Zu vage formulieren: „Wir haben eine App entwickelt“ reicht nicht. Beschreibe die konkrete technische Herausforderung.
2. Wirtschaftliche Risiken nennen: Die BSFZ prüft technische Risiken. „Der Markt ist unsicher“ zählt nicht.
3. FuE-Anteil abgrenzen: Nur der nachweisbare FuE-Anteil gehört in den Antrag.
4. Standard-Frameworks als Innovation verkaufen: React einsetzen ist keine FuE. Ein eigenes Rendering-System bauen schon.
5. Technische Tiefe fehlt: Beschreibe den eigenen Lösungsweg, die fachliche Schwierigkeit und die geprüften Alternativen.

Was die Rechtsprechung sagt

Das Urteil ist in der Berliner Rechtsprechungsdatenbank veröffentlicht. Das Gericht bestätigte, dass ein neues Produkt allein die technologische Neuartigkeit nicht belegt. Reine Kombination verfügbarer Funktionen und Technologien genügt nicht; der eigene FuE-Kern muss konkret dargelegt werden.

Konkret folgte das Gericht der BSFZ-Linie: Die Anpassung etablierter DCNN-Modelle auf eigene Trainingsdaten oder die Integration verfügbarer KI-APIs in eine neue Benutzerschnittstelle ist keine FuE. Förderfähig wäre etwa ein neuartiger Trainingsalgorithmus, eine eigene Modellarchitektur oder eine bisher nicht erprobte Inferenz-Strategie.

Diese Linie wurde durch den BSFZ-Prüfleitfaden Stand 10/2025 explizit kodifiziert. Kap. 2.4.1 listet die nicht-förderfähigen IKT-Tätigkeiten katalogisch auf (siehe FAQ unten).

Externe Quellen und Gesetze

Gesetze und EU-Recht:

• § 2 FZulG: Begünstigte FuE-Vorhaben
• § 3 FZulG: Förderfähige Aufwendungen
• AGVO Art. 2 Nr. 86: Experimentelle Entwicklung (Definition)

Behörden:

• BSFZ-Prüfleitfaden Stand 10/2025: insbesondere Kap. 2.4.1 IKT-Vorhaben (S. 15)
• BMF: Themenseite Forschungszulage

Gerichtsurteile:

• VG Berlin, Urteil vom 22.09.2025, Az. 8 K 153/23: Neuartigkeit bei Software/KI
• VG Berlin, Urteil vom 14.02.2025, Az. 8 K 7/23: Arbeitsplan-Pflicht + AGVO-Primat

Software-Antrag: meine Rolle

Du willst dich auf deine Projekte konzentrieren, nicht auf Anträge. Genau dafür bin ich da. Ich komme aus der IT und formuliere den BSFZ-Antrag mit Stand der Technik, Risiken, Arbeitsplan und Nachweisen.

Dein Aufwand hängt von Projektumfang, Nachweisen und Rückfragen ab. Du lieferst und prüfst die technischen Tatsachen; ich formuliere und begleite den BSFZ-Antrag. Die Konditionen richten sich nach Projekt und Rechtsform.

Mach den QuickCheck für eine erste Einschätzung oder schreib mir per WhatsApp.

Förderung berechnen