Beleg-Pipeline-as-a-Service — Brainstorm Requirements

Beleg-Pipeline-as-a-Service — Requirements

Arbeitstitel: „Beleg-Inbox”. Finaler Produktname offen.

Problem Frame

Marvin (Solo-GF mit ADHS, Agentic Ventures UG) erlebt Beleg-Erfassung als aversive Daueraufgabe. Belege landen in mehreren Quellen (Gmail hello@ + privat@, Restaurant-Papier-Quittungen, Karten-Abbuchungen ohne Beleg), Bewirtungs-Belege brauchen GoBD-konforme Beschreibung („Was war das? Mit wem?”), und gegen Quartalsende geht eine signifikante Menge Belege verloren oder bleibt schlecht beschrieben. Steuer-Risiko und Stundenverlust.

Marvin ist exemplarisch fuer den ICP — Solo-GF Tech/Beratung mit Lexware/sevDesk, 20-100 Belege/Monat, Buchhaltung als Nebenjob, gleichem Pain. Marvins These: „Viele die ich kenne wuerden dafuer schon Geld bezahlen — wenn es richtig sauber ist und nicht buggy.”

Wir bauen ein autonomes Beleg-System das im Hintergrund laeuft, ohne Aufmerksamkeit zu klauen, keinen Beleg verliert, und Bewirtungs-Beschreibungen aus Kalender-Kontext synthetisiert. Erst fuer Marvin als Pilot (4-8 Wochen Dogfooding), dann als Standard-Stack-Modul fuer Solo-GF-Kunden verpackt.

Refine-Hinweis (2026-05-20): Nach document-review wurde Welle-Split eingefuehrt, Idempotenz-Strategie konkretisiert (OCR-Text-Hash), Multi-Achsen-Trust statt einfacher Konfidenz-Schwelle eingezogen. Welle-4-Multi-Tenant in separater Spec-Datei welle-4-spec geparkt bis erster Kunde anklopft.

User Flow

EINGAENGE                                              OUTPUTS

Gmail hello@ + privat@        ─────┐
(Label "Belege")                   │
                                   │           ┌─► Lexware Voucher
WhatsApp-Foto (Welle 1.5) ─────────┤           │   (voucherItems[].description
(Restaurant, Hardware,             │           │    = mensch-lesbare GoBD)
 Belege unterwegs)                 ├─► Brain ──┤
                                   │           ├─► S3 GoBD-Archiv
manueller Vault-Drop               │           │   (av-finanzen-eu-central-1
inbox/belege/<file>                │           │    + S3-Side-Log mit Audit-
                                   │           │    Trail, beide Object-Lock 10y)
Qonto-Transaktion ohne Beleg ──────┘           │
(Welle 2 — braucht mcp-qonto)                  └─► Vault-Stub
                                                   extern/inbound/rechnungen/
                                                   <datum>-<sender>-<betrag>.md
                                                   mit Cross-Refs

                       BRAIN-DETAIL
                       ───────────
                       1. Idempotenz-Check (OCR-Text-Hash, DDB-Side-Check,
                          Burst-Detection bei WA-Fotos ≤60s)
                       2. Bedrock Haiku 4.5 EU — Klassifikation
                          + Kontext-Lookup (Kalender, Anbieter-Cache, EXIF
                          wenn relevant)
                       3. Multi-Achsen-Routing:
                          autonom NUR wenn Konfidenz ≥70%
                          UND Cache-Match ≥3 historische Belege
                          UND verified_by_human=true
                          erste 3 Belege pro Sender immer Pending
                          → autonom buchen ODER Pending mit Marker
                       4. Lexware Voucher (voucherItems[].description) +
                          S3-Side-Log + Vault-Stub (dual-source GoBD)
                       5. Sonntag-Push: gebuchte + Pending + Dedupe-Events

                       PUSH-MODUS
                       ──────────
                       1x/Woche Sonntag-Summary mit drei Sektionen:
                       (a) auto-gebucht (kollabierbar), (b) Pending, (c) Dedupe-
                       Events mit /keep-Korrektur. Real-Time-Ping nur bei
                       harten Stoppern (Backlog >7 Tage, Auth-Failure, S3-Down).

