# JARVIS Finance System – Statusbericht & Roadmap v0.3

## Kanonischer Projektcheckpoint – 2026-08-01

- **Verbindliches Konzept:** [`../finance-manager-2.0/FinanceManager_Umsetzungs_und_Zielkonzept_v2.2_2026-08-01.docx`](../finance-manager-2.0/FinanceManager_Umsetzungs_und_Zielkonzept_v2.2_2026-08-01.docx)
- **Produktbaseline:** [`../finance-manager-2.0/sprint-0-baseline.md`](../finance-manager-2.0/sprint-0-baseline.md)
- **Produktive Basis für Sprint 18:** Sprint 17E, PR #32–#34, Merge-/Deployment-SHA `11e2d75106e4ce4f7555bd35e9e8d2c82090fa08`
- **Aktiver Produktions-SHA vor Sprint 18:** `11e2d75106e4ce4f7555bd35e9e8d2c82090fa08`
- **Schema:** 49; Sprint 18 benötigt keine Migration
- **Releasebaseline:** Backend und Frontend aktiv; P0 0 · P1 0 · P2 0
- **Deployment:** Worktree `/home/agent/.hermes/worktrees/FinanceManager-main-deploy`; systemd-Services `finance-manager-backend.service` und `finance-manager-frontend.service`; Runbook [`../operations/finance-manager-deployment-runbook.md`](../operations/finance-manager-deployment-runbook.md)
- **Aktueller Auftrag:** Sprint 18 – Vermögens-Cockpit und Performance v1; Branch `sprint18/wealth-cockpit-performance-v1`
- **Produktverständnis:** private Haushaltsorientierung für Marcel und Melanie; kein buchhalterischer Monatsabschluss, keine Monatsfreigabe und kein Perioden-Lock
- **Nächster Sprint:** Sprint 19; nicht im Rahmen von Sprint 18 beginnen

### Sprint 18 – Vermögens-Cockpit und Performance v1

- Die bestehende Portfolioseite bleibt der einzige Vermögenseinstieg. Ihre Standardansicht zeigt höchstens sechs Kennzahlen, einen ehrlichen Verlauf, die Vermögensverteilung, Konten/Quellen, den Vergleich mit der versionierten Portfolio-Policy und einen getrennten Link zur Haushaltsplanung. Research-, Trading- und Orderfunktionen erscheinen dort nicht.
- **Erfasstes Vermögen** ist die Summe der bekannten bestätigten Bankguthaben, PostFinance-Aktien/-ETFs, des True-Wealth-Gesamtwerts, der vorhandenen Kryptowährungswerte und weiterer kanonisch bestätigter Werte. Unvollständig erfasste Immobilien und Verbindlichkeiten sind ausgeschlossen; deshalb wird nicht vollständiges Nettovermögen behauptet.
- Für den gesamten Haushalt sind Transfers zwischen eigenen Konten neutral. Für das Anlageportfolio werden Bank → Anlagekonto als Einzahlung und Anlagekonto → Bank als Auszahlung behandelt; interne Anlagekontotransfers sowie Käufe/Verkäufe innerhalb des Depots sind keine externen Kapitalflüsse.
- Vermögensveränderung, Nettoeinzahlungen und Anlageergebnis bleiben getrennt. Das Anlageergebnis folgt **Endwert − Anfangswert − Nettoeinzahlungen**. Prozentuale Rendite kommt ausschließlich aus der bestehenden kanonischen TTWROR-Engine und bleibt ohne vollständige Anfangs-/Endbewertungen, klassifizierte Kapitalflüsse und kanonische FX-Stichtage „Noch nicht verlässlich berechenbar“. Es wird keine parallele IRR-/XIRR- oder Steuerengine gebaut.
- True Wealth bleibt genau ein bestätigter Gesamtwert ohne Einzelpositionen. Cash, PostFinance-Positionen und Kryptowährungen werden über die bestehenden Services zusammengesetzt; nicht bewertete oder nicht zugeordnete Bereiche bleiben sichtbar und werden nicht als null ausgegeben.
- Historische Haushaltswerte werden nur an Stichtagen verbunden, an denen für alle bekannten Konten exakte gespeicherte Bewertungen vorhanden sind. Es gibt kein Carry-forward, keine erfundenen Zwischenwerte und keine Provideraufrufe beim Rendern. Der vorhandene Produktionsstand besitzt noch keine vollständige gemeinsame Haushaltsreihe und keine ausreichende globale Performance-Coverage; aktuelle bekannte Werte bleiben trotzdem sichtbar.
- Freshness, Reconciliation und Performanceberechenbarkeit sind drei unabhängige Qualitätsdimensionen. Ein veralteter Kurs ist keine Kontendifferenz; eine Differenz beweist keine fehlende Performancehistorie. Technische Diagnoseinformationen bleiben unter **Daten & Diagnose**.
- Die vorhandene versionierte Portfolio-Policy ist die einzige Zielorientierung. Das bereits vorhandene optionale Feld `monthly_contribution` trägt eine Beitragsorientierung ohne neue Tabelle; ohne aktive bestätigte Policy wird nichts unterstellt oder produktiv geändert.
- Der Sprint bleibt vollständig read-only. Es gibt keine Policyänderung, kein Beitragsziel-Confirm, keinen Import, kein Marktupdate, keinen Kauf/Verkauf und kein Rebalancing. Release-, CI-, Merge- und Deploymentbelege werden dynamisch im PR-/Abschlussaudit geführt, da der Merge-SHA nicht selbstreferenziell im Kandidatencommit stehen kann.

### Offene Nutzerentscheide und Datenlücken

- Apple-, Netflix- und ähnliche Erkennungshinweise bleiben gebündelte Datenhinweise. Sie blockieren den geschätzten Jahresrest nicht.
- Die VISECA-Bankzahlung bleibt als Kreditkartenabrechnung neutral; Käufe werden nicht doppelt gezählt. Eine materielle, tatsächlich unbrauchbare Importbasis führt weiterhin zu „Noch nicht verlässlich berechenbar“.
- Kategorisierungen, Dubletten und Budgetversionen benötigen weiterhin Preview → Confirm → Audit. Die read-only XLS-Kontrollquelle wird nicht automatisch übernommen.

### Sprint 17E – verbindliche Haushaltslogik

