10 Jahre persönliche Finanzen in einfachen Textdateien verwaltet

 (sgoel.dev)
2 Punkte von GN⁺ 2026-01-03 | 1 Kommentare | Auf WhatsApp teilen
  • Mit Beancount wurden persönliche Finanzen 10 Jahre lang in einfachen Textdateien erfasst und dabei rund 45.000 Datenzeilen und 10.000 Transaktionen verwaltet
  • Jeden Monat werden 30–45 Minuten investiert, um CSV-Dateien mit Kontoauszügen zu importieren und manuell sowie automatisch zu bereinigen; zur besseren Lesbarkeit werden die Daten in Jahresdateien aufgeteilt
  • Eine eigene Python-basierte Importer-Bibliothek für deutsche Banken wurde entwickelt und mit Beancount integriert; ein Teil davon wird bis heute gepflegt
  • Weil der Einstieg in Beancount für Anfänger schwierig sein kann, wurde ein Einsteigerleitfaden geschrieben, der in der Community positiv aufgenommen wurde
  • Alle Daten werden auf dem lokalen Gerät und in einem Git-Repository gespeichert, was im Vergleich zu bestimmten Apps oder Services mehr Beständigkeit und Kontrolle bietet

Struktur des Beancount-Ledgers über 10 Jahre

  • Seit 2016 werden Finanzdaten mit Beancount verwaltet; insgesamt sind 45.011 Zeilen an Einträgen in 16 .beancount-Dateien gespeichert
    • Die Datei main.beancount bildet den Kern, Jahresdateien werden per include eingebunden
    • Insgesamt gibt es etwa 9.895 Transaktionen und darin 19.743 Postings (Buchungssätze)
  • Es existieren 1.086 Konten (accounts), die jedoch nicht nur reale Bankkonten sind, sondern vor allem virtuelle Klassifizierungskonten
    • Beispiel: Konten für Supermarktausgaben, Einnahmen, Abo-Dienste und andere Detailkategorien
  • 507 PDF-Dokumente sind an Transaktionen angehängt, sodass sich relevante Belege etwa für die Steuererklärung leicht prüfen lassen
  • Die Zahl der Postings pro Jahr stieg von 715 im Jahr 2016 auf 2.651 im Jahr 2023; 2023 war damit das aktivste Jahr

Monatlicher Verwaltungsablauf

  • Pro Monat werden etwa 30–45 Minuten aufgewendet, um Kontoauszüge als CSV herunterzuladen und in Beancount zu importieren
    • CSV wird verwendet, weil es sich leichter parsen lässt als PDF
    • Ein Python-basierter Importer wandelt die CSV-Daten in das Beancount-Format um
  • Nach dem Hinzufügen der konvertierten Transaktionen zur .beancount-Datei werden sie nach dem Prinzip der doppelten Buchführung so angepasst, dass der Saldo 0 ergibt
    • Ein Teil wird automatisch kategorisiert, ein Teil manuell angepasst
  • Mit Beginn eines neuen Jahres werden die Transaktionen des Vorjahres in die Datei <year>.beancount verschoben und über main.beancount eingebunden
  • Alle Transaktionsdaten sind als Textdateien in einem einzigen Verzeichnis organisiert

Entwicklung von Beancount-Importern für deutsche Banken

  • Beancount kennt standardmäßig die Formate von Bankauszügen nicht, daher ist eine Umwandlung über Importer-Klassen nötig
  • Da deutsche Bankkonten verwendet werden, wurden mehrere Importer direkt selbst entwickelt
  • Die ersten drei Bibliotheken werden weiterhin aktiv gepflegt und genutzt

Vom Nutzer zum Autor

  • Die Dokumentation von Beancount ist umfangreich, aber für Einsteiger ist die Einstiegshürde hoch
  • Auf Basis der durch Versuch und Irrtum gewonnenen Erfahrungen wurde ein Einsteigerleitfaden geschrieben
    • Veröffentlicht auf personalfinancespython.com
    • Erwähnt auf der Seite external contributions der offiziellen Beancount-Dokumentation
    • Leserrezensionen fielen positiv aus