Requirements

Welle 1 — Standard-Abo-Pipeline (~12 Reqs, 2-3 Tage Bau, 2 Wochen Stabilisierung)

Eingangs-Kanaele

• R1. Gmail Label Belege wird alle 30 Min auf beiden Accounts (hello@ + privat@) gescannt. PDF-Anhaenge extrahiert.
• R3. Manueller Vault-Drop in inbox/belege/<file> als Fallback fuer Edge-Cases.

Klassifikator (Multi-Achsen-Trust)

• R5. Bedrock Haiku 4.5 EU liefert pro Beleg strukturierte Klassifikation via Tool-Use: is_business, category, is_deductible + Grund, voucher_description_gobd, confidence (0-1), pending_reason, verified_by_human_in_cache (boolean).
• R7. Anbieter-Cache (DynamoDB) mit Trust-Flags. Schema: PK=sender_domain, SK=classifier_version. Felder: classification, description_template, verified_by_human (initial false, true sobald Marvin via Korrektur bestaetigt ODER 3+ konsistente Bedrock-Klassifikationen). Cache-Drift-Detection: 5-10% der Cache-Hits parallel Bedrock-Call, bei Divergenz Alert.
• R5b. Multi-Achsen-Auto-Trust. Lambda darf NUR autonom buchen wenn ALLE drei Bedingungen: (i) Konfidenz ≥70%, (ii) Anbieter-Cache hat ≥3 historische Belege fuer den Sender, (iii) verified_by_human=true im Cache. Sonst Pending. Erste 3 Belege pro neuem Sender immer Pending — Bootstrap durch Marvin-Sichtung, nicht durch Bedrock-Self-Assessment.

Output + Dual-Source GoBD

• R10. Lexware Voucher autonom angelegt via mcp-lexware create_voucher. GoBD-konforme Beschreibung landet in voucherItems[].description (mensch-lesbar fuer StB) + PDF anhaengen. mcp-lexware-Patch noetig: aktueller MCP exposed kein description-Feld auf voucherItems, 1-Zeilen-Patch noetig bevor Welle 1 baut.
• R11. S3-Archiv (av-finanzen-eu-central-1) mit Object-Lock 10y ist GoBD-Aufbewahrung. Naming: <jahr>/<monat>/<sender-slug>-<datum>-<betrag>.pdf. PDF wird hier gespeichert BEVOR Lexware-Call (S3 ist Pflicht, Lexware ist Folge). Plus S3-Side-Log als JSON pro Voucher: {voucher_id, beleg_hash, classification_full, bedrock_prompt_response, decision_path, confidence, timestamp} — der Maschinen-Audit-Trail, ebenfalls Object-Lock 10y (GoBD-Aufbewahrungsfrist).
• R12. Vault-Stub unter extern/inbound/rechnungen/<datum>-<sender>-<betrag>.md mit Frontmatter-Cross-Refs: s3_uri, s3_side_log_uri, lexware_voucher_id, beleg_hash, classification_confidence, pending_marker (true/false).
• R13. Pending-Marker bei <70% Konfidenz ODER Multi-Achsen-Fail. Voucher wird trotzdem in Lexware angelegt mit Tag KI-PENDING-REVIEW. Sonntag-Summary listet alle Pending-Voucher.

Trust & Idempotenz (Hybrid + sichtbar)

