Forschungszulage (FZulG) — Funding Strategy
Bezugsdokumente:
funding-application-plan.md(operativer Beantragungsplan),funding-work-packages.md(AP-Katalog),bsfz-ablehnungsrisiken.md(Risikobewertung).
Legal Basis & Process
- Forschungszulagengesetz (FZulG), novelliert durch Wachstumschancengesetz (28.03.2024)
- Zwei-Stufen-Prozess: BSFZ-Bescheinigung (technisch) → Finanzamt-Geltendmachung (fiskalisch)
- Referenz:
forschungszulagengesetz.md(Gesetzesgrundlage, Frascati-Kriterien, Bewertungsmatrix)
Financial Parameters
- Max. Bemessungsgrundlage: 10M€/Jahr (2024–2025), ab 2026 12M€
- KMU-Fördersatz: 35% (Solo-Founder qualifiziert)
- Förderfähige Kosten: Direkte F&E-Personalkosten, 70% Auftragsforschung, Abschreibung dedizierter F&E-Wirtschaftsgüter
- Solo-Founder-Pauschale (Einzelunternehmen, ab 2026): 100€/h, max. 40h/Woche
IMPORTANT
FZulG ist eine Steuergutschrift (§ 4 FZulG), kein Projektzuschuss mit Verwertungsbeschränkung. Kommerzieller Verkauf, Kunden-Onboarding und Umsatzgenerierung während der geförderten F&E-Periode sind erlaubt. Ein F&E-Vorhaben endet mit Beantwortung der Forschungsfrage, nicht mit Produktlaunch.
BSFZ-Eignung: Frascati-Klassifikation
Busflow qualifiziert primär als Experimentelle Entwicklung — systematische Anwendung vorhandenen Wissens zur Überwindung erheblicher technischer Barrieren.
Drei kumulative Kriterien
| Kriterium | Beleglage |
|---|---|
| Neuartigkeit | Übersteigt Branchenstand (etablierte Branchen-Monolithen bieten keine der AP-Lösungen) |
| Unwägbarkeit | 30+ ADRs dokumentieren ungelöste technische Risiken zum Projektstart. STRATEGIC_BLIND_SPOTS.md dokumentiert 21 identifizierte Risiken (SB-1–SB-21), deren systematische Triage und Resolution den Forschungsprozess belegt — die Git-Historie zeigt den Übergang von offenen Fragen zu architektonischen Lösungen |
| Planmäßigkeit | Phase-Gates (Phase 1/2/3), 24+ Protokoll-Spezifikationen, formelle Architektur-Reviews L1–L4 |
Abgrenzung (Exclusions)
Explizit nicht förderfähig:
- Routine-Bugfixing, allgemeines QA, Support
- UI/UX-Design ohne technische Neuartigkeit
- Busflow-eigenes Marketing, Sales-Funnels, Landing Pages (
apps/landing) — B2C-Produktfeatures für Operatoren (z.B. Booking-Widget-Optimierung, Operator-Landingpages) sind davon nicht betroffen - Standard-CRUD-Scaffolding und allgemeine DevOps-Pipelines (CI/CD, Deployments) — ggf. nicht förderfähig; Abgrenzung zu forschungsbedingt notwendiger Infrastruktur (Multi-Tenant-Isolation, Observability für Telemetry-Research, verteilte Systemarchitektur) durch Berater klären
- Pre-Project Feasibility Studies
Vorhaben-Clustering
Statt monolithischer Beantragung (schwer als kohärente Forschungsfrage zu verteidigen) oder Mikro-Anträgen (Verwaltungs-Overhead) gruppieren wir die APs entlang technologischer Abhängigkeitslinien in vier BSFZ-Vorhaben.
AP-Details siehe funding-work-packages.md.
Vorhaben 1 — Preisberechnung unter temporaler Datenunvollständigkeit (~600h)
| AP | Stunden |
|---|---|
| AP1 — Deferred-Pricing-Pipeline mit Post-Departure-Kostenzerlegung | 400h |
| AP6 — Kalkulations-Engine | 200h |
Forschungsfrage: Wie berechnet man finanziell bindende Ausgaben (Verkaufspreise, Steuerzerlegungen) für Touristik-Pakete, wenn die erforderlichen Eingabedaten erst nach Leistungserbringung verfügbar sind — und der erste Lösungsansatz nachweislich mathematisch falsch war?
Abhängigkeit: Tax Engine setzt Kalkulations-Engine voraus (CostingSheet → PriceMatrix Pipeline).
Vorhaben 2 — Datenkonsistenz über Vertrauensgrenzen (~935h)
| AP | Stunden |
|---|---|
| AP2 — Offline-First Sync + Immutability | 150h |
| AP3 — Mandantenübergreifende Compliance Engine | 200h |
| AP4 — Event-Driven Multi-Tenant Architecture | 150h |
| AP7a — Event-Driven Broadcast-Resilience | 65h |
| AP8 — Concurrent Seat Hold Engine | 150h |
| AP18 — CRDT-Based Collaborative Trip Planning (ADR-032) | 220h |
| Optional: AP14 — Dispatch Conflict Resolution | 80h |
| Optional: AP19 — Passenger-Side Offline Credential Validation (CBOR/CWT/COSE) | 120h |
| Optional: AP26 — Communication Decision Engine (ADR-033) | 115h |
Forschungsfrage: Wie gewährleistet ein verteiltes System Datenkonsistenz und Datenimmutabilität, wenn Offline-Feldgeräte, konkurrierende Verkaufskanäle und kaskadierte Domain-Event-Pipelines widersprüchliche Anforderungen erzeugen — und darüber hinaus mandantenübergreifende Compliance-Daten aggregiert werden müssen, ohne die architektonische Datenisolation aufzubrechen? Ergänzend: Wie integriert man Conflict-free Replicated Data Types für kollaborative Bearbeitung in dieselbe Architektur, wenn der CRDT-Zustand als opakes Binärformat vorliegt, die relationale Projektion FK-Constraints erzwingen muss, und der GoBD-Audit-Trail aus einem DAG gleichzeitiger Operationen abgeleitet werden muss?
Abhängigkeit: Offline Sync, Seat Hold und Dispatch Conflict Resolution teilen das gleiche verteilte Konsistenz-Problem. Broadcast-Resilience operiert auf gleicher Event-Driven-Infrastruktur. EU-561 konsumiert Felddaten aus dem Driver Hub. AP19 erweitert AP2's Offline-Sync-Infrastruktur durch Credential-Versionierung gegen das Fahrermanifest. AP18 nutzt einen fundamental anderen Konsistenzmechanismus (mathematischer CRDT-Merge statt Server-Wins), teilt aber V2's Kernthema: Datenkonsistenz über Vertrauensgrenzen hinweg.
NOTE
AP7-Auflösung: Das ursprüngliche AP7 (Crisis Communication Pipeline, 150h) wurde aufgeteilt: LLM-Krisennachrichten-Generierung (45h) → integriert in AP5 (Vorhaben 3). Event-Driven Broadcast-Resilience (65h) → AP7a (Vorhaben 2). 40h Standard-Infrastruktur (Rate Limiting, Circuit Breaker) bewusst nicht beantragt.
AP4 vereint: AP4 gehört vollständig zu Vorhaben 2 (nicht mehr auf V1/V2 gesplittet). 150h statt ursprünglich 200h — Multi-Tenant-Grundlagen (RLS, RBAC) sind Standard-Engineering; Event-Driven-Orchestrierung und Cross-Context-Sagas sind der Forschungsanteil.
AP14 optional: Dispatch Conflict Resolution als verwandtes Concurrency-Problem. Rücknehmbar, falls Vorhaben 2 zu breit wirkt.
AP19 optional: Passenger-Side Offline Credential Validation (CBOR/CWT/COSE) als passagierseitiges Gegenstück zu AP2. Die Forschungsfrage adressiert die Schnittstelle Digital/Analog: kryptographische CBOR-Credentials kompakt genug für Papier-QR-Codes (Analog-Fallback für ältere Zielgruppen), gekoppelt an Wallet-Push-Updates für Smartphone-Nutzer. State-Reconciliation zwischen immutablen Papiertickets und mutablen Wallet-Pässen als Kernunsicherheit. ADR + Spike ausstehend. Rücknehmbar, falls V2 zu breit wirkt.
Vorhaben 3 — LLM-Zuverlässigkeit für domänenkritische Prozesse (~875h)
| AP | Stunden |
|---|---|
| AP5 — Dokumentenverarbeitung + Krisennachrichten-Generierung (inkl. AP7b) | 345h |
AP5 — Knowledge-Graph-RAG [SCOPE-ERWEITERUNG] | 50h |
AP5 — Taxonomy-Aware Retrieval [SCOPE-ERWEITERUNG] | 60h |
AP5 — Buchungsmutationen [SCOPE-ERWEITERUNG] | 100h |
| AP9 — Agentic Company Governance ⚪ | 100h |
| AP27 — Domain-State PARA Derivation ⚪ | 100h |
| AP28 — Human-AI Co-Creation in CRDT-basierten Echtzeit-Umgebungen ⚪ | 120h |
Forschungsfrage: Wie orchestriert man nicht-deterministische Sprachmodelle für Geschäftsprozesse, bei denen fehlerhafte Ausgaben rechtliche oder finanzielle Konsequenzen haben — wenn die Fehlercharakteristiken je nach Anwendungskontext unterschiedlich sind (strukturelle Halluzinationen bei Datenbankeinträgen, inhaltliche Halluzinationen bei sicherheitskritischen Passagiernachrichten, kaskadierende Fehler in Agenten-Pipelines)? Ergänzend: Wie disambiguiert ein LLM-Retrieval-System autoritative Spezifikationen von archivierten Entwürfen, wenn eine dokumentationsweite Taxonomie (PARA) als maschinenlesbares Metadatensignal vorhanden ist, aber der Embedding-Raum keine kategoriale Autorität abbildet? Wie leitet ein KI-System aus domäneneigenen Entity-Lifecycle-Zuständen automatisch PARA-Kategorien ab, um Agenten-Routing und Kontext-Priorisierung auf Produkt-Datenebene zu steuern? Und wie löst man den Intentionskonflikt, wenn ein nicht-deterministischer KI-Agent als synchroner Akteur in einer CRDT-basierten Echtzeit-Kollaborationsumgebung mit menschlichen Disponenten zusammenarbeitet und Datenstrukturen mit Übermensch-Geschwindigkeit mutiert?
Abhängigkeit: AP5 orchestriert LLMs für drei domänenkritische Anwendungskontexte (Dokumente → ACID, Krisennachrichten → Passagiere, Buchungen → State Machine). AP9 ist die Meta-Ebene (Agenten betreiben das Unternehmen). AP27 setzt AP9 voraus und liefert die Produkt-Daten-Taxonomie, die Agenten für proaktives Task Surfacing benötigen. AP28 setzt ebenfalls auf AP9 und AP18 (CRDT) auf, löst aber die Konfliktauflösung synchroner Agenten-Interventionen in Echtzeit-Datenstrukturen.
Vorhaben 4 — Privacy-Aware Commerce Intelligence (~640h)
| AP | Stunden |
|---|---|
| AP20 — Privacy-First 360° Customer Profile | 250h |
| AP21 — AI-SEO / Generative Engine Optimization | 120h |
| AP22 — Consent-Aware Recommendation Engine | 150h |
| AP23 — Privacy-Preserving Conversion Analytics | 120h |
Forschungsfrage: Wie aggregiert und nutzt man Kundenverhaltensdaten für Empfehlungen, Profiling und Conversion-Analyse — wenn DSGVO-Datensparsamkeit, Multi-Tenant-Isolation und ein cookieloses Web die dafür nötigen Datenflüsse architektonisch unterbinden?
Abhängigkeit: Customer Intelligence Context konsumiert Events aller vier operativen Contexts (Commerce, Operations, Communications, Backoffice). AP21 setzt Booking-Widget (Commerce Context) voraus. AP23 setzt Widget-Embedding auf Operator-Websites voraus.
NOTE
Zielkonflikt als Forschungskern: Alle vier APs teilen denselben architektonischen Grundkonflikt: Datenmaximierung für geschäftskritische Funktionen (Empfehlungen, Analytics, SEO) vs. Datenminimierung durch DSGVO-Compliance. Die einzelnen Techniken (CDP, Recommendations, Analytics, SEO) sind bekannt — die Kombination unter Privacy-Constraints in einem Multi-Tenant-Bus-Touristik-Kontext hat keine Referenzimplementierung.
Folge-Vorhaben (nach Codebasis-Validierung)
Kandidaten AP10–AP13, AP15–AP17 verteilen sich nach Codebasis-Validierung entweder auf bestehende Vorhaben (z.B. AP15 in Vorhaben 2 als Erweiterung von AP3) oder bilden ein fünftes Vorhaben für Folgejahre. AP18 (CRDT Planning) ist seit ADR-032 dokumentiert und in V2 integriert; der Phase-1-Spike steht aus. AP19 (Passenger-Side Offline Credential Validation) nutzt CBOR/CWT/COSE und ist als optionaler V2-Kandidat eingestuft. AP25 (Adaptive Feedback Engine) adressiert die B2B2C-Dimension und eignet sich für Vorhaben 4. AP26 (Communication Decision Engine) adressiert Cross-Context-Konfliktauflösung und ist in Vorhaben 2 integriert. AP24 (Field-Device Media Pipeline) wurde bewusst zurückgestellt (🗃️ Backlog) — der Ansatz erfordert einen On-Device-ML-Feasibility-Spike vor Wiederaufnahme. Volumen-Maximum: ~4.460h.
Submission-Strategie
Risiko-Maximierung
| Strategie | Beantragt | Erwartet (risiko-adjustiert) | Aufwand |
|---|---|---|---|
| A: Alles eigenständig | 2.400–4.460h | ~70% | 310h |
| B: Risikoreichste APs (AP1, AP3) weglassen | 1.800–3.510h | ~88% | 260h |
| C (empfohlen): Alles + Berater für AP1+AP3 | 2.400–4.460h | ~85% | 310h + 4–7k€ Beratung |
NOTE
Historische Versionen dieser Tabelle nannten 2.400–4.110h. Das korrigierte Maximum ist ~4.460h (inkl. AP27, AP28, AP5 Taxonomy-Aware Retrieval, AP18 auf 220h). Herleitung: funding-work-packages.md §Stundenübersicht.
Gezielter Berater-Einsatz nur für rote APs (siehe bsfz-ablehnungsrisiken.md). Die Argumentationsmuster für rote APs sind übertragbar auf gelbe APs (AP6, AP7a, AP20–AP26 etc.).
Reihenfolge & Timing
Parallele Einreichung aller vier Vorhaben (separate Aktenzeichen, separate Gutachter). Verfassungs-Sequenz, Phasen-Timeline und konkrete nächste Schritte siehe funding-application-plan.md.
Erwarteter Ertrag
| Szenario | Stunden | Bemessungsgrundlage (100€/h) | Förderung (35% KMU) |
|---|---|---|---|
| Konservativ — V1–V3 Kern ohne AP9/AP27/AP28 | 1.660h | 166k€ | ~58k€ |
| V1–V3 + Scope-Erweiterungen AP5 (ohne AP9/AP27/AP28) | 1.970h | 197k€ | ~69k€ |
| V1–V3 + AP9 + AP27 + AP28 | 2.290h | 229k€ | ~80k€ |
| V1–V3 + AP18 (CRDT) | 2.510h | 251k€ | ~88k€ |
| V1–V4 inkl. Commerce Intelligence | 3.050h | 305k€ | ~107k€ |
| V1–V4 + starke Kandidaten AP10–AP14 | ~3.630h | 363k€ | ~127k€ |
| Maximum/Obergrenze — alle APs + Scope-Erweiterungen | ~4.460h | 446k€ | ~156k€ |
IMPORTANT
~4.460h ist die kanonische Maximum-Obergrenze (alle APs inkl. AP27, AP28 + AP5-Erweiterungen + AP18 auf 220h), nicht die empfohlene Jahr-1-Submission. Für Jahr 1 empfiehlt die konservative Strategie 1.660h–3.050h. Kandidaten aus dem oberen Bereich bilden die Folgejahres-Pipeline und dienen als Gesprächsgrundlage für den Steuerberater.
Documentation Assets für BSFZ-Submission
Die bestehende Projektdokumentation erfüllt BSFZ-Beweisanforderungen:
| Anforderung | Asset |
|---|---|
| Systematische Planung mit Meilensteinen | 30+ ADRs mit expliziten Phase-Gates |
| Technische Risikodokumentation und Forschungsprozess | STRATEGIC_BLIND_SPOTS.md — 21 Risiken identifiziert (SB-1–SB-21), systematisch triagiert und aufgelöst. Git-Historie belegt den Übergang von offenen Fragen zu Lösungen. |
| Recherche-Belege | eu-561-compliance-research.md |
| Design-Dokumentation | 24+ Protokoll-Spezifikationen unter docs/protocols/ |
| Independent Technical Review | Level 1–4 Architecture Review-Dokumente |