- Das Budget ist eine jährlich festgelegte, bei Bedarf veränderbare Orientierung und kein starres Ausgabenlimit. Eine Anpassung erzeugt technisch weiterhin eine neue unveränderliche Budgetversion, wird aber als einfacher Ablauf „Wert ändern → neue Gesamtrechnung sehen → übernehmen“ dargestellt.
- Die deterministische Formel lautet: **Jahresprognose = Ist bis Datenstand + erwartete Werte für den verbleibenden Zeitraum**. Für variable Kategorien gilt vollständiges saisonales Vorjahresmuster vor aktiver Jahresorientierung; danach ist ein aktueller Durchschnitt erst ab mindestens drei Monaten zulässig. Ohne ausreichende Grundlage wird kein präziser Betrag behauptet.
- Der aktuelle Monat zeigt Ist-Einnahmen, Ist-Ausgaben, Monatsergebnis, erwartete Ausgaben bis Monatsende und den Vorjahresmonat. Ein Monat endet automatisch durch den Kalender; es gibt keinen Abschlussstatus und keine Nutzerfreigabe.
- Plan, Ist und Prognose bleiben fachlich und visuell getrennt. Transfers sind neutral, Kreditkartenabrechnungen werden nicht zusätzlich zu Käufen gezählt, Rückerstattungen folgen der kanonischen Semantik, und einmalige Ausgaben werden genau einmal berücksichtigt.
- Kategorien sind die zentrale Grundlage für Ausgabenanalyse und Optimierung. Die Übersicht zeigt Jahresorientierung, Ist, Prognose, Abweichung, Vorjahr und eine verständliche Bewertung; höchstens drei materielle Optimierungshinweise werden angezeigt.
- **Frei planbar = prognostizierte Jahreseinnahmen − prognostizierte Jahresausgaben − geplante Sonderausgaben.** Das Ergebnis ist eine Haushaltsorientierung und kein garantierter Kontostand. Eine Sonderausgabe bleibt bis zu einer expliziten Budgetübernahme reine Was-wäre-wenn-Rechnung.
- Fixkosten-/Abo-Erkennung darf Prognosen intern unterstützen, ist aber kein obligatorischer Pflegeprozess und keine Voraussetzung für Jahresplanung oder Jahresrest.
- Die direkt bereitgestellte Datei `Altes Budget Melanie und Marcel.xls`, Blatt `2026` / „Budget Familie Gasser 2025/26“, wurde ausschließlich read-only als Kontrollquelle geprüft. Verbindlich sind CHF 114’569.39 Jahresausgaben, CHF 148’775.40 Jahreseinnahmen, CHF 34’206.01 Jahresüberschuss und CHF 2’850.50 korrekter Monatsdurchschnitt. CHF 1’984.67 wird nicht als Jahresdurchschnitt übernommen; die Hypothek CHF 1’298.75 quartalsweise ergibt CHF 5’195.00 jährlich und CHF 432.92 normalisiert pro Monat.

### Sprint-17D-Releasecheckpoint vor PR #30

- **Review:** P0 0 · P1 0 · P2 0. Letzte Korrekturen: VISECA-Coverage aus kanonischem Card-Match statt hardcodierter Kontrollzahl; Schema-48-Einzelbeobachtungen werden bei Migration konservativ auf `undetermined`/`unconfirmed` ohne sichere nächste Fälligkeit gesetzt; bestätigte Periodizität bleibt bei Edit erhalten; Kategorie-Typen sowie immutable Versionen, Positionen und Audits sind fail-closed.
- **Migration/Restore:** Preflight-Kopie des produktiven Schema-48-Stands: 26’427’392 Bytes, SHA-256 `b7ac45b25ab573f0defd0341268360a3cbf5c1954ade4c8618927d5675212464`; Restore auf Schema 49 und frische DB auf Schema 49 jeweils `integrity_check=ok`; gemeinsame persistente Fachtabellenzahlen unverändert.
- **Fachwerte:** Autobahnvignette bleibt bei einer Einzelbeobachtung „Noch festlegen“, nicht monatlich und ohne nächste Monatsfälligkeit. Hypothek CHF 1’298.75 quartalsweise = CHF 5’195.00 jährlich = CHF 432.92 Rückstellung pro Monat. XLS-Kontrollrechnung: CHF 114’569.39 Ausgaben, CHF 148’775.40 Einnahmen, CHF 34’206.01 Überschuss und CHF 2’850.50 Monatsdurchschnitt; read-only, Confirm nicht verfügbar.
- **Lokale Gates:** Backend 26/26 relevant grün; Reviewregressionen 16/16 grün; Frontend 25/25 relevant sowie 15/15 UI-Abschlusskorrekturen grün; Git-Safety 19/19; Typecheck, Build, Compileall, Ruff auf geänderten Python-Surfaces, `git diff --check` und Safety-Scan grün.
- **Browser-UAT:** 1440/820/390 px mit 12 Seiten-/Breitenkombinationen; Overflow 0, effektive Touchzielverstöße 0, Console-Fehler 0, Semantikverstöße 0. Vignetten-Preview wurde geprüft, nichts bestätigt; Budgetversionen vor/nach UAT: 0/0, Audit- und Confirm-Zähler unverändert.
- **Dynamische Releasebelege:** PR-Link, finaler CI-Lauf, Abschluss-, Merge- und Deployment-SHA sowie das unmittelbar vor Deployment erzeugte Backup werden nach Ausführung im PR-/Release-Audit dokumentiert; sie können nicht selbstreferenziell in demselben Git-Commit stehen.

### Schema-49-FK-Hotfix

- **Ursache:** Die Phase-18-Kompatibilitätsroutine baute bereits korrigierte Child-Tabellen bei jedem Migrationsstart erneut auf. Im realen Schema-48-Zustand existiert `budget_transfer_pairs.confirmed_transfer_id → budget_transfers.transfer_id`; deshalb scheiterte der unnötige `DROP TABLE budget_transfers` bei `foreign_keys=ON`.
- **Reparatur:** Phase-18-Child-Rebuilds laufen nur noch, wenn deren Tabellendefinition tatsächlich auf den obsoleten Rename-Parent `budget_transactions__phase18` beziehungsweise `budget_transaction_candidates__phase18` verweist. Bereits korrigierte Tabellen und ihre Daten bleiben unverändert.
- **Fokussierte Gates:** synthetische Regression des exakten Parent-/Child-Zustands 2/2 grün; frische Datenbank und reale Backup-Kopie bis Schema 49 grün; `foreign_key_check` vor/nach leer; `integrity_check=ok`; Ruff, Compileall, Diff- und Git-Safety-Gates grün. PR-, CI-, Backup-, Merge- und Deploymentbelege werden dynamisch im Hotfix-PR-Audit geführt.