• R14. Idempotenz via OCR-Text-Hash. Primary-Key: SHA256 von sender_canonical + voucher_datum + brutto_cent + (rechnungsnummer ODER last_4_iban). Cross-Channel-Dedupe — gleicher Beleg per Email + WhatsApp + manuell wird erkannt. Burst-Detection fuer WA-Fotos: zwei Foto-Uploads vom gleichen Sender innerhalb 60s → gleicher Beleg-Hash, zweites Foto als Anhang dazu. DynamoDB-Tabelle beleg-dedupe: hash → {voucher_id, s3_uri, first_seen, sources[]}.
• R15. DDB-Side-Check vor Voucher-Anlage (nicht Lexware-Description-Footer): pruefe beleg-dedupe-Tabelle. Falls Hash existiert: skip + Log dedupe-hit, plus Eintrag in Sonntag-Push-Dedupe-Sektion. Korrektur-Affordance: /keep VC-XYZ falls False-Positive-Dedupe — Lambda bucht den Beleg nachtraeglich als separaten Voucher mit unique-Hash-Suffix.
• R16. Audit-Trail in S3-Side-Log (Object-Lock 10y), nicht primaer in CloudWatch. Klassifikations-Entscheidung wird in S3-Side-Log persistiert (siehe R11). CloudWatch nur als Live-Debug mit 14d-Retention.
• R17 entfaellt (Backlog-Heartbeat war redundant zu R18 Sonntag-Push).

Push & UX (ADHS-Schonung)

• R18. Sonntag-Push 18:00 Berlin als WhatsApp + Email-Fallback mit drei Sektionen: (a) Auto-gebucht (kollabierbare Liste — du siehst was passiert ist), (b) Pending (zur Sichtung mit Deep-Links), (c) Dedupe-Events („3 Belege als Duplikat erkannt — pruefen mit /keep”). Format-Beispiel: „Diese Woche 14 Belege auto-gebucht (durchklicken), 3 Pending, 1 Dedupe-Hit. Pending: “.
• R19. Real-Time-Ping nur bei harten Stoppern. Definition: System-Down >2h, Backlog-Alert (>14 Tage Belege im Pending-Bucket), Lexware-API-Auth-Failure, Gmail-OAuth-Failure, WhatsApp-Webhook-Disconnect (Meta-Token-401), S3-Write-Failure. Sonst Schweigen.

Welle 1.5 — Bewirtungs-Auto-Beschreibung + WhatsApp-Input + Korrektur-Flow (3-4 Tage, nach 2-Wochen-Stabilisierung Welle 1)

Welle-1.5-Cutover-Kriterium: Welle 1 muss 2 Wochen ohne harten Stopper laufen, mit ≥90% Auto-Quote auf Standard-Abos.

• R2. WhatsApp-Foto-Input ueber mcp-whatsapp (Marvin schickt Foto an dedizierte AV-Nummer mit Sender-Whitelisting auf seine Privatnummer — alle anderen Senders weiter an Friseur-Brain). Bild-Pipeline: Foto → Lambda-tmp → EXIF-strip in-memory BEVOR S3-PUT → Bedrock Haiku 4.5 Multimodal (Vision-Capability — Sonnet-Switch nur falls Haiku-OCR-Qualitaet nicht reicht, in Welle-1.5-Pre-Planning empirisch geprueft).
• R6. Bewirtungs-Belege via Kalender-Lookup + WhatsApp-Direct-Frage. Lambda holt gsuite get_calendar_events fuer den Tag des Belegs, matched Restaurant-Name + Uhrzeit. Dual-Path-Logik basierend auf Evidence-Level:
  • kalender_exact_match (Restaurant-Name + Zeit + Teilnehmer im Eintrag) → autonome Beschreibung
  • kalender_zeit_only (Eintrag „Lunch” ohne Restaurant/Teilnehmer) → Pending mit WhatsApp-Frage „Mit wem warst du da?”
  • no_kalender → Pending mit Frage „Was war das?”
  • Bei WhatsApp-Foto-Upload zusaetzlich: 5-Sek-Sprach-/Text-Frage direkt am Punkt hoechster Erinnerung statt Sonntag-Sammlung
