Kurzfassung: Eigene Algorithmen, neue Architekturen, KI-Modelle und Performance-Optimierungen sind förderfähige FuE. Standard-Websites, SaaS-Konfiguration und Bug-Fixing dagegen nicht. Ein SaaS-Entwickler mit 1.800 FuE-Stunden kann ab 2026 rund 75.600 EUR Forschungszulage pro Jahr erhalten. Git-Commits dienen als Nachweis.

Softwareentwicklung und Forschungszulage. Für viele Entwickler klingt das widersprüchlich. “Ich forsche doch nicht, ich programmiere.” Das stimmt nicht ganz. 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

Eigene ML-Modelle zu trainieren ist fast immer FuE: Du experimentierst mit Architekturen, Hyperparametern, Trainingsdaten. Das Ergebnis ist nicht vorhersehbar. Einen ausführlichen Deep Dive findest du im Beitrag Forschungszulage für KI-Entwicklung. Konkrete Beispiele:

• 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

Wenn du ein eigenes SaaS-Produkt baust, liegt der FuE-Anteil oft bei 60 bis 80% der Entwicklungszeit. Die technischen Herausforderungen sind typischerweise: Multi-Tenancy-Architekturen mit Isolierung, Echtzeit-Synchronisation zwischen Clients, eigene Abrechnungslogiken mit komplexen Tarifmodellen und skalierbare Event-Systeme.

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

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 heben, 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?

Ja, Open-Source-Projekte können förderfähig sein. Entscheidend ist nicht, ob der Code öffentlich verfügbar ist, sondern ob die Entwicklungsarbeit die FuE-Kriterien erfüllt. Wenn du ein Open-Source-Framework mit neuartiger Architektur entwickelst, ist das genauso förderfähig 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

Ein großer Vorteil für Softwareentwickler: Git-Commits sind ein hervorragender Nachweis für FuE-Arbeit. Die Commit-History dokumentiert automatisch:

• 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. Alles als FuE deklarieren: Sei ehrlich bei der Abgrenzung. Nur der FuE-Anteil zählt.
4. Standard-Frameworks als Innovation verkaufen: React einsetzen ist keine FuE. Ein eigenes Rendering-System bauen schon.
5. Zu wenig technische Tiefe: Beschreibe nicht nur was du gebaut hast, sondern warum es technisch anspruchsvoll war und welche Alternativen du verworfen hast.

Du codest, ich kümmere mich um den Rest

Du willst dich auf deine Projekte konzentrieren, nicht auf Anträge. Genau dafür bin ich da. Ich komme selbst aus der IT, verstehe deinen Tech-Stack und formuliere den BSFZ-Antrag so, dass die Gutachter die Tiefe deiner Arbeit erkennen. Wie das bei anderen Entwicklern funktioniert hat, zeigen die Erfolgsgeschichten.

Dein Aufwand: Ein 60-Minuten-Gespräch und ein paar Rückfragen. Mein Honorar: 0 EUR im Voraus, 15% der ausgezahlten Förderung. Wird nichts bewilligt, zahlst du nichts.

Mach den QuickCheck oder schreib mir direkt per WhatsApp. Ich melde mich am gleichen Tag.

Förderung berechnen