### Sprint-17D-Ziel und Stop-Gates

- Bestehende Budget-/Recurring-/Forecast-Architektur vertikal erweitern; keine zweite Engine, Seite oder Navigation.
- Editierbare Kandidaten und konservative Periodizität; Einzelbeobachtung niemals automatisch monatlich.
- Verständliche, pro Vertrag gebündelte Hinweise mit Datengrundlage, Wirkung und Handlung.
- Jahresbudgetassistent und vereinfachter Budgetstatus mit strikt getrenntem Plan, Ist und Forecast.
- Excel nur read-only profilieren und als Preview darstellen; keine produktive Übernahme.
- Release erst nach gezielten Tests, einem Final-HEAD-Review, genau einem finalen vollständigen GitHub-CI-Lauf sowie P0/P1/P2 = 0.

---

**Historischer Stand:** nach akzeptiertem Budget Import Production Sprint v1
**Dokumenttyp:** sanitiserter Statusbericht, Roadmap und kurzes User-Handbuch  
**Scope:** Dokumentation, keine neue Implementierung  
**Datenschutz:** keine echten Finanzwerte, keine API-Keys, keine Rohdateien, keine CSV/XLS/PDF-Inhalte

---

## Executive Summary

Das JARVIS Finance System ist inzwischen ein lokal betriebenes FinanceManager-MVP mit separater Runtime, FastAPI-Backend, Vue/PrimeVue-Dashboard, Streamlit-Fallback/Admin-Resten, SQLite-Datenhaltung, Git-Safety-Gates, Audit-Log und konsequentem **Preview → Confirm → Audit**-Muster.

Der zuletzt akzeptierte Budget Import Production Sprint v1 hat den Budget-Import-Review produktionsnah gemacht: Kandidaten können geprüft, kategorisiert, gesplittet, bestätigt, ignoriert, wieder geöffnet und über Merchant/Alias- sowie Rule-Manager-Mechanismen vorbereitet werden. Produktive Buchungen bleiben an explizite Bestätigung gebunden.

Wichtig: Das System ist funktional weit fortgeschritten, aber noch kein vollautomatisches Finanz-ERP und erst recht kein magischer Steuerberater mit Krawatte. Vor Analytics, Reports und weiteren Importquellen ist eine Konsolidierungsphase sinnvoll.

---

## Release v0.3.1 – Import v2 + Analytics v1

**Datum:** 2026-05-18
**Release-Ziel:** Konsolidierung von Budget Import Production v2 und Budget Analytics/Data Explorer v1 auf `main`.

### Enthaltene Branches

- `feat/budget-import-production-v2`
- `feat/budget-analytics-data-explorer-v1`

`feat/budget-import-production-v2` ist in `feat/budget-analytics-data-explorer-v1` enthalten; daher wurde der Analytics-Branch als finaler Release-Branch per No-FF-Merge nach `main` übernommen.

### Merge / Tag

- **Merge-Commit:** `f87463d926a13968aea08a1a4c1bdc6018450e51`
- **Release-Tag:** `v0.3.1`
- **Tag-Message:** `Finance MVP budget import and analytics release`

### Release-Inhalt

- Source-aware Budget CSV Import v2 für VISA, Migros, Raiffeisen und AKB als Dry Run → Review → Confirm → Audit Workflow.
- Quellentabs und Income-/Transfer-Klassifikation im Import Review.
- Analytics/Data Explorer v1 aus ausschließlich bestätigten Budget-Transaktionen.
- Kategorieanalyse, Händleranalyse, Monatsvergleich und Budgetabweichungen erweitert.
- CSV Export im Explorer nur runtime-only vorbereitet und in v1 bewusst deaktiviert.

### Verifikation / UAT

- Python Compile: OK.
- Backend pytest: OK.
- Frontend Vitest: OK.
- Frontend Build: OK.
- Source Secret Scan und Frontend Build Secret Scan: OK.
- Git-Safety: OK.
- Browser-/Tailscale-Sanity: OK.
- Read-only UAT: Daten-Explorer, Top-Händler, Kategorieanalyse, Monatsvergleich, Import-Review-Quellentabs, Bank-/Income-Tabs und JS-Fehlerprüfung bestanden.

Es wurden keine produktiven Bulk-Confirms, keine Massenbuchungen und keine neuen Importquellen durchgeführt. Runtime-DB, reale CSV/XLS/PDF-Dateien und Secrets bleiben außerhalb des Repositories.

### Nächste Empfehlung

Als nächster Sprint wird **Fixkosten/Subscriptions v1** empfohlen: zunächst Klassifikation/Regeln und Anzeige/Auswertung, weiterhin mit Preview → Confirm → Audit und ohne automatische Massenbuchungen.

---

## Roadmap-Merker: Steuerprognose Tool

Späteres, noch nicht implementiertes Tool zur groben Steuerprognose:

- steuerbares Einkommen grob schätzen,
- erwartete Steuerbelastung indikativ ableiten,
- Quellen und Abzüge strukturiert erfassen,
- Szenarien vergleichen,
- klarer Disclaimer: keine Steuerberatung, keine verbindliche Berechnung.

Dieser Merker ist bewusst nur Roadmap/Dokumentation. Es wurde in diesem Sprint keine Steuerlogik implementiert.

---

## 1. Aktueller technischer Stand

### Git / Branch / Commit

- **Aktueller Branch:** `feat/budget-phase-1-4`
- **Letzter Commit:** `7d9d1101e33ede99639a34597fba18ceb4095174`
- **Commit Message:** `feat: productionize budget import review`
- **Remote Branch:** `origin/feat/budget-phase-1-4`
- **Default/Main Stand:** `main` und `origin/main` stehen auf `d6c36ac1025fd3263a3d4380c4aca5d717524793`
- **Merge-Status:** `feat/budget-phase-1-4` ist **nicht** in `main`/`origin/main` gemergt.
- **Branch-Beobachtung:** Es existiert zusätzlich `fix/manual-entry-uat-flows` lokal/remote. Diese Historie ist älter als der aktuelle Budget-Branch.
- **PR-Situation:** `gh`/GitHub-PR-Status war lokal nicht authentifiziert abrufbar. Aus Git-Sicht ist der Budget-Branch remote vorhanden und gegenüber `main` voraus; ein Merge/PR muss separat über GitHub oder authentifizierten CLI-Zugriff geprüft werden.