• R8. active-work-Lookup fuer Kunden-Zuordnung. Bei unklarer Klassifikation prueft Lambda intern/firma/active-work.md — welche Projekte/Kunden diese Woche aktiv? AWS-Beleg in Becker-Account-Region → Tag kunde:becker.
• R20. Korrektur-Flow (Syntax in /ce:plan finalisiert — Optionen: Coded-Command /p VC-123 vs. natuersprachlich vs. Magic-Link). Lambda korrigiert in Lexware + S3-Side-Log + Anbieter-Cache (sets verified_by_human=true). Empfehlung Plan-Phase: Magic-Link aus Sonntag-Push auf av-eigene HTTPS-Korrektur-UI als DSGVO-saubererer Pfad (keine Voucher-IDs ueber Meta-Infrastruktur).

Welle 2 — Qonto-Transaktion-Match (3-5 Tage, separate mcp-qonto-Bau)

• R4. Qonto-Transaktionen ohne zugeordneten Beleg werden erkannt und tagged. Trigger: Welle 1 stabil + Marvin braucht es (Karten-Abbuchung kommt, PDF fehlt noch). Vorbedingung: mcp-qonto-Eigenbau via SKILL.

Welle 4 — Multi-Tenant-Kunden-Modul

In separate Spec-Datei ausgelagert: welle-4-spec. Wird nach Welle-1+1.5-Pilot-Abnahme (8 Wochen) ausgearbeitet wenn erster Kunde anklopft. Maker-First-Prinzip: keine Premature-Generalisierung.

Pflicht-Vorarbeiten (vor Welle-1-Build)

• VP1. Lexware-API-Verifikation: Hat Voucher selbst ein remark-Feld oder nur voucherItems[].description? Plus ist description wirklich in Public-API-Voucher-Body? — 30-Min-Check in /ce:plan via Lexware-API-Doku + Test-Call.
• VP2. mcp-lexware-Patch: description-Feld auf voucherItems durchreichen + ggf. remark ergaenzen. 1-2 Stunden Bau.
• VP3. Bewirtungs-Eval-Set anlegen: 30-50 historische Bewirtungs-Belege (2024+2025) aus Gmail-Label Belege + manueller Ground-Truth-Beschreibung als Labelset fuer Welle-1.5-Eval. Vor Welle-1.5-Cutover validieren — falls <80%-Match → R6 verfeinern oder Sonderpfad fuer schwache Kalender-Eintraege.
• VP4. Bedrock Haiku 4.5 Vision-Benchmark: 5-10 echte WA-Beleg-Fotos gegen Haiku 4.5 Multimodal benchmarken. Falls OCR-Qualitaet reicht: Haiku-only pipeline (kostenoptimiert). Sonst: Sonnet-Switch bei <60% Konfidenz dokumentieren.
• VP5. Anbieter-Cache-Bootstrap: 5-10 historische Belege je Top-10-Anbieter (AWS, Hetzner, Anthropic, etc.) manuell klassifizieren, Cache mit verified_by_human=true vorfuellen. Sonst sind die ersten 3 Belege pro Sender immer Pending — bei AV-Pilot vermutlich akzeptabel, bei Welle-4-Kunden zu langsam.

Success Criteria

• Welle 1 (Standard-Pipeline, 2-3 Tage Bau + 2 Wochen Stabilisierung):
  • 95% der Standard-Abo-Belege (AWS, Hetzner, Anthropic etc.) landen automatisch in Lexware
  • 0 doppelte Voucher (Idempotenz haelt, gemessen am gleichen Beleg per 2+ Kanaele)
  • 0 verlorene Belege (S3 ist vollstaendig, jeder Beleg hat S3-Stub auch wenn Lexware-Voucher noch pending)
  • Dedupe-False-Positive-Rate ≤2% (gemessen ueber /keep-Korrekturen pro Dedupe-Event)
  • 0 harte Stopper > 24h (System-Down, Gmail-OAuth-Failure, etc.)
