Entwurf · Issue c77346f

Die Karte schreibt mit

Entwurf zu Issue c77346f, zu docs/plans/c77346f-the-map-keeps-itself-current.md. Alle Zahlen stammen aus der Auswertung vom 04.09.2026 über raw.george und raw.paypal im Namespace money, Fenster 01.09.2025 – 31.08.2026, 1.141 Buchungen, 67.616 €.

Die Auswertung hat gefunden, was sie finden sollte: 7.209 € im Jahr für Essen außer Haus gegen 6.017 € Lebensmittel, ein Sparkonto, das 10.339 € zurückgegeben hat, nachdem es 9.180 € bekam, und einen Lieferdienst-Bestellwert, der in fünfzehn Monaten um 42 % gestiegen ist. Sie hat es mit einem sechzigzeiligen CASE WHEN in einem psql-Heredoc gefunden, einmal ausgeführt und weggeworfen. Dieses Kapitel entscheidet, was an dessen Stelle tritt — und was ausdrücklich nicht.

01Die API zieht, die CSV füllt einmal auf

Der erste Entwurf hatte das andersherum: CSV als Fundament, PSD2 als Bequemlichkeit für später. Die Daten widersprechen dem. Ein Bericht, der davon abhängt, dass jemand an einen Download denkt, hört nach dem zweiten Monat auf — und die Befunde, auf die es ankommt, sind genau die, die man erst über die Zeit sieht. Der steigende Bestellwert ist in keinem einzelnen Export sichtbar.

PSD2 deckt Erste und Revolut ab. PayPal ist kein Zahlungskonto im Sinn der Richtlinie und braucht einen eigenen Weg — den es hat: die Transaction Search REST-API, einmal unter developer.paypal.com registriert, ganz ohne Einwilligungsuhr.

Die Uhr ist kleiner als gedacht. Artikel 10a der RTS wurde durch die Delegierte Verordnung (EU) 2022/2360 geändert, anwendbar seit 25. Juli 2023: Erneuerung alle 180 Tage, nicht alle 90. Die Ausnahme deckt Saldo plus die letzten 90 Tage Umsätze — genau das Fenster, das ein täglicher Abruf braucht. Alles Ältere verlangt jedes Mal SCA, und das ist der zweite Grund für den einmaligen Backfill: er ist keine Bequemlichkeit, sondern der einzige Weg an die Historie.

Daraus folgt eine Pflicht, die leicht zu übersehen ist: die Anwendung muss das Ablaufdatum jeder Verbindung kennen und vorher etwas sagen. Eine Anbindung, die still stehenbleibt, ist schlechter als eine, die es nie gab — die Zahlen bleiben auf dem Schirm stehen und veralten unbemerkt.

02Regeln sind Zeilen, keine Codezeilen

Das CASE WHEN ist das eigentliche Ding, das ersetzt wird. Regeln als Zeilen heißen: derselbe Lauf gibt nächsten Monat dieselbe Antwort, eine falsche Zuordnung ist ohne Deploy korrigierbar, und — der wichtigste Teil — eine Buchung ohne passende Regel ist ein abfragbarer Zustand statt eines stillen Durchfallens nach „Sonstiges".

18 % der Ausgaben haben derzeit keinen benannten Empfänger: 8.893 € auf 240 Buchungen im Langschwanz und 3.417 € Bargeld. Kein Export senkt diese Zahl. Das Einzige, was sie senkt, ist ein Mensch, der einen Partner einmal einordnet — weshalb die Triage-Liste eine Arbeitsfläche ist und keine Debug-Ansicht.

Die Zuordnung passiert beim Lesen, nicht beim Import. Eine korrigierte Regel muss die Vergangenheit umfärben, ohne dass jemand neu importiert.

03Zwei Wege, die verworfen wurden

  • Kategorien vom Modell raten lassen. Verlockend für die 240 Buchungen im Langschwanz, und falsch. Der ganze Einwand gegen Firefly III war, dass es Annahmen traf, die nicht die des Besitzers sind. Eine geratene Kategorie, die zu 90 % stimmt, erzeugt eine Karte, der man nicht widersprechen kann — das ist der Fehlermodus, der behoben wird, keine Abkürzung darum herum. Dass ein Modell eine Regel vorschlägt, die der Mensch dann annimmt, bleibt offen und steht nicht in diesem Plan.
  • Doppelte Buchführung. Löst Umbuchungen zwischen eigenen Konten elegant und war der Grund, zuerst zu Firefly III zu greifen. Nur ist das Umbuchungsproblem hier klein und abgeschlossen: vier eigene IBANs plus zwei Namensmuster, in der Auswertung bereits gelöst. Dafür ein Buchhaltungsmodell zu bezahlen, in dem der Besitzer nicht denkt, ist genau der Tausch, der abgelehnt wurde.

04Was stehen bleibt

Der Namespace money auf mosaik hat schon Postgres mit raw.george und raw.paypal, nächtliche Dumps, VolSync und OIDC am Gateway auf die DID des Betreibers. Nichts davon wird neu gebaut. Der Wechsel weg von Firefly III ist eine Bildänderung in deployment.yaml, und er kommt zuletzt — erst wenn der Ersatz allein stehen kann. Firefly läuft bis dahin weiter und wird nicht migriert: seine Datenbank enthält nichts, was mitzunehmen wäre.

Eine Beobachtung, die die Reihenfolge festlegt: der Bank-Export führt keine Saldo-Spalte. Die Füllstände der Sicherheitspolster sind aus Buchungen allein nicht berechenbar. PSD2 liefert Saldo und Umsätze zusammen — das ist der Grund, warum die API die laufende Quelle ist und nicht bloß Komfort.

05Was dieses Kapitel offenlässt

  • Ob Erste tatsächlich die 180 Tage fährt oder freiwillig strenger ist. Steht in der Connector-Doku von Enable Banking und wird beim Einrichten geprüft, nicht hier geraten.
  • Flavias Sicht auf die gemeinsamen Konten. Eine echte Frage, aber nicht diese.
  • Die Höhe des Thommy-Puffers. Faktisch kostet er 295 €/Monat; ein Zielbetrag ist eine Entscheidung, keine Ableitung.