### Laufende Dienste

- **Backend lokal:** `http://127.0.0.1:8000`
- **Backend Tailscale:** `http://100.85.29.67:8000`
- **Frontend lokal:** `http://127.0.0.1:5173`
- **Frontend Tailscale:** `http://100.85.29.67:5173`
- **Health-Status bei Dokumentation:** Backend und Frontend lieferten HTTP `200` lokal und via Tailscale.
- **Bind:** Backend und Frontend lauschen auf `0.0.0.0`, also für Tailscale erreichbar.

### Runtime-Pfade

Die Runtime liegt bewusst außerhalb des Git-Repositories:

- **Runtime Root:** `~/jarvis_runtime/finance-system`
- **DB:** `~/jarvis_runtime/finance-system/data/finance.sqlite3`
- **Reports:** `~/jarvis_runtime/finance-system/reports`
- **Backups:** `~/jarvis_runtime/finance-system/backups`
- **Secrets:** `~/jarvis_runtime/finance-system/secrets`
- **Logs:** `~/jarvis_runtime/finance-system/logs`
- **Import-/Quellartefakte:** unter Runtime, nicht im Repo

### Teststatus / Qualitätstore

Zuletzt vollständig verifiziert nach Budget Import Production Sprint v1:

- **Python Compile:** OK
- **Backend pytest:** OK, `417 passed`
- **Frontend Vitest:** OK, `55 passed`
- **Frontend Build:** OK
- **Git-Safety:** OK, `14 passed`
- **Secret Scans:** OK für geänderte Dateien und Build-Artefakte
- **Browser Sanity:** OK für die relevanten Budget-, Portfolio- und Runtime-Routen

Für diesen Bericht wurden nur Dokumentation und Status erfassende Read-only-Checks durchgeführt. Produktive Runtime-Tabellen wurden nicht verändert.

### Schema-Version und wichtigste Migrationen seit Budgetstart

- **Aktuelle Migration-Version im Sprint-17D-Kandidaten:** `49`
- **Aktueller Migration-Name:** `049_annual_budget_recurring_semantics_v1`
- Die produktive Datenbank bleibt bis zum freigegebenen Release auf Schema 48.

Wichtige Budget-/Finance-Migrationsblöcke im aktuellen Stand:

- Budget Phase 1 Tabellen: Basis für Budget-Konten, Kategorien, Tags, manuelle Transaktionen und Transfers.
- Budget Phase 1.1 Tabellen: Runtime-Kategorie-/Plan-Erweiterungen.
- Budget Phase 1.4 Tabellen: Review-only Import-Kandidaten für Budgetquellen.
- Budget Phase 1.5 Tabellen/Erweiterungen: source-aware Import Review, Migros/Kreditkarten-Kandidaten, Covered-by-Source-Logik.
- Budget Phase 1.8 Tabellen/Erweiterungen: zentraler Confirm-Flow, Confirmed Transaction Link, Status-/Review-Korrekturen.
- Budget Phase 1.9 Tabellen/Erweiterungen: Review Productivity, Batch/Split/Rule-MVP-Grundlagen.
- Budget Import Production v1 Tabellen: Merchant/Alias Engine, Duplicate MVP, produktionsnähere Review-/Rule-Strukturen.

---

## 2. Realisierte Kernmodule

## A. Core / Infrastruktur

### Status

**MVP bis produktiv nutzbar**, mit lokalen Runtime-Grenzen.

### Wichtigste Funktionen

- Separates Runtime-Konzept außerhalb des Repositories.
- SQLite als lokale Hauptdatenbank.
- Schema-Migrationen mit Versionierung.
- Backup-/Restore-Konzept mit Runtime-Backups außerhalb Git.
- Git-Safety-Scan gegen versehentlich eingecheckte Daten, DBs, Secrets oder Rohdateien.
- Secret Handling: Provider-/Git-/Google-/Finance-Secrets bleiben lokal/runtime-orientiert, nicht im Frontend und nicht im Git.
- Audit-Log für produktive Änderungen.
- Preview → Confirm → Audit Pattern als zentrale Sicherheitsgrenze.
- FastAPI als lokale API-Schicht.
- Vue 3 + PrimeVue/Aura Dashboard als aktueller User Mode.
- Streamlit bleibt als Admin/Fallback/Altbestand vorhanden.

### Offene Grenzen

- Runtime ist aktuell lokal; keine echte Multi-User-/Server-Deployment-Architektur.
- Backup/Restore sollte vor der nächsten produktiven UAT nochmals manuell getestet werden.
- Einige alte Streamlit-Bereiche sind historisch gewachsen und sollten später entweder bewusst als Admin/Fallback markiert oder entfernt werden.
- Noch keine vollständige End-to-End-Testabdeckung aller realen User-Flows mit Browser-Automation.

---

## B. Portfolio / Aktien / ETFs

### Status

**MVP nutzbar**, Provider-/Performance-/Steuerlogik teilweise vorbereitet.

### Wichtigste Funktionen

- Instrumentensuche und manuelles Hinzufügen über User Mode.
- OpenFIGI-first/FMP-second Konzept vorbereitet; weitere Provider wie Finnhub, Twelve Data, Massive/EODHD sind als Fallback-/spätere Provider konzeptionell berücksichtigt.
- Provider-Aufrufe sollen nur explizit per Klick/CLI/Schedule erfolgen, nicht beim normalen Dashboard-Rendern.
- Manuelles Hinzufügen von Aktien/ETFs über Preview → Confirm → Audit.
- Aktien-/ETF-Positionen im Dashboard sichtbar.
- MVP-Flows für Kauf/Verkauf bzw. positionsbezogene Aktionen vorhanden bzw. vorbereitet.
- Dividende/Ausschüttung MVP-seitig vorgesehen/teilweise nutzbar.
- FX-Status wird als Datenqualitätsaspekt behandelt; fehlende FX-Daten sind keine Nullwerte.
- Preisupdate-Konzept über explizite Aktualisierung statt Live-Render-Calls.
- Detail Drawer im Vue-Dashboard für kompakte Detailansicht.

### Offene Grenzen

