Jede Kapitalflussrechnung beruht auf einer stillen Entscheidung, die einmal pro Konto getroffen wird: Ist dieses Konto Teil des Bargelds, das Sie erklären, oder ist es eine operative, investive oder finanzierende Aktivität? Wenn diese Entscheidung richtig ist, zeigt die Rechnung, wohin Ihr Geld tatsächlich geflossen ist. Ist sie falsch, ist die Rechnung zuversichtlich irreführend.
Bisher traf der Cash-Flow-Bericht von Beancount.io diese Entscheidung für Sie mithilfe von Heuristiken – dem Wurzeltyp des Kontos plus einer namensbasierten Vermutung, welche Vermögenswerte als Bargeld gelten. Bei den meisten Ledgern war die Vermutung meistens richtig und der Rest der Zeit stillschweigend falsch. Ein Brokerage-Konto, das falsch benannt war, landete im falschen Abschnitt. Ein Geldmarktfonds, der in jeder praktischen Hinsicht Bargeld ist, saß unter „Investing Activities", weil sein Name es nicht verriet.
Ab heute können Sie die Klassifizierung explizit machen. Eine Zeile standardmäßiger Beancount-Metadaten in der open-Direktive des Kontos:
2000-01-01 open Assets:US:Brokerage
cash-flow-role: "investing"
2000-01-01 open Assets:US:Marcus:Savings
cash-flow-role: "cash"Ein Schlüssel, vier Werte – cash, operating, investing, financing – und das ist die gesamte Konfiguration. Es gibt keine Einstellungsseite, keine JSON-Datei, keine berichtsspezifischen Optionsdialoge. Beim nächsten Laden des Cash-Flow-Berichts erscheinen die Bewegungen des Brokerage-Kontos unter „Investing Activities", das Sparkonto schließt sich dem Bargeldbestand an, dessen Veränderung die Rechnung erklärt, und alle anderen Konten funktionieren weiterhin genau wie zuvor.

Was jede Rolle bedeutet
Eine Kapitalflussrechnung sortiert jedes Konto in eine von zwei Aufgaben, und cash-flow-role beantwortet beide mit einem einzigen Wort:
"cash"– das Konto gehört zum Bargeld- und Zahlungsmittelbestand. Bargeldkonten erscheinen nie als Einzelposten; die Rechnung erklärt die Veränderung ihres kombinierten Saldos, und Transfers zwischen zwei Bargeldkonten heben sich auf, so wie Geld vom Girokonto zum Sparkonto es sollte."operating"/"investing"/"financing"– das Konto ist kein Bargeld, und seine Periodenveränderung erscheint als Zeile in diesem Aktivitätsabschnitt.
Standardmäßig behandelt der Bericht Konten, deren Namen Cash, Checking, Savings oder Bank enthalten, als Zahlungsmittel. Eine deklarierte Rolle überschreibt das in beide Richtungen. cash-flow-role: "cash" zieht ein Konto herein, das die Namensregel übersehen hat – einen Geldmarktfonds, eine Stablecoin-Wallet. Und cash-flow-role: "investing" auf Assets:US:Bank:CD bewirkt mit einer Zeile zwei Dinge: Es schließt das CD vom Bargeld aus und ordnet es den Investitionen zu, obwohl sein Name zur Bargeldregel gepasst hätte.
Wir haben bewusst einen Schlüssel statt zwei verwendet. „Ist dieses Konto Bargeld?" und „Zu welchem Aktivitätsabschnitt gehört es?" waren nie unabhängige Fragen – ein Konto ist entweder Teil des Bargeldbestands oder es gehört zu genau einem Aktivitätsabschnitt. Zwei Schlüssel hätten unsinnige Zustände erlaubt, wie ein Bargeldkonto mit einer Aktivitätsrolle. Ein Schlüssel macht die illegalen Zustände unrepräsentierbar, und die gesamte Spezifikation passt in einen Tweet.