• Welle 1.5 (Bewirtung + WhatsApp, nach Welle-1-Stabilisierung):
  • Bewirtungs-Auto-Beschreibung trifft Ground-Truth in ≥80% (gemessen gegen Eval-Set aus VP3)
  • Korrektur-Flow nutzbar (Marvin korrigiert ≥1x/Woche ohne Frust)
• Welle 1 + 1.5 Final-Gate (8 Wochen):
  • Marvin laesst Pipeline 8 Wochen ungeschoben laufen ohne sie zu kuendigen oder zu disablen
  • Welle-4-Pilot-Kunde-Identifikation: 3-5 konkrete Kandidaten aus Marvins Netzwerk warmgeprueft

Scope Boundaries

• NICHT in Welle 1: Bewirtungs-Auto-Beschreibung (Welle 1.5), WhatsApp-Foto-Input (Welle 1.5), active-work-Lookup (Welle 1.5), Qonto-Transaktion-Match (Welle 2, braucht mcp-qonto), Pro-Rata-Splits (siehe unten Sonderpunkt), Hardware-Klassifikator-Spezialfaelle.
• NICHT in Welle 1.5: EXIF-GPS-Reverse-Geocoding (Micro-Feature ohne ROI, ggf. spaeter), Backlog-Heartbeat-Alert (redundant zu Sonntag-Push, R17 gestrichen).
• NICHT in Welle 4: Multi-User pro Tenant (jeder Kunde = Solo-GF = ein User), Kunden-eigene-Klassifikator-Anpassung (System-Prompts global), Sub-User-Approval-Workflows.
• NICHT Teil des Produkts: Steuerberatung. System klassifiziert nach Heuristiken + Marvins Defaults, ersetzt keinen StB. Verkauf erfolgt klar als „Beleg-Erfassung mit AI-Klassifikator-Vorschlag”, nicht als „AI-Steuerberater”.
• NICHT in Welle 5+: Industriekunden (Becker-Profil — siehe _index), Handwerk-Spezial (TSE-Kassen), Salon/Gastro (siehe receptionist).
• Pro-Rata-Sonderpunkt: Anbieter-Cache braucht Flag requires_manual_split: bool. Marvin markiert beim Bootstrap explizit Pro-Rata-Anbieter (Hetzner-Server-IDs, Telekom-Vertraege, Strom). Match auf Pro-Rata-Anbieter → IMMER Pending, nie autonom. Verhindert blind-spot wo out-of-scope-Belege als 100% business gebucht werden.

Key Decisions

• Maker-First statt Product-First. Marvin ist 4-8 Wochen alleiniger Pilot-Nutzer bevor wir generalisieren.
• Multi-Achsen-Trust statt Single-Konfidenz. Auto-Routing nur bei (Konfidenz ≥70%) UND (Cache-Match ≥3 Belege) UND (verified_by_human=true). Erste 3 Belege pro Sender immer Pending. Stichproben-Drift-Detection 5-10%.
• Welle-Split 3-stufig. Welle 1 = Standard-Pipeline (12 Reqs, 2-3 Tage Bau, 2 Wochen Stabilisierung). Welle 1.5 = Bewirtung + WhatsApp + Korrektur-Flow (3-4 Tage). Welle 4 = separate Spec welle-4-spec, wird nach 8-Wochen-Pilot ausgearbeitet.
• Dual-Source GoBD. Lexware voucherItems[].description = mensch-lesbare GoBD-Source fuer StB. S3-Side-Log + Vault-Stub = Maschinen-Audit-Trail (Klassifikations-Entscheidung, Bedrock-Prompt-Response). Beide Object-Lock 10y (GoBD-Frist). Bei Korrektur (R20) beide synchron updaten.
• Idempotenz: OCR-Text-Hash + Burst-Detection + sichtbare Dedupe-Events. Primary-Key OCR-Text-basiert (sender + datum + brutto + rechnungsnummer/IBAN). WA-Foto-Burst-Detection (≤60s = gleicher Beleg). DDB-Side-Check (nicht Lexware-Footer). Dedupe-Events sichtbar im Sonntag-Push mit /keep-Korrektur fuer False-Positives.
• ICP fuer Welle 4+: Solo-GF Tech/Beratung. Pricing-Range: 1500-2500 EUR Setup + 50-150 EUR/Monat. Andere Verticals: separate Module.