- Vollständige Performanceanalyse ist noch offen.
- Tax-Lots/FIFO/LIFO sind offen.
- Vollständige Steuerlogik ist offen.
- Rebalancing ist offen.
- Watchlist ist offen.
- Provider-Keys und Auth-Diagnostik müssen vor breiterem Provider-Ausbau sauber geprüft werden.
- Broker-/DOCX-/CSV-Importe für Equity/ETF bleiben review- und sicherheitsgetrieben; keine Masseneinspielung ohne separate Freigabe.

### Roadmap-Merker: Portfolio-Simulator und Signal-Advisor

- TrueWealth-vs-JARVIS-Simulator: historische TrueWealth-Transaktionen, monatliche Einzahlungen, Kosten, Orderanzahl, Drift und Low-Turnover-Regeln gegeneinander simulieren.
- Simulator-Ziel: nicht jedes Mikro-Rebalancing kopieren, sondern zeigen, wie viele Orders/Jahr bei Cashflow-Rebalancing, Quartalsprüfung und Toleranzbändern tatsächlich nötig wären.
- Buy/Hold/Sell-Indikatoren je Anlage vorbereiten: Aktie, ETF, Crypto-Coin, Managed Portfolio/TrueWealth, später Hyperliquid-Portfolio.
- Empfehlungskarten sollen Signal, Confidence, Quellen, Kosten-/Steuerhinweise, Risiko, Zeithorizont und Status `research/paper/approval/live-blocked` trennen.
- Keine automatische Ausführung aus dem Portfolio-Dashboard; alle Trade-Ideen laufen über Preview → Confirm → Audit bzw. bei CryptoTrader nur nach separater Live-Autonomie-Freigabe und harten Risk-Gates.

---

## C. Crypto

### Status

**MVP nutzbar**, mit lokalem Preis-/Report-/Wallet-Fokus.

### Wichtigste Funktionen

- Wallet-Verwaltung.
- Holdings je Wallet und Asset.
- CoinGecko-ID als empfohlene Provider-Identität.
- Crypto-Preisupdate über expliziten Workflow, nicht über Dashboard-Render.
- CoinGecko-Link/Providerbezug für Assets vorbereitet bzw. sichtbar.
- Transfers zwischen Wallets mit Guards.
- Bestand erhöhen/reduzieren über auditable Workflows.
- Auf 0 setzen als explizite, geprüfte Aktion.
- Wallet-Aufteilung sichtbar, inkl. Detail-/Drilldown-Logik.
- Crypto-Report-Konzept mit lokalen Daten und runtime-only Export.

### Offene Grenzen

- Keine Livepreise/Websocket-Preise.
- Erweiterte Coin-Metadaten sind offen.
- Staking/Rewards sind offen.
- On-chain-Integration ist offen.
- Tax-Lots für Crypto sind offen.
- Coin-Symbol-Konflikte müssen weiterhin manuell/über Review sauber behandelt werden.

---

## D. Cash / Konten

### Status

**MVP nutzbar**.

### Wichtigste Funktionen

- Cash-Konten im lokalen Ledger-/Dashboard-Kontext.
- Einzahlungen, Auszahlungen und Korrekturen über Preview → Confirm → Audit.
- Kontoerstellung/Account-Verwaltung.
- Wallet-Verwaltung für Crypto getrennt von Cash-/Broker-Konten.
- FX als Datenqualitäts-/Ledger-Thema berücksichtigt.
- Integration in Gesamtportfolio und Command-Center-Ansichten.

### Offene Grenzen

- Vollständige Bank-CSV-Importe für AKB/Raiffeisen sind offen, bis die passenden CSVs vorliegen.
- Bankabgleich und automatische Matching-Logik sind bewusst nicht breit produktiv aktiviert.
- Mehrwährungs-Cash-Performance und detaillierte FX-Auswertung sind späterer Ausbau.

---

## E. Budget

### Status

**MVP bis produktionsnah nutzbar**, aktuell stärkster Ausbaupfad.

### Wichtigste Funktionen

- Budget-Konten.
- Budget-Kategorien und Kategoriehierarchie.
- Tags.
- Budgetpläne.
- Budgetstatus mit 2026-Fokus und confirmed actuals.
- Manuelle Einnahmen/Ausgaben.
- Transfers.
- Effektive Ausgaben aus bestätigten Buchungen.
- Effektive Einnahmen bzw. Income-Workflows auf Budgetplan-Basis.
- Import Review als zentrale Seite für Kandidatenprüfung.
- Merchant/Alias Engine für Händlererkennung.
- Rule Manager v1 für regelbasierte Vorschläge auf offenen Kandidaten.
- Split UI: Kandidat in mehrere Buchungszeilen aufteilen, mit Summen-/Differenzprüfung.
- Duplikatserkennung MVP mit Schutz vor `covered_by_source` und explizitem Trotzdem-Confirm nur mit Kategorie/Review/Audit.
- Migros Auto-Booking/Auto-Mapping-Konzept: Migros-Receipt-Logik und Kreditkarten-Migros-Coverage bleiben gegen Doppelzählung geschützt.
- Kreditkarten-Kandidaten im Review nutzbar.
- Budget vs Ist vorhanden.
- Kategorieanalyse vorhanden.
- Monatsvergleich vorhanden.

### Offene Grenzen

- AKB/Raiffeisen Import ist offen, bis echte CSV-Strukturen bereitstehen.
- Produktive Batch-Confirm UAT mit echten Kandidatengruppen ist noch nötig; keine Blindbuchungen.
- Fixkosten/Subscriptions sind noch nicht als eigenes Modul abgeschlossen.
- Daten-Explorer ist offen.
- Reports sind teilweise vorbereitet, aber nicht final ausgebaut.
- OCR/Kamera/Vision ist offen und explizit nicht Bestandteil des aktuellen MVP.
- Kategorie-Duplikate oder historisch gewachsene Kategoriefeinheiten sollten in einer Konsolidierungsphase geprüft werden.

---

## F. Dashboard / UX

### Status

**MVP nutzbar**, UI-System professioneller geworden, aber nicht final poliert.

### Wichtigste Funktionen

- Vue 3 + PrimeVue/Aura.
- Helles Theme / Light User Mode.
- Mobile-/Tablet-Optimierungen mit Bottom Navigation und Card Lists.
- Desktop-Sidebar bleibt erhalten.
- Budgetseiten: Review, Status, Transaktionen, Analyse, Setup/Regeln/Kategorien.
- Portfolio-/Crypto-Seiten.
- Detail Drawer für kompakte Details und Aktionen.
- Toast/Confirm in Budget Review produktionsnah verdrahtet.
- Tailscale-Erreichbarkeit für iPhone/iPad über lokale IP.