Fazit

  • Alle Finanzdaten sind als lokale Textdateien mit Versionsverwaltung per Git gespeichert
  • Die Daten befinden sich auf dem eigenen Gerät und sind nicht an eine bestimmte App oder einen bestimmten Service gebunden
  • Mit den Werkzeugen des Beancount-Ökosystems lassen sie sich frei analysieren
  • Dieser Ansatz des Plaintext Accounting ist eine leistungsfähige Form der Finanzverwaltung, die länger bestehen kann als jede einzelne App

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-03
Hacker-News-Kommentare

  • Stimme dem Buch des OP voll und ganz zu. Es war die beste Einführung, die ich bisher gesehen habe, um Beancount / Plaintext Accounting zu verstehen.
    Ich selbst habe doppelte Buchführung mein ganzes Leben lang nicht richtig verstanden, und erst nach der Lektüre von Martin Kleppmans "Accounting for Computer Scientists" hat es bei mir Klick gemacht. Die Erklärung über Graphentheorie war überraschend intuitiv.

    • Die Zusammenfassung „Quicken ist ein einfaches Buchhaltungssystem, daher kann Geld plötzlich auftauchen oder verschwinden. In der doppelten Buchführung muss Geld, das auf ein Konto kommt, zwingend von einem anderen Konto abgehen“ bringt den Kern wirklich gut auf den Punkt. Der Satz stammt aus quicken2beancount.
    • Interessant, dass du doppelte Buchführung als schwierig empfunden hast. Eigentlich ist es nur das einfache Prinzip, dass jede Transaktion immer zwei Konten berührt und Soll und Haben in Summe gleich sein müssen. Ich kann mir nicht so recht vorstellen, wie Graphentheorie das noch einfacher macht.
    • Danke fürs Erwähnen, Michael!

  • Ich habe früher Quicken benutzt, aber weil ich bei jedem Versionswechsel die Daten neu eingeben musste, bin ich schließlich zu GNU Cash gewechselt. Dort gab es allerdings ebenfalls Migrationsprobleme.
    Dann habe ich Plaintext Accounting (PTA) entdeckt und mich für hledger entschieden (bei Beancount hatte ich Bedenken wegen möglicher Performance-Probleme). Nachdem ich doppelte Buchführung gelernt hatte, war sie deutlich einfacher als gedacht.
    Ich parse Investmentabrechnungen und Gehaltsabrechnungen, die als PDF kommen, mit Python-Skripten und habe die CSVs von Bank und Karte so automatisiert, dass sie automatisch kategorisiert werden.
    Ich investiere pro Monat ungefähr eine Stunde und erstelle damit Investmentberichte, Budgets und Steuerzusammenfassungen.
    Weil es Plain Text ist, bleiben die Daten auch bei Formatänderungen sicher, und man kann sie mit git versionieren.
    Der Nachteil ist, dass es auf Mobilgeräten nicht funktioniert und ein gewisses technisches Verständnis erfordert. Aber für Menschen, denen Geldflüsse wichtig sind, ist das die richtige Lösung.

    • Ich frage mich, was mit „neu eingeben musste“ gemeint ist. Ich nutze Quicken seit 1992 und musste bei Versionswechseln nie Daten neu eingeben.
    • Ich will auch von Quicken weg, aber die Intuit-Abhängigkeit ist enorm. Alle Transaktionen seit 2000 stecken in einem proprietären Format.
      Allerdings ist Quicken bei der automatischen Synchronisierung immer noch unschlagbar, daher ist Ersatz schwer. Ich prüfe täglich 27 Konten, um Betrug oder Fehler zu entdecken, und jedes Mal CSVs herunterzuladen und manuell zu verarbeiten wäre ein Albtraum.
      Außerdem schließen Banken inzwischen OFX und setzen Intuit als zwischengeschalteten Hub ein, wodurch der Ausstieg immer schwieriger wird.

  • Die Idee, persönliche Finanzen wie ein Projekt-Build-System zu verwalten, habe ich aus full-fledged-hledger gelernt.
    Die von Finanzinstituten erhaltenen Rohdaten werden unverändert gespeichert, dann per Skript in CSV umgewandelt und anschließend über Regeldateien auf PTA-Einträge gemappt.
    So werden automatisch alle historischen Daten aktualisiert, wenn man die Umwandlungslogik oder Klassifizierungsregeln ändert.
    Man kann mit den Daten eines Monats anfangen und das schrittweise ausbauen — zum Beispiel bis hin zu Amazon-Bestellhistorien oder PayPal-Belegen.

    • Da kam der Witz: „Warum hat PTA plötzlich etwas mit der Elternvertretung zu tun?“
    • Bei der Verbuchung von Hypotheken war ich verwirrt, und der Link liefert dazu eine gute Erklärung. Ich frage mich, ob du diese Codebasis tatsächlich verwendet hast oder nur das Prinzip übernommen hast. Ich kenne Haskell nicht und weiß daher nicht, wie viel angepasst werden muss.

  • Ich benutze seit einigen Jahren Beancount.
    Seit diesem Jahr habe ich wie der OP auf eine dateibasierte Jahresstruktur umgestellt. Früher hatte ich eine einzelne Datei mit 2 Millionen Zeilen, und das Emacs-Plugin wurde langsam.
    Der Vorteil dieses Ansatzes ist, dass man alles nachvollziehen kann — Investments, Rentenansprüche, RSUs, Bankkonten usw. Man kann sogar Stromverbrauch (kWh) modellieren.
    In letzter Zeit baue ich viele Automatisierungstools mit LLMs. Zum Beispiel habe ich mit Claude eine Regel-Engine für Transaktionen in eine App mit UI refaktoriert. Früher hätte das Tage gedauert.

    • Ich habe auch einmal meine Stromrechnung in kWh getrackt, aber ehrlich gesagt war das ziemlich nutzlos 😂
    • Ich würde auch gern persönliche Finanztools mit LLMs bauen, mache mir aber Sorgen wegen der Weitergabe sensibler Daten. Vermutlich wäre Verarbeitung mit anonymisierten lokalen Modellen besser.

  • Viele Leute scheinen Plain Text und doppelte Buchführung zu verwechseln.
    Beancount unterstützt beides, aber man kann Plaintext-Buchhaltung auch ohne Kenntnisse in doppelter Buchführung machen.
    Trotzdem ist doppelte Buchführung ein hervorragendes Werkzeug, um Wissen zu systematisieren, deshalb würde ich empfehlen, sie zu lernen.
    Beim Nutzen von Plain Text selbst bin ich etwas skeptisch. Es wirkt wie eine Gegenreaktion auf Cloud-Abhängigkeit oder Vendor Lock-in, aber doppelte Buchführung mit freier Software lokal auszuführen reicht eigentlich aus.
    Mein Fazit ist folgendes:

    • Buchhaltung: wichtig
    • Doppelte Buchführung: wichtig
    • Cloud-/Lock-in-Vermeidung: wichtig
    • Proprietäre Formate vermeiden: wichtig
    • Plain Text: nicht wichtig
      Ich benutze GnuCash, und auch wenn es nicht perfekt ist, passt es gut zu dieser Philosophie.
    • Ich denke, Automatisierung ist in der Buchhaltung unverzichtbar. Manuelle Arbeit produziert viele Fehler, und Genauigkeit ist die wichtigste Anforderung überhaupt (P0).
    • Ich liebe und hasse GnuCash zugleich. Die UI ist viel zu veraltet. Es wäre schön, wenn die Engine als Bibliothek getrennt wäre, damit man sie mit verschiedenen UIs nutzen könnte.

  • Ich habe kürzlich mit PTA angefangen, und die Einstiegshürde ist ziemlich hoch.
    Zuerst muss man doppelte Buchführung lernen und dann eines von ledger-cli / hledger / beancount auswählen. Die Unterschiede sind subtil, und am Ende geben Community oder Dokumentationsqualität den Ausschlag.
    Danach muss man entscheiden, von welchen Konten man starten will, wie weit die historischen Daten zurückreichen sollen und wie man automatische Importer einrichtet.
    hledger verwendet ein DSL, Beancount Python. Die meiste Zeit geht für manuelles Bearbeiten drauf.
    Danach tauchen neue Fragen auf, etwa zu Budgetierung, Steuern oder gemeinsamem Gebrauch mit dem Ehepartner.
    Aber genau darin liegt für mich der eigentliche Wert von PTA: dass man diese Fragen überhaupt selbst erkennt.
    Wenn jedes Jahr unzählige finanzielle Entscheidungen anstehen — Rente, Versicherungen, Internetkosten, neues Jobangebot usw. — ist es ein großer Vorteil, die eigene finanzielle Lage im Detail zu verstehen.

    • Ich bin Mathematiker, Programmierer und habe Finanzen studiert, daher habe ich doppelte Buchführung früh gelernt. Ich finde dieses abstrakte und elegante System wirklich schön.
      Ich nutze seit 10 Jahren ledger-cli mit Emacs und habe früher auch GnuCash verwendet.
      Als Einführung gibt es auch mein eigenes Lehrbuch zur doppelten Buchführung.
    • Doppelte Buchführung ist leicht, sobald man sich daran gewöhnt hat, aber am Anfang ist die Lernkurve steil.
      Ich nutze PTA seit 2018 und habe durch Versuch und Irrtum viel gelernt.
      Kommerzielle Dienste zeigen oft nur einzelne Konten, aber mit PTA kann man den gesamten Geldfluss der kompletten Finanzen vollständig nachvollziehen.
      Man kann zum Beispiel die vollständige Herkunft (Provenance) eines Vorgangs verfolgen, wenn Aktien vom Arbeitgeber verkauft werden und das Geld schließlich auf dem Bankkonto landet.
    • Ich halte doppelte Buchführung für persönliche Finanzen für völlig übertrieben.
      Für mich ist eine Excel-Tabelle das perfekte Werkzeug. Ich trage jede Woche nur die Zahlen ein, die ich brauche.
    • Ich stimme zu, dass Buchhaltung einfach aussieht, aber schwer zu lernen ist.
      Die Literatur ist widersprüchlich und schwer zugänglich, und selbst Buchhalter verstehen die Konzepte oft nicht richtig.

  • Ich verwalte meine Finanzen seit 20 Jahren auf einfache Weise mit Spreadsheets.
    Ich aktualisiere sie jeden Monat in etwa 5 Minuten und verfolge nur die Kernposten wie Strom, Heizung, Versicherungen und Ersparnisse.
    Das Ziel ist, Ausgabentrends zu erkennen und ein Jahresbudget zu sichern. Was übrig bleibt, wird einfach ausgegeben.

    • So ähnlich mache ich es auch. Ich notiere monatlich Kontostände, Einkommen, Steuern, Investmentüberweisungen, Wohnkosten und Versicherungen. Das reicht völlig aus, um die finanzielle Lage zu verstehen.
    • Ich habe es früher auch mit Plain Text gemacht, bin nach der Heirat aber wegen der gemeinsamen Verwaltung zu Spreadsheets gewechselt.
      Ich erfasse nur Ausgaben über $100 separat, um größere Ausgaben im Blick zu behalten.
    • Ich nutze für die Haushaltsfinanzen ebenfalls Spreadsheets, aber wenn ich fremdes Geld verwalte (z. B. Treuhandvermögen), verwende ich hledger. Da braucht man doppelte Buchführung und Abstimmung.
    • Wenn du Automatisierung willst, empfehle ich Tiller. Es verbindet sich mit Banken, importiert Transaktionen automatisch in Spreadsheets und bietet auch Budget-Templates.
    • Ich bin auch eher weniger obsessiv, aber proprietäre Dienste oder kostenpflichtige Apps mag ich nicht.
      Ich lade jeden Monat CSVs von Bank und Karte herunter und analysiere sie mit Python-Skripten.
      Mit von LLMs geschriebenem Code analysiere ich Ausgabentrends nach Händler, und auf einer Karte laufen ausschließlich wiederkehrende Zahlungen, damit ich Veränderungen leichter erkenne.

  • Ich empfehle Fava, ein GUI-Frontend für Beancount.
    https://beancount.github.io/fava/
    Es visualisiert alle Konten, und die Such-/Abfrageoberfläche sowie die Live-Bearbeitungsfunktion sind äußerst nützlich.

  • Das System sieht wirklich großartig aus, aber ich frage mich, wie man Finanzen zusammen mit einem nicht technischen Partner verwalten soll.
    Wir benutzen YNAB, weil die UI übersichtlich ist und Zusammenarbeit leicht macht. Lässt sich so eine Oberfläche auch für Beancount umsetzen?

    • Im direkt darunterstehenden Kommentar wird Fava empfohlen.
    • Wenn du ein iPhone nutzt, empfehle ich die App MoneyStats. Sie ist hübsch und leicht einzurichten, daher gut für gemeinsame Nutzung.

  • Ich war früher auch tief in PTA drin und habe angefangen, Logs zu führen, aber Transaktionen manuell von mehreren Banken herunterzuladen war viel zu mühsam.
    Alle sagen, Automatisierung sei die Lösung, aber ich frage mich, wie das konkret gemacht wird — mit APIs wie Plaid, mit Web-Scrapern oder PDF-Parsern?
    Am Ende zahle ich jetzt $130 pro Jahr für YNAB. Die Zufriedenheit meiner Partnerin ist hoch, und alles ist automatisch verbunden.
    Man könnte die Daten vielleicht über die YNAB-API sichern und parallel PTA nutzen.

    • Ich habe PDF-Auszug-Parser selbst gebaut. Einige direkt mit PyMuPDF, andere habe ich von Claude anhand von Musterabrechnungen generieren lassen.
      Die Finanzbranche hängt in diesem Bereich weit hinterher. Automatisierung nimmt zwar zu, aber bislang ist das Verhältnis von Aufwand zu Nutzen noch schlecht.
    • Ich habe mein Setup heute Morgen auch fertiggestellt. Ich prüfe alle zwei Wochen 18 Konten, und weil mir das sogar Spaß macht, ist es für mich keine große Belastung.
      Früher habe ich YNAB benutzt, aber dort gab es ständig Probleme mit doppelten Transaktionen, deshalb habe ich es am Ende aufgegeben.
      Ich habe dreimal alles zurückgesetzt, aber die Fehler blieben bestehen, also bin ich wieder zum manuellen Tracking zurückgekehrt.
      Jetzt ist PTA deutlich stabiler, und ich habe das Gefühl, alles selbst unter Kontrolle zu haben.