Dependencies / Assumptions

• Bedrock Haiku 4.5 EU verfuegbar in av-production eu-central-1. Vision-Capability fuer Welle 1.5 — Pre-Planning-Benchmark (VP4).
• mcp-lexware-Patch noetig vor Welle 1 (VP2). voucherItems[].description durchreichen.
• mcp-whatsapp live mit Sender-Whitelisting (Welle 1.5) — Marvin’s Privat-Nummer auf Beleg-Routing, andere weiter an Friseur-Brain.
• agents-platform Skeleton in av-production (Heartbeat live). Pipeline-Logik baut auf agents-platform.
• S3-Buckets av-finanzen-eu-central-1 mit Object-Lock 10y (Aufbewahrung GoBD).
• mcp-qonto existiert noch nicht — Welle-2-Bau noetig fuer R4 (3-5 Tage Eigenbau via SKILL).
• Welle-2-Trigger: mcp-qonto-Bau startet wenn Welle 1 stabil laeuft (8-Wochen-Pilot-Abnahme) UND Marvin oder erster Kunde Qonto-Match brauchen.
• DynamoDB-Tabellen (neu, ~1h Bau): beleg-dedupe (Idempotenz), anbieter-cache (Klassifikator-Cache mit verified_by_human-Flag + classifier_version-SK).
• Marvin akzeptiert Restrisiko dass bei <70% Konfidenz autonome Buchung passiert (Pending-Marker). Bei Steuer-Audit ggf. Pending-Marker-Voucher manuell verteidigen. Welle 4 sollte Pending-Voucher als Lexware-Drafts schreiben statt finale Voucher (sicherer fuer Kunden).
• Bewirtungs-Eval-Set (VP3) wird vor Welle-1.5-Cutover validiert. Bei <80%-Match auf Eval-Set: R6 verfeinern oder Welle 1.5 verschoben.

Outstanding Questions

Resolve Before Planning

(Keine — die drei kritischen Items aus dem Review wurden in Refine-Pass entschieden: Hash-Strategie ist OCR-Text-Hash, Kalender-Lookup hat Dual-Path-Logik mit WhatsApp-Direct-Frage, Korrektur-Syntax wird in /ce:plan mit Magic-Link-Empfehlung finalisiert.)

Deferred to Planning

• [Affects R5/R10] [Tool-Use] — Strukturiertes Output-Format via Bedrock Tool-Use mit JSON-Schema ist Pflicht (nicht freier JSON-Output). Verhindert Prompt-Injection ueber Beleg-PDF. Schema-Definition in /ce:plan.
• [Affects R10] [Technisch] — Lexware-API-Verifikation: ist remark auf Voucher-Body verfuegbar zusaetzlich zu voucherItems[].description? (VP1)
• [Affects R7] [Technisch] — Cache-Versionierung bei Klassifikator-Prompt-Bump. Replay-Tool fuer kuratiertes Re-Klassifizieren historischer Belege gegen neuen Prompt.
• [Affects R20] [User-Testing] — Korrektur-Flow-Syntax-Finalisierung: Coded-Command vs. Natuersprachlich vs. Magic-Link. Empfehlung Magic-Link (DSGVO + UX), aber Marvin-Test in Welle 1.5.
• [Affects R11] [Plan-Detail] — State-Machine pro Beleg: RECEIVED → S3_STORED → CLASSIFIED → LEXWARE_PENDING → LEXWARE_BOOKED (oder LEXWARE_FAILED → retry-queue). DDB-Item-Status, SQS-DLQ fuer Lexware-API-Failures mit Retry-Logik.
• [Affects R23 in welle-4-spec] [Strategisch] — Lambda-pro-Tenant skaliert bis ~50 Kunden. Aktuelles Welle-5-Ziel sind 3 Kunden — Skalierungs-Strategie erst pruefen wenn >10 zahlende Kunden.
• [Affects R6] [Pre-Planning] — Bedrock Haiku 4.5 Vision-Benchmark mit 5-10 echten WA-Beleg-Fotos. Falls OCR-Qualitaet zu schwach: Sonnet-Switch-Logik dokumentieren (Cost-Impact).
• [Plan-Phase Threat-Model] — Top-3-Exploit-Szenarien: (a) Beleg-Email-Spoofing mit Prompt-Injection-PDF, (b) Lambda-Compromise via Layer-Supply-Chain → Lexware-Token-Vollzugriff, (c) WhatsApp-Korrektur-Code-Spoof. Mitigations in Plan.