### Offene Grenzen

- Design-Feinschliff bleibt offen.
- Globale Toasts sind noch nicht garantiert in jedem alten Modul gleich einheitlich.
- Einheitliche Dialoge sollten weiter konsolidiert werden.
- Dark Mode ist später.
- Bundle Size / Lazy Loading sollte beobachtet werden; erste lazy Chunks existieren, aber systematische Bundle-Optimierung ist später sinnvoll.

---

## 3. Produktiv nutzbare Workflows

### Bereits nutzbar

- Crypto-Bestand ansehen.
- Crypto-Preise explizit aktualisieren.
- Crypto transferieren.
- Crypto-Bestand korrigieren.
- Crypto-Bestand auf 0 setzen.
- Aktien/ETF hinzufügen.
- Aktien/ETF verkaufen bzw. positionelle Aktionen ausführen, soweit MVP-Flow vorhanden.
- Dividende/Ausschüttung erfassen, soweit MVP-Flow vorhanden.
- Cash erfassen.
- Cash-Konto/Kontoobjekte verwalten.
- Budget-Kandidaten prüfen.
- Budget-Kandidaten einzeln bestätigen.
- Budget-Kandidaten ignorieren/wieder öffnen.
- Ausgabe splitten und bestätigen.
- Kategorie ändern bzw. Kategoriezuordnung setzen.
- Merchant/Alias pflegen.
- Regeln testen/anwenden, ohne produktive Buchung aus dem Regeltest.
- Budgetstatus ansehen.
- Effektive Ausgaben/Einnahmen ansehen.
- Budget vs Ist/Kategorieanalyse/Monatsvergleich ansehen.

### Teilweise nutzbar

- Reports.
- Portfolio Performance.
- Watchlist.
- Daten-Explorer.
- Fixkosten/Subscriptions.
- AKB/Raiffeisen Imports.
- Produktive Batch-Confirm UAT mit echten Kandidaten.

### Nur vorbereitet

- OCR/Kamera.
- Livepreise/Websocket.
- Analystenratings.
- Backtests.
- Rebalancing.
- Tax-Lots.
- Staking/Rewards.
- Full Steuerreport.

---

## 4. Offene technische Schulden

- `feat/budget-phase-1-4` ist noch nicht in `main` gemergt.
- PR-Status ist ohne authentifizierten GitHub-CLI-Zugriff nicht lokal bestätigt.
- Runtime-Daten liegen lokal; Backup-/Restore-Disziplin bleibt kritisch.
- Tests sind grün, aber UAT mit realen Nutzerklickpfaden ist teilweise noch nötig.
- Bundlegröße und Lazy Loading sollten später bewusst optimiert werden.
- UI-Komponenten sind noch nicht überall vollständig einheitlich.
- Alte Streamlit-Reste sind vorhanden und sollten als Admin/Fallback sauber eingeordnet werden.
- Fehlende echte End-to-End-Tests mit vollständigen Workflows.
- Mögliche Datenkonsolidierung in Kategorien/Merchant-Regeln.
- Mögliche Kategorie-Duplikate oder zu feine Kategorieäste.
- Budgetkandidaten sind nicht notwendigerweise alle produktiv bestätigt.
- Bank-CSV-Dateien AKB/Raiffeisen fehlen noch.
- Providerdiagnostik ist vorbereitet, sollte aber vor breitem Provider-Ausbau erneut getestet werden.

---

## 5. Risiken mit Ampel

### Grün – unter Kontrolle

- **Git/Secrets Risiko:** Grün, solange Git-Safety konsequent vor Commit/Push läuft und Runtime strikt außerhalb Git bleibt.
- **Blindbuchungen:** Grün, da Preview → Confirm → Audit als Write Boundary etabliert ist.
- **Covered-by-Migros/Duplikatschutz:** Grün bis Gelb; Schutzlogik ist vorhanden, UAT bleibt sinnvoll.
- **Dashboard-Erreichbarkeit:** Grün, lokal/Tailscale aktuell gesund.

### Gelb – beobachten

- **Datenqualität:** Gelb. Importkandidaten, Kategorien und FX-/Providerdaten brauchen laufende Prüfung.
- **Import-Duplikate:** Gelb. MVP-Erkennung vorhanden, aber reale Daten bleiben tückisch.
- **Falsche Kategorisierung:** Gelb. Merchant/Alias/Rules helfen, brauchen aber UAT und manuelle Pflege.
- **FX-Lücken:** Gelb. Fehlende FX-Daten müssen als Datenqualitätsproblem sichtbar bleiben.
- **Provider-Limits:** Gelb. Explizite Provider-Calls und Caching mindern Risiko, aber Keys/Limits müssen geprüft werden.
- **Lokale Runtime-Abhängigkeit:** Gelb. Lokal ist kontrollierbar, aber kein robustes Multi-Device-Deployment.
- **UI-Komplexität:** Gelb. Das Dashboard ist mächtiger geworden; weitere Vereinfachung lohnt sich.
- **Zu viele halbfertige Seiten:** Gelb. Roadmap-/Admin-/alte Bereiche müssen klar markiert oder reduziert werden.
- **Scope Creep:** Gelb bis Rot. Das System ist verlockend breit; Sprints müssen hart begrenzt bleiben.

### Rot – vor Ausbau fixen

- **Merge-/Release-Konsolidierung:** Rot vor dem nächsten großen Feature. Der akzeptierte Budget-Branch muss sauber gemergt oder als Release-Basis festgelegt werden.
- **Produktive UAT-Matrix:** Rot vor produktiver Massennutzung. Kritische Budget-/Cash-/Portfolio-Flows sollten einmal bewusst durchgeklickt werden.
- **Backup/Restore-Test vor produktiver Kandidatenbestätigung:** Rot, falls vor realem Batch/Import kein aktueller Restore-Test durchgeführt wurde.

---

## 6. Empfohlene Roadmap

### Phase 0: Konsolidierung

Priorität: sehr hoch.

- Offene Branches/PRs prüfen und `feat/budget-phase-1-4` kontrolliert mergen.
- UAT durchführen.
- Backup/Restore testen.
- Datenqualität prüfen.
- Dokumentation aktualisieren.
- Optional: Release-Tag setzen.

### Phase 1: Budget produktiv abschließen