Die Klassifizierung, die Sie deklarieren, ist die Klassifizierung, die jede Ansicht verwendet. Das By-Activity-Diagramm stapelt die operativen, investiven und finanzierenden Bewegungen jedes Monats; wenn Sie die Rolle eines Kontos ändern, wandern seine Bewegungen in die richtige Ebene des Diagramms, den richtigen Abschnitt der Rechnung und die richtige Zeile des Exports – alles auf einmal.
Deklariert schlägt abgeleitet – und der Bericht zeigt seine Arbeit
Die Klassifizierung wird nun in einer strikten Reihenfolge aufgelöst: zuerst Ihre Metadaten, dann die eingebaute Heuristik. Und der Bericht ist ehrlich darüber, was er getan hat. Die Rechnung endet mit einem Feld „Cash & cash equivalents in this report", das genau auflistet, welche Konten beim Erstellen der Zahlen als Bargeld behandelt wurden, und gleicht sie dann ab: Bargeld zu Periodenbeginn, Bargeld am Periodenende und die Nettoveränderung, die die Aktivitätsabschnitte erklären.

Der Bericht unterscheidet außerdem zwischen Klassifizierungen, die Sie deklariert haben, und solchen, die er abgeleitet hat, und diese Unterscheidung fließt in CSV- und Markdown-Exporte ein: Eine Rechnung, die vollständig aus deklarierten Rollen besteht, trägt keine Zeile mehr mit dem Hinweis „Klassifizierung ist abgeleitet", denn an diesem Punkt ist die Klassifizierung keine Ableitung – sie ist Teil Ihrer Bücher.
Tippfehler werden so behandelt, wie ein Plain-Text-Werkzeug sie behandeln sollte. cash-flow-role: "invsting" wird nicht stillschweigend akzeptiert und nicht stillschweigend ignoriert: Das Konto fällt auf die Standardheuristik zurück, und das Statusfeld markiert es – „unbekannter cash-flow-role-Wert, Standard wird verwendet" –, sodass der Fehler dort sichtbar ist, wo Sie hinschauen, und nicht in einem Log vergraben.
Wenn Sie nichts ändern, ändert sich nichts
Nicht annotierte Konten verwenden dieselben veröffentlichten Standardwerte wie zuvor: Einnahmen und Ausgaben werden operativ zugeordnet, nicht zahlungswirksame Vermögenswerte investiv, Verbindlichkeiten und Eigenkapital finanzierend, und namenspassende Zahlungsmittel bilden den Bargeldbestand. Ein bestehendes Ledger rendert vor und nach diesem Release identisch. Die meisten Benutzer werden eine Handvoll Konten annotieren – diejenigen, bei denen der Standard falsch ist – und den Rest nie anfassen.
Auch die Portabilität bleibt unberührt. Metadaten auf open-Direktiven sind Kernbestandteil der Beancount-Syntax, werden von jedem v2/v3-Werkzeug geparst und von allem ignoriert, das nicht nach diesem spezifischen Schlüssel sucht. bean-check besteht, Fava zuckt mit den Schultern, und Ihr Ledger bleibt außerhalb von Beancount.io vollständig nutzbar.
Jede Ansicht Ihres Bargelds stimmt mit jeder anderen überein
Ein gemeinsamer Auflöser erzeugt die endgültige Rolle für jedes Konto, und jeder Verbraucher liest daraus:
- Der Cash-Flow-Bericht baut seine Aktivitätsabschnitte und seine Bilanzlinie – Nettoveränderung von Bargeld und Zahlungsmitteln – aus den aufgelösten Rollen auf.
- CSV-, Markdown- und Druckexporte tragen dieselben Zahlen, mit der Offenlegung abgeleiteter Klassifizierungen nur dort, wo tatsächlich eine Heuristik verwendet wurde.
- Das Übersichts-Sankey-Diagramm liest dieselben Deklarationen, sodass ein Konto, das Sie als Bargeld markiert haben, nicht mehr als Bewegungs-Knoten erscheint und Ihre deklarierten Aktivitätsrollen für Nicht-Einnahmen-Konten berücksichtigt werden.
- Das Kontostatusfeld listet ein deklariertes Konto nicht mehr als „nicht klassifizierter Vermögenswert" auf.

