Kurzfassung: IT-Freelancer und Software-Entwickler haben besonders gute Karten bei der Forschungszulage – Git-Historie als Stundennachweis, klare Abgrenzung zu etablierten Frameworks, dokumentierbare technische Risiken. Förderfähig sind eigene Algorithmen, Architekturen und methodische Innovationen. Nicht förderfähig: Konfiguration von SaaS-Tools, Standard-Implementierung, reine Anwendung von Standard-LLMs ohne eigenständigen Algorithmus. Bei 1.200 FuE-Stunden pro Jahr ergeben sich ab 2026 rund 50.400 EUR Forschungszulage für neue Projekte.

Wenn du als IT-Freelancer oder Software-Entwickler eigene Lösungen entwickelst, ist die Forschungszulage mit hoher Wahrscheinlichkeit für dich relevant. Aber: Nicht jede Code-Zeile ist FuE im Sinne des FZulG. In diesem Beitrag schauen wir auf konkrete Praxisbeispiele – was die BSFZ als FuE anerkennt, was zu Ablehnung führt, und wie du deine Git-Historie als Stundennachweis nutzen kannst.

Drei Kriterien, die jede IT-Tätigkeit erfüllen muss

Die BSFZ prüft drei Kriterien (geregelt in § 2 FZulG und AGVO Art. 2 Nr. 84-86):

1. Neuartigkeit: Dein Ansatz geht über den Stand der Technik der Branche hinaus, nicht nur über deine eigene bisherige Praxis. Wenn du React lernst, ist das für dich neu, aber nicht für die Branche.

2. Technische Unwägbarkeit: Das technische Ergebnis ist zu Beginn der Entwicklung nicht vorhersehbar. Du experimentierst, iterierst, verwirfst Ansätze. Wenn das Ergebnis ab Sekunde 1 klar ist und du nur noch implementierst, ist es keine FuE.

3. Planmäßigkeit: Du gehst systematisch vor mit Arbeitspaketen, Meilensteinen und dokumentiertem Fortschritt. Patentanmeldungen ersetzen keinen Arbeitsplan (VG Berlin 8 K 7/23).

Förderfähig: 7 typische IT-Freelancer-Szenarien

Szenario 1: Eigenständige Datenbank-Architektur

Ein Solo-Entwickler baut eine eigene Time-Series-Datenbank-Architektur für IoT-Sensordaten mit speziellen Komprimierungsalgorithmen. Etablierte Lösungen (InfluxDB, TimescaleDB) bieten generische Komprimierung, aber nicht die spezifische Optimierung für extrem hochfrequente Sensordaten unter 1ms-Latenz.

Warum förderfähig: Klare Abgrenzung zum Stand der Technik (zwei konkrete Wettbewerbsprodukte genannt), eigenständige methodische Innovation (Komprimierungsalgorithmus), technisches Risiko (Latenz-Ziel von unter 1ms ist nicht garantiert erreichbar).

Szenario 2: CRDT-basierter Synchronisationsalgorithmus

Eine Freelance-Entwicklerin entwickelt einen eigenen CRDT-basierten Synchronisationsalgorithmus mit eigenständiger Konfliktauflösung für Offline-First-Anwendungen. Bestehende CRDT-Bibliotheken (Yjs, Automerge) bieten generische Lösungen, ihre Variante optimiert für domänenspezifische Datenstrukturen.

Warum förderfähig: Eigenständige algorithmische Innovation, dokumentiertes technisches Risiko (Konvergenz unter teilweise getrennten Netzwerken), Abgrenzung zu zwei konkreten Wettbewerbsprodukten.

Szenario 3: Domänenspezifischer Optimierungs-Algorithmus

Ein IT-Berater entwickelt einen eigenen kombinatorischen Optimierungsalgorithmus für Logistik-Routenplanung mit Echtzeit-Anpassung an Verkehrsdaten. Standard-Lösungen (OR-Tools, Gurobi-Wrappers) bieten generische Solver, seine Variante integriert eigenständige Heuristiken für die spezifische Logistik-Domäne.