Sicherheits- + Compliance-Punkte (alle in /ce:plan adressieren)

• GoBD-Retention: S3-Side-Log Object-Lock 10y, CloudWatch nur Live-Debug 14d.
• PII in Bedrock-Prompts: Daten-Minimierungs-Schicht in Welle 4 (Hashes/Initials fuer Kunden-Teilnehmer-Namen). Welle 1 (Marvin nur) ohne Minimierung OK.
• WhatsApp-Korrektur-Codes ueber Meta: Welle-1.5-Default Magic-Link auf av-eigene Korrektur-UI statt Plain-Code-Reply.
• Lexware-API-Token: Read-Only-Token fuer Dedupe-Check, separater Write-Token fuer Voucher-Create. Falls Lexware nur Vollzugriff-Tokens: explizites Akzept-Statement im Plan + Lambda-Egress-Hardening (nur Lexware-API-Domain).
• EXIF-Strip: Order-of-Operations: WhatsApp → Lambda-tmp → EXIF lesen (in-memory) → PDF + EXIF-strip → Bedrock-Call → S3-PUT gestrippt. Niemals EXIF in Object-Lock-Bucket.
• Tenant-YAML (Welle 4): PII nicht im Code-Repo, sondern AWS Parameter Store mit anonymen Slugs. Details in welle-4-spec.
• Anbieter-Cache DDB: Pro Tenant eigene Tabelle (Welle 4), Customer-managed-KMS-Key.
• Tenant-Offboarding (Welle 4): S3-Archiv-Export an Kunden + KMS-Key-Lebenszyklus-Dokumentation.
• Bedrock-Prompt-Injection: Beleg-Content NUR als Tool-Input mit klarer Delimitation (‘<user_uploaded_receipt>…</user_uploaded_receipt>’), System-Prompt enthaelt explizit „untrusted user data”. Maximaler-Betrag-Cap fuer autonome Voucher (z.B. >500 EUR = immer Pending bis Trust etabliert).

Differenzierung gegen bestehende Loesungen

• Dext (UK/US), Hubdoc (intuit), Receipt Bank — ~30-100 USD/Monat. Schwaeche: US-First (nicht GoBD-native), keine Bewirtungs-Auto-Beschreibung, kein Kalender-Lookup, keine deutsche Buchhaltungs-Tool-Tiefen-Integration.
• Lexware/sevDesk Mobile-Apps — eigene Beleg-Scan-Funktion. Schwaeche: OCR ohne Klassifikator, keine Bewirtungs-Beschreibung, kein WhatsApp, keine Kalender-Anbindung.
• GetMyInvoices — Beleg-Abruf-Tool fuer DE-Markt. Schwaeche: zieht Belege von Anbieter-Portalen, kein AI-Klassifikator, keine Kontext-Synthese.