Es gibt keine Möglichkeit, dass die Rechnung und das Diagramm sich darüber uneinig sind, was Ihr Bargeld ist, denn es gibt nur eine Antwort, über die man uneinig sein könnte.
Warum das Ledger und keine Einstellungsseite
Das ist der Teil des Releases, bei dem wir uns am stärksten engagieren. Wir haben eine Einstellungs-UI in Betracht gezogen und sie aus drei Gründen verworfen:
- Das Ledger ist die Quelle der Wahrheit. Eine Klassifizierung, die irgendwo anders lebt, kann mit den Büchern, die sie beschreibt, in Widerspruch geraten. Eine Klassifizierung, die auf der
open-Direktive lebt, reist mit dem Konto – durch Umbenennungen, durch Repository-Umzüge, durch jeden Client, der die Datei liest. - Plain Text ist diffbar, grepbar und überprüfbar. Wenn Sie Ihr Ledger in git führen – und wenn Sie Beancount.io nutzen, tun Sie das – ist die Klassifizierungsregel jetzt etwas, das Sie
grep,diffundblamekönnen, und etwas, das ein Prüfer in einem Pull Request sehen kann. Eine Einstellungsseite ist nichts davon. - Es funktioniert offline und überall. Jeder Editor kann eine Rolle deklarieren. Jeder zukünftige Client, der das Ledger liest, erhält die Klassifizierung kostenlos, ohne pro Client Einstellungen synchronisieren zu müssen.
Aus demselben Grund sind Klassifizierungen bewusst nicht datumsbezogen wirksam. Die Metadaten beschreiben die Natur des Kontos, die sich selten ändert; wenn sie sich ändert, bearbeiten Sie die open-Direktive, und Ihre Git-Historie zeichnet auf, was sich wann geändert hat. Diese Historie ist der Prüfpfad.
Probieren Sie es an Ihrem Ledger aus
Die Funktion wird jetzt für alle Ledger ausgerollt. Eine Rolle zu deklarieren erfordert nur einen Texteditor:
- Öffnen Sie die Datei, in der die
open-Direktive des Kontos lebt. - Fügen Sie
cash-flow-role: "cash"(oder"operating","investing","financing") als eingerückte Metadatenzeile darunter ein. - Laden Sie den Cash-Flow-Bericht neu. Ihre Deklaration gewinnt sofort gegen die Heuristik.
Beginnen Sie mit den Konten, bei denen die Standardvermutung falsch ist – das CD, das nicht wirklich Bargeld ist, der Geldmarktfonds, der es wirklich ist, das Brokerage-Konto, das Sie sauber unter „Investing Activities" haben möchten. Lassen Sie den Rest in Ruhe. Die vollständige Spezifikation – akzeptierte Werte, Rangfolge, Standardklassifizierungen und wie ungültige Werte behandelt werden – finden Sie in der Referenz zu Cash-Flow-Rollen.
Der Cash-Flow-Bericht ist Teil jedes Beancount.io-Ledgers, neben Gewinn- und Verlustrechnung sowie Bilanz. Wenn Sie aufholen möchten, was diesen Sommer noch erschienen ist – intelligentere Importe, einen aktionsfähigen KI-Assistenten und eine neu aufgebaute Mobile-App – decken die Versionshinweise zu 3.6 den Rest ab.
Ihre Bücher wussten bereits, welche Konten Investitionen und welche alltägliche Ausgaben sind. Jetzt weiß es auch die Kapitalflussrechnung.