Warum förderfähig: Eigenständige Heuristik (kein Standard-Solver), klare Abgrenzung, technisches Risiko (Echtzeit-Anpassung unter 100ms bei mehr als 1.000 Routenpunkten ist nicht garantiert).

Szenario 4: Eigenständige ML-Architektur

Ein KI-Entwickler baut eine eigenständige Architektur für Few-Shot-Learning in einem domänenspezifischen Anwendungsfall. Wichtig: Reine LoRA-Feinabstimmung von Standard-LLMs reicht nach VG Berlin 8 K 153/23 nicht. Die Innovation muss in der Architektur oder im Algorithmus liegen, nicht in der Anwendung.

Warum förderfähig (wenn richtig formuliert): Eigenständige Architektur (kein Standard-Transformer-Pattern), neuer Memorisierungs-Regularisierer, methodische Innovation gegenüber LoRA und RAG. Nicht förderfähig wäre: “Ich habe Claude und GPT-4 verwendet, um einen Chatbot für Tierärzte zu bauen.”

Szenario 5: Eigenständiges Verschlüsselungsverfahren

Ein Freelancer entwickelt ein eigenes End-to-End-Verschlüsselungsverfahren für Echtzeit-Audio-Streaming mit eigenständiger Schlüsselrotation und Forward-Secrecy. Standard-Bibliotheken (libsodium, NaCl) bieten generische Primitive, sein Verfahren integriert eigenständige Protokolle.

Warum förderfähig: Eigenständige Protokoll-Definition (kein Standard wie WebRTC oder Signal Protocol), technisches Risiko (Latenz unter 50ms bei 4K-Audio plus Forward-Secrecy ist nicht trivial), klare Abgrenzung.

Szenario 6: Eigenständige Datenstruktur

Ein Software-Entwickler baut eine eigene konkurrenzlose Datenstruktur für räumliche Indexierung extrem dichter Geo-Daten. Etablierte Strukturen (R-Tree, KD-Tree, QuadTree) bieten generische räumliche Indexierung, seine Variante optimiert für eine spezifische Geo-Domäne mit besonderen Performance-Eigenschaften.

Warum förderfähig: Eigenständige Datenstruktur-Innovation, klare Abgrenzung zu drei etablierten Strukturen, technisches Risiko (Insertion-Performance unter Echtzeit-Bedingungen).

Szenario 7: Eigenständige Compiler-/Transpiler-Optimierung

Ein Freelancer entwickelt einen eigenen Transpiler für eine Domain-Specific Language mit eigenständigen Optimierungspasses, die in etablierten Compilern (LLVM, Babel) nicht verfügbar sind.

Warum förderfähig: Eigenständige Optimierung (keine LLVM-Pass-Übernahme), klare Abgrenzung, technisches Risiko (Korrektheits-Beweis der Optimierung).

Nicht förderfähig: 7 typische Anti-Beispiele

Anti-Beispiel 1: Konfiguration von SaaS-Tools

“Ich habe Salesforce für meinen Kunden konfiguriert, eigene Workflows aufgebaut, Dashboards entwickelt.” Nicht förderfähig: Konfiguration etablierter SaaS-Tools – auch komplexe – ist keine FuE im Sinne des FZulG.

Anti-Beispiel 2: Standard-CRUD-Anwendung

“Ich habe eine Webanwendung mit React, Express und PostgreSQL gebaut.” Nicht förderfähig: Standard-Tech-Stack mit etablierten Patterns ist keine FuE, auch wenn die fachliche Domäne neu ist.

Anti-Beispiel 3: Reine LLM-Anwendung

“Ich habe einen Chatbot mit GPT-4 für Anwaltskanzleien gebaut.” Nicht förderfähig nach VG Berlin 8 K 153/23: Anwendung etablierter LLMs auf neue Branchen ist nicht FuE. Die Innovation muss im Algorithmus oder Modell liegen, nicht in der Anwendung.

Anti-Beispiel 4: Bug-Fixing und Wartung

“Ich habe das bestehende Backend stabilisiert, Performance optimiert, Bugs gefixt.” Nicht förderfähig: Routinewartung ist keine FuE.

Anti-Beispiel 5: Übersetzung etablierter Patterns