AV-Differenzierung: Bewirtungs-Auto-Beschreibung via Kalender + WhatsApp-Direct-Frage (unique), DSGVO-EU-First (Bedrock EU + S3 EU + Object-Lock GoBD), Lexware-Native, fuer Solo-GF mit ADHS-Pain explizit designed. Preispunkt 50-150 EUR/Monat positioniert unter Dext-Premium und ueber Lexware-Inklusiv-OCR.

Offene Strategie-Fragen (vor Welle 4)

Diese sind NICHT plan-blockierend fuer Welle 1+1.5, sondern muessen vor Welle-4-Sales geklaert sein:

• Marktgroesse ICP — 30-Min-Top-Down-Schaetzung Solo-GF DACH mit Lexware/sevDesk. Wenn <500 adressierbare Kandidaten: Cherry-Pick-Strategie (Bewirtungs-Modul als Standalone) statt Full-Stack-Pipeline.
• Distribution-Pfad — Marvins Netzwerk warm vs. Outbound vs. Add-On zu AV-Bestandskunden vs. StB-Multiplikator. Konkrete Akquise-Hypothesen vor Welle-4-Build.
• Spannung Produkt-Modul vs. Beratungs-Service — Setup 1500-2500 EUR fuer 2-3h = Premium-Beratung. Entweder Service-Modus (max 10 Kunden, kein Multi-Tenant-Refactor) ODER Produkt-Modus (Setup auf 300-500 EUR, Multi-Tenant nativ).
• Pilot-Kunden-Strategie Welle 4 — 3-5 konkrete Kandidaten warm pruefen + reduzierte Sales-Bedingungen (z.B. 50% Setup-Rabatt + 3 Monate kostenlos gegen Referenz-Recht) + Support-Budget-Cap (8h/Monat).
• Cherry-Pick: Bewirtungs-Modul als Standalone? — Wenn Bewirtungs-Auto-Beschreibung der eigentliche Hebel ist, koennte das ein separates Mini-Produkt sein (Email an describe@agentic-ventures.com → GoBD-Beschreibung als Antwort) das auch Dext-/Hubdoc-Nutzer kaufen.
• Opportunity-Cost vs Voit — Voit-Setup-Pauschalen liefern pro Kunde mehr MRR. Ist Beleg-Pipeline-Sales-Stunden-Budget begrenzt (max X h/Woche) damit Voit-Hauptlinie nicht leidet?
• Stop-Loss-Trigger Welle 4 — Wenn nach 90 Tagen Welle-4-Outreach <2 Kunden konvertieren: Modul bleibt AV-internal, Welle-5-Generalisierung canceln.

Next Steps

→ /ce:plan fuer strukturierte Implementierungs-Planung.

Plan sollte abdecken:

• VP1+VP2: Lexware-API-Verifikation + mcp-lexware-description-Patch
• Architektur-Detail (Lambda-Funktionen, DDB-Schemas, Bedrock-Prompts mit Tool-Use + JSON-Schema, State-Machine pro Beleg, SQS-DLQ-Retry)
• Welle-1-Build-Backlog (Reihenfolge, Test-Strategie, AV-Pilot-Cutover)
• VP3-Eval-Set + Bewirtungs-Validation-Methodik
• VP4 Bedrock Haiku Vision-Benchmark
• VP5 Anbieter-Cache-Bootstrap-Strategie
• Welle 1.5-Build-Backlog mit Welle-1-Stabilisierungs-Gate
• Welle-2-Spec (mcp-qonto-Bau)
• Threat-Model + Top-3-Exploit-Szenarien + Mitigations
• Bedrock-Cost-Schaetzung pro Beleg + pro Monat (50-100 Belege/Monat AV)
• Risk-Tracking: Idempotenz-Tests (Cross-Channel, Burst-Detection), Bewirtungs-Eval-Set-Performance, Pending-Quote-Monitoring, Dedupe-False-Positive-Rate
• Strategie-Fragen-Resolution vor Welle 4 (Markt, Distribution, Service-vs-Produkt, Cherry-Pick)