Priorität: hoch.

- Kreditkarten-/Migros-Kandidaten UAT.
- Sichere Kandidaten nach Preview bestätigen.
- Merchant/Alias Regeln verfeinern.
- Fixkosten/Subscriptions vorbereiten.
- AKB/Raiffeisen CSV einlesen, sobald Dateien da sind.
- Keine neuen Importquellen ohne separate Freigabe.

### Phase 2: Reports

Priorität: mittel-hoch, nach UAT.

- Budget Monatsreport.
- Portfolio Monatsreport.
- Crypto Report verbessern.
- PDF/HTML Export.
- Dashboard-Snapshot.
- Reports nur aus bestätigten lokalen Daten, ohne echte Werte in Git/Chat.

### Phase 3: Analytics

Priorität: mittel.

- Daten-Explorer.
- Top Händler.
- Kategorie-Trends.
- Cashflow.
- Net Worth.
- Portfolio Contribution.
- Performancevergleich.

### Phase 4: Investment Decision Support

Priorität: später.

- Watchlist.
- Decision Journal.
- Rebalancing.
- Risk/Exposure.
- Scoring.
- Analysten/News später.

### Phase 5: Mobile/Automation

Priorität: später, nach stabilen Kernflows.

- Telegram-Erfassung.
- Mobile PWA.
- Kamera/OCR für Belege.
- Wiederkehrende Zahlungen.
- Alerts.

---

## 7. Nächste empfohlene 5 Sprints

### 1. Branch/Release Konsolidierung & UAT

- **Ziel:** Budget-Branch als stabile Release-Basis konsolidieren.
- **Warum jetzt:** Ohne sauberen Merge/Release wächst technische Unsicherheit.
- **Scope:** Branch-/PR-Prüfung, Merge nach `main`, Release-Tag, UAT-Checkliste, Smoke Tests, Backup/Restore-Test.
- **Nicht-Scope:** Neue Features, Analytics, Reports, neue Importe.
- **Akzeptanzkriterien:** Branch gemergt oder bewusst als Release-Branch markiert; Tests grün; Dashboard läuft; Backup/Restore geprüft; UAT-Liste erstellt.

### 2. Budget Review Production UAT

- **Ziel:** Reale Budget-Review-Flows sicher durchgehen.
- **Warum jetzt:** Das Budget-Modul ist produktionsnah, braucht aber echte Bedienabnahme.
- **Scope:** Einzelconfirm, Split, Ignore/Reopen, Merchant/Alias, Rule Apply, Duplicate Override, kleine sichere Kandidatengruppe mit Preview.
- **Nicht-Scope:** Massenimport, AKB/Raiffeisen, OCR, Analytics.
- **Akzeptanzkriterien:** Alle kritischen Review-Flows mit Audit nachgewiesen; keine Doppelbuchung; Fehlerfälle verständlich; Backup vorher/nachher vorhanden.

### 3. Reports v1

- **Ziel:** Monatsberichte aus bestätigten Daten erzeugen.
- **Warum jetzt:** Nach UAT liefern Reports echten Nutzen ohne weitere Importkomplexität.
- **Scope:** Budget Monatsreport, Portfolio Monatsreport, Crypto Report v1, HTML/Markdown/PDF soweit technisch verfügbar, runtime-only Export.
- **Nicht-Scope:** Prognosemodelle, Steuerreport, Analytics-Explorer.
- **Akzeptanzkriterien:** Reports aus lokaler DB; keine Rohdaten im Git; Exportpfad unter Runtime; Audit/Report-Metadaten; Testdatenabdeckung.

### 4. Fixkosten/Subscriptions v1

- **Ziel:** Wiederkehrende Ausgaben kontrolliert sichtbar machen.
- **Warum jetzt:** Subscriptions/Fixkosten helfen beim Budgetabschluss und bei Merchant-Regeln.
- **Scope:** Kandidaten-Cluster, manuelle Bestätigung, Plan-/Budget-Verknüpfung, Statusseite.
- **Nicht-Scope:** Automatische Abbuchung, Blindbooking, externe Provider.
- **Akzeptanzkriterien:** Wiederkehrende Kandidaten vorgeschlagen; User bestätigt; Budgetstatus profitiert; keine produktive Buchung ohne Confirm.

### 5. Daten-Explorer v1

- **Ziel:** Bestätigte Transaktionen flexibel filtern und analysieren.
- **Warum jetzt:** Nach stabilen Datenflüssen wird Exploration sinnvoll.
- **Scope:** Filter nach Zeitraum/Kategorie/Händler/Quelle, CSV-Export sanitized/runtime-only, einfache Aggregationen.
- **Nicht-Scope:** ML, Backtesting, Analysten, Steuerreport.
- **Akzeptanzkriterien:** Explorer zeigt nur bestätigte Daten; keine Kandidaten-Doppelzählung; User Mode ohne technische IDs; Export bleibt runtime-only.

### Eigene Empfehlung

Die vom Nutzer vermutete Reihenfolge ist sinnvoll. Ich würde sie nur schärfen:

1. **Branch/Release Konsolidierung & UAT**
2. **Budget Review Production UAT**
3. **Reports v1**
4. **Fixkosten/Subscriptions v1**
5. **Daten-Explorer v1**

Analytics, Investment Decision Support und Automation sollten erst danach kommen. Sonst bauen wir ein Cockpit mit Raketenknopf, während noch jemand prüft, ob die Räder fest sind.

---

## 8. User-Handbuch kurz

### Dashboard starten

Aus dem Repo/Runtime-Kontext:

```bash
cd ~/.hermes/repos/FinanceManager
source ~/jarvis_runtime/finance-system/venv/bin/activate
PYTHONPATH=src uvicorn jarvis_finance.api.main:app --host 0.0.0.0 --port 8000
```

Frontend separat:

```bash
cd ~/.hermes/repos/FinanceManager/frontend
VITE_API_BASE_URL=http://100.85.29.67:5173 npm run dev -- --host 0.0.0.0
```

Aufrufen:

- Lokal: `http://127.0.0.1:5173`
- Tailscale: `http://100.85.29.67:5173`

### Backend/Frontend stoppen

Ports prüfen:

```bash
ss -ltnp '( sport = :8000 or sport = :5173 )'
```

Prozess gezielt beenden:

```bash
kill <PID>
```

### Budget-Kandidaten prüfen

1. Dashboard öffnen.
2. Budget → Buchungen prüfen / Import Review öffnen.
3. Kandidat anklicken.
4. Kategorie, Händler, Regelhinweise, Duplikatstatus und Quelle prüfen.
5. Keine Bestätigung, wenn Kategorie oder Quelle unklar ist.

### Kandidaten bestätigen

1. Kandidat öffnen.
2. Kategorie setzen.
3. Confirm-Aktion wählen.
4. ConfirmDialog lesen.
5. Bestätigen.
6. Toast und Audit-Hinweis prüfen.

### Ausgabe splitten

1. Kandidat öffnen.
2. Split aktivieren.
3. Split-Zeilen mit Kategorie, Betrag, Notiz/Tag erfassen.
4. Differenz prüfen.
5. Confirm erst ausführen, wenn Summe exakt passt.
6. Toast/Audit prüfen.

### Kategorie ändern

1. Kandidat oder Transaktion öffnen.
2. Kategorieauswahl nutzen.
3. Speichern/Bestätigen.
4. Audit-/Toast-Hinweis prüfen.

### Merchant/Alias erstellen

1. Budget → Regeln öffnen.
2. Händler anlegen oder bestehenden Händler wählen.
3. Alias-Pattern erfassen.
4. Match-Typ wählen: contains/exact/regex.
5. Default-Kategorie setzen, falls sinnvoll.
6. Auf offene Kandidaten anwenden.
7. Ergebnis prüfen; keine produktive Buchung entsteht durch reine Regelanwendung.

### Crypto korrigieren

1. Crypto-Seite öffnen.
2. Coin/Wallet auswählen.
3. Korrektur-/Transfer-/Set-Zero-Aktion wählen.
4. Eingaben prüfen.
5. Confirm nutzen.
6. Audit-Hinweis prüfen.

### Aktie/ETF hinzufügen

1. Position hinzufügen öffnen.
2. Instrument suchen oder manuell erfassen.
3. Candidate bewusst auswählen.
4. Konto, Datum, Menge/Preis/FX-Status erfassen.
5. Preview prüfen.
6. Confirm ausführen.
7. Audit und Portfolioansicht prüfen.

### Cash erfassen

1. Cash/Kontenbereich öffnen.
2. Einzahlung, Auszahlung oder Korrektur wählen.
3. Konto und Pflichtfelder erfassen.
4. Preview prüfen.
5. Confirm ausführen.
6. Audit prüfen.

### Backup erstellen

Nur Runtime, nicht Git:

```bash
cd ~/.hermes/repos/FinanceManager
source ~/jarvis_runtime/finance-system/venv/bin/activate
python -m jarvis_finance.cli.main backup-runtime-db
```

Falls ein anderer Backup-Befehl projektspezifisch verwendet wird, zuerst Hilfe anzeigen:

```bash
python -m jarvis_finance.cli.main --help
```

### Git-Safety prüfen

```bash
cd ~/.hermes/repos/FinanceManager
rm -rf .pytest_cache frontend/.vite frontend/dist
find . -type d -name __pycache__ -prune -exec rm -rf {} +
python -m jarvis_finance.cli.main git-safety-scan .
git diff --check
git status --short
```

---

## 9. Speicherorte dieses Dokuments

- **Repo Markdown:** `docs/status/jarvis-finance-status-roadmap-v0.3.md`
- **Google Drive Ziel:** Ordner `Finanzen`, als Markdown und Google Doc, sofern Workspace-CLI authentifiziert verfügbar ist.

---

## 10. Verifikations-Checkliste für diesen Bericht

- Keine neue Implementierung.
- Keine Runtime-DB-Änderung.
- Keine echten Finanzwerte im Dokument.
- Keine API-Keys oder Secrets im Dokument.
- Keine CSV/XLS/PDF-Dateien ins Git.
- Markdown im Repo abgelegt.
- Google Drive Kopie abgelegt, falls Auth verfügbar.
- `git diff --check` ausgeführt.
- Git-Safety ausgeführt.
- Commit und Push durchgeführt.

---

## 11. Release-/UAT-Ergänzung v0.3.0

**Datum:** 2026-05-18
**Release-Branch:** `main`
**Quellbranch:** `feat/budget-phase-1-4`
**Merge-Commit:** `d16f4390e2d4c52cb66eb26c4fb1d529646e2e68`
**Release-Tag:** `v0.3.0`
**UAT-Matrix:** `docs/uat/uat-finance-mvp-v0.3.md`

### UAT-Ergebnis

- Branch-/Release-Konsolidierung durchgeführt.
- `feat/budget-phase-1-4` wurde konfliktfrei nach `main` gemergt.
- Runtime-DB-Backup wurde vor Merge/Release erstellt.
- Checksum wurde verifiziert.
- Restore-Test wurde gegen separaten Testpfad durchgeführt.
- Kleine UAT-Schreibflüsse wurden auf einer Test-Runtime-Kopie durchgeführt, nicht auf produktiver Runtime.
- Produktive Runtime wurde durch den UAT nicht verändert.
- Keine produktiven Massenbuchungen durchgeführt.
- Keine echten Werte, Rohdaten oder Secrets in Git/Chat dokumentiert.

### Bekannte offene Punkte

- Produktive Bestätigung echter Budget-Kandidaten bleibt manuell freizugeben.
- Produktiver Bulk Confirm bleibt hinter Preview und separater Freigabe.
- Reports v1 ist weiterhin ein eigener Sprint.
- Fixkosten/Subscriptions v1 ist weiterhin ein eigener Sprint.
- AKB/Raiffeisen-Import bleibt offen, bis CSV-Dateien bereitstehen.
- Bundle Size / Lazy Loading bleibt beobachtenswert.

### Nächster empfohlener Sprint

**Budget Review Production UAT** — kleine, bewusst freigegebene reale Budget-Review-Schritte mit aktuellem Backup, Preview, Confirm und Audit. Keine neuen Features.

---

## 12. Empfehlung für den nächsten Schritt

**Nächster Sprint:** Budget Review Production UAT.

Begründung: Der Budget-Branch ist nach der Release-Konsolidierung auf `main`. Der nächste sinnvolle Schritt ist keine neue Funktion, sondern eine kontrollierte produktive Bedienabnahme mit sehr kleinem Scope: einzelne reale Kandidaten prüfen, sicher bestätigen/ignorieren/reopen, Merchant/Alias-Regeln verfeinern und erst danach Reports oder Fixkosten ausbauen.