Angefangen hat es mit einer Tabellenkalkulation. Wie immer. 🙄
Die Frage war harmlos: Wie sieht mein Kontostand eigentlich in zwei Jahren aus, wenn Miete, Gehalt und Versicherungen so weiterlaufen? Und was passiert, wenn sich eine davon ändert?
In einer Tabelle beantwortet man das, indem man Zeilen kopiert. Für jeden Monat. Für jedes Jahr. Und beim nächsten Jahreswechsel darf man wieder ran. Irgendwann hatte ich keine Lust mehr und habe mir ein eigenes Werkzeug geschrieben.
Oben seht ihr die Jahresmatrix: Posten in den Zeilen, Monate in den Spalten, unten Saldo und kumulierter Stand.
(Alle Zahlen in den Bildern sind ausgedacht – meine echten bleiben schön hier. 😅)
Der Trick: nicht speichern, sondern rechnen
Der Kern des Ganzen ist eine einzige Entscheidung: Ein wiederkehrender Posten wird nicht als Stapel einzelner Buchungen gespeichert, sondern als Regel. Also nicht zwölf Zeilen „Miete", sondern einmal: Miete, 1.180 €, monatlich, ab 01.01.2026, unbefristet.
Die konkreten Termine rechnet das Tool bei jeder Abfrage neu aus. Klingt nach einem Detail, ändert aber alles: Die Folgejahre sind einfach da.
Zehn Jahre, die niemand eintippen musste - alles aus den hinterlegten Regeln gerechnet
2035 zeigt dieselben Posten wie 2026, bis dort etwas abweicht. Kein Kopieren, keine Duplikate, kein Jahreswechsel-Ritual.
Und wenn sich doch was ändert?
Genau da wird es interessant. Wenn ich einen Betrag ändere, fragt das Tool, wie weit das gelten soll: nur dieser eine Termin, dieser und alle folgenden, oder die ganze Serie. Bei „dieser und alle folgenden" wird die Serie geteilt – die alte endet am Vortag, eine neue beginnt.
Ein Klick auf eine einzelne Zelle bearbeitet genau diesen Termin - die Serie bleibt im Takt
Daraus ergaben sich zwei Dinge, die ich vorher nicht auf dem Schirm hatte:
Eine geteilte Serie soll trotzdem eine Zeile bleiben. Sonst erzeugt jede jährliche Gehaltserhöhung eine neue Zeile, und nach zehn Jahren sucht man sein Gehalt in zehn Zeilen zusammen. Jede Serie trägt deshalb eine gemeinsame Kennung, und die Matrix gruppiert danach.
Termine müssen immer vom Startdatum aus gerechnet werden, nie Schritt für Schritt. Eine monatliche Serie ab dem 31.01. liefert sonst 28.02., dann 28.03., dann 28.04. – der Februar frisst sich für immer durch. Richtig ist 28.02., 31.03., 30.04.
Noch ein Detail: der Startsaldo
Der Anker eines Kontos liegt auf einem frei wählbaren Monatsanfang, nicht auf dem Jahresanfang. So kann ich einfach den heutigen Kontostand von der Bank übernehmen, statt alle Buchungen bis Januar nachzupflegen. Vor diesem Datum wird bewusst nichts gerechnet – da steht ein „–" statt einer erfundenen Zahl.
Kontoauszüge lassen sich als PDF importieren, und gemerkte Zuordnungen erkennen beim nächsten Mal von selbst, wohin eine Buchung gehört.
Technik
FastAPI mit Jinja2-Templates auf SQLite, Frontend ohne Build-Schritt, läuft als Container auf dem Server. Mehr dazu auf der Projektseite.
Das Repo ist privat – da hängt zu viel Persönliches dran. 😉