“Ich habe eine Mobile-App mit React Native gebaut, weil die Webversion bereits existierte.” Nicht förderfähig: Übertragung etablierter Lösungen auf neue Plattformen ist keine FuE.

Anti-Beispiel 6: Reine Frontend-Implementierung

“Ich habe eine schöne Landing Page mit Animationen und Tailwind CSS gebaut.” Nicht förderfähig: UI/UX-Implementierung mit etablierten Frameworks ist keine FuE – auch wenn das Design neuartig ist.

Anti-Beispiel 7: Standard-API-Integration

“Ich habe Stripe und SendGrid in die Anwendung integriert.” Nicht förderfähig: Integration etablierter APIs ist keine FuE.

Git-Historie als Stundennachweis

Eine der größten Stärken von IT-Freelancern bei der Forschungszulage: die Git-Historie. Aus jedem Commit ergibt sich:

• Datum: Exakter Zeitstempel des Commits
• Umfang: Dateien geändert, Zeilen hinzugefügt/gelöscht
• Thematische Zuordnung: Commit-Message als Tätigkeits-Beschreibung
• Iterations-Spuren: Verworfene Branches, refactored Code, Reverts

In Kombination mit weiteren Quellen ergibt sich ein dichter, plausibler Stundennachweis – auch rückwirkend:

Wichtig: Der Stundennachweis muss plausibel und konsistent sein. Wenn die Git-Commits 200 Zeilen pro Tag zeigen, kann der Stundennachweis nicht 50 Stunden Entwicklung an diesem Tag ausweisen. Maximal 8 Stunden pro Tag sind aus Glaubwürdigkeitsgründen empfohlen, maximal 40 Stunden FuE pro Woche sind gesetzlich nach § 3 Abs. 3 FZulG. Wie ein BSFZ-konformer Stundenzettel im Detail aussieht, beschreibt der Beitrag Stundenzettel für Eigenleistung.

Wie ich den Antrag formuliere

Der BSFZ-Antrag muss methodisch dicht sein. Konkrete Formulierungs-Patterns für IT-Tätigkeiten:

Schwach: “Wir entwickeln eine innovative Datenbank-Lösung.”

Stark: “Erstmals soll eine Time-Series-Datenbank-Architektur mit eigenständigem differentiellen Komprimierungsalgorithmus für IoT-Sensordaten unter 1ms-Insertion-Latenz entwickelt werden. Im Gegensatz zu etablierten Ansätzen (InfluxDB mit Snappy-Komprimierung, TimescaleDB mit ZStandard) integrieren wir eine domänenspezifische Komprimierung, die sensor-typische Wertfolgen mit eigenständigem Vorhersagemodell vorkomprimiert.”

Die starke Formulierung enthält:

• Konkretes technisches Ziel mit Zahl (unter 1ms)
• Zwei konkrete Wettbewerbsprodukte
• Eigenständige methodische Innovation (differentielle Komprimierung mit Vorhersagemodell)
• Klare Abgrenzung (was Wettbewerber nicht können)

Diese Dichte zieht sich durch den gesamten Antrag. Im Risiken-Feld:

Schwach: “Wir wissen nicht, ob es funktioniert.”

Stark: “R1: Bei der Entwicklung des Vorhersagemodells für Sensorwerte ist ungewiss, ob die Modellgröße bei akzeptabler Vorhersage-Genauigkeit (>95%) unter 100KB bleibt. MI: Wir testen drei verschiedene Modellarchitekturen (LSTM, lineare Approximation, Markov-Kette) parallel. Ob die Modellgröße unter 100KB bleibt und gleichzeitig die geforderte Vorhersagegenauigkeit erreicht, ist ungewiss. Bleibt die Modellgröße über 200KB, scheitert das Vorhaben technisch, da die Speicheranforderungen den Use-Case unbrauchbar machen.”

Konkrete Förderhöhe: Was bringt das?

Bei einem typischen IT-Freelancer mit 1.200 FuE-Stunden pro Jahr ergeben sich folgende Förderhöhen:

Bei einer kombinierten Antrag-Strategie (rückwirkend ab 2023 plus prospektiv ab 2026) sind über sechs Jahre rund 217.650 EUR Forschungszulage realistisch. Berechne deinen individuellen Wert im Förderrechner.

Sonderfall: Kundenprojekte vs. Eigenprojekte

Als IT-Freelancer arbeitest du oft an Kundenprojekten und parallel an eigenen Vorhaben (eigene SaaS-Plattform, Open-Source-Framework, Tool-Entwicklung). Beide Konstellationen können förderfähig sein:

Eigenprojekte: Eigene SaaS-Plattform, Open-Source-Framework, Tool-Entwicklung. Hier bist du sowohl Antragsteller als auch FuE-Leister – die Förderfähigkeit ist klar.

Kundenprojekte (Auftragsforschung): Hier wird es nach VG Berlin 8 K 144/24 komplizierter. Förderfähig sind nur Kern-FuE-Tätigkeiten, nicht Hilfsleistungen. Konkret:

• Förderfähig: Eigenständige Algorithmus-Entwicklung im Auftrag, eigenständige Architektur-Konzeption, methodische Innovation auf Basis deiner Expertise
• Nicht förderfähig: Standard-Implementierung nach Kundenwunsch ohne eigene Innovation, reine Anpassung etablierter Lösungen, Schulung, Dokumentation, Marketing-Material

Die saubere Trennung im Antragstext ist entscheidend.

Was übernehme ich für IT-Freelancer – und was nicht

Ich bin Fördermittelberater, kein Steuerberater. Den BSFZ-Antrag mache ich vollständig, den ELSTER-Antrag (AaF) bereite ich vor – einreichen darfst du oder dein Steuerberater.

BSFZ-Teil (vollständig durch mich):

• Strukturierung deiner Git-Historie und Projektmanagement-Daten zu einem BSFZ-konformen Antrag
• Formulierung der Neuartigkeit mit Abgrenzungsmatrix zu konkreten Wettbewerbern
• Risiken-Beschreibung mit Scheiterns-Klausel und technischen Zielwerten
• Arbeitspaket-Plan auf Basis deiner real geleisteten Entwicklung
• Stundennachweis-Vorbereitung aus Git-Commits, PRs und Kalender-Einträgen
• Einreichung im BSFZ-Portal und Beantwortung aller BSFZ-Rückfragen
• Widerspruch bei BSFZ-Ablehnung – im Honorar enthalten

ELSTER-Teil (Vorbereitung, kein Einreichen):

• Konkrete Eintragungswerte je Wirtschaftsjahr (Bemessungsgrundlage, Stundensatz, Fördersatz, Förderbetrag)
• BSFZ-Bescheinigung und Stundennachweise als PDF-Anlagen
• Übergabe-Dokument mit Erläuterungen für dich oder deinen Steuerberater

Mein Honorar: 0 EUR im Voraus, 15 Prozent Erfolgshonorar nur bei tatsächlicher Auszahlung. Details auf der Kosten-Seite.

Hinweis: Ich bin Fördermittelberater, kein Steuerberater oder Rechtsanwalt. Die Inhalte dieser Seite (FZulG-Verweise, BSFZ-Verfahren, technische Beispiele) dienen der Orientierung und ersetzen keine individuelle Steuer- oder Rechtsberatung. Für verbindliche Auskünfte zu deinem konkreten Einzelfall wende dich bitte an einen Steuerberater oder Rechtsanwalt.

Nächster Schritt

Wenn du eigene Software, Algorithmen oder Architekturen entwickelst, ist die Forschungszulage mit hoher Wahrscheinlichkeit relevant. Drei konkrete erste Schritte:

1. QuickCheck (2 Minuten) – schnelle FuE-Charakter-Prüfung
2. Förderrechner – individuelle Höhen-Schätzung auf Basis deiner Stunden
3. Kostenloses Erstgespräch (20 Min) – buchbar auf Cal.com

Den vollständigen Einstieg in alle Detail-Themen findest du im Forschungszulage-Leitfaden für Solo-Selbstständige. Speziell zur ML/KI-Entwicklung gibt es einen separaten Beitrag Forschungszulage für KI-Entwicklung, der die Spezifika und aktuelle Rechtsprechung im Detail beschreibt.

Schreib mir auf WhatsApp oder buche dein Erstgespräch direkt.