Beancount FAQ: Fragen zur Buchführung im Klartext

Etwa fünf Konzepte, keinen Abschluss. Du brauchst die fünf Kontotypen (Aktiva, Passiva, Eigenkapital, Erträge, Aufwendungen), die Vorstellung, dass jede Transaktion Wert zwischen mindestens zwei davon verschiebt, und die Regel, dass eine Transaktion ausgeglichen sein muss. Beancount erzwingt den Rest für dich — es markiert jede Transaktion, deren Zahlen nicht aufgehen, als Fehler, statt sie stillschweigend zu akzeptieren, sodass die Software die Fehler abfängt, die ein Anfänger sonst übersehen würde.

Beginne mit der Einführung in Beancount, halte das Glossar in einem Tab geöffnet und füge deine ersten Transaktionen im Schnellstart hinzu.

Beancount verwendet die Wörter „Soll" und „Haben" überhaupt nicht — es verwendet vorzeichenbehaftete Zahlen, die sich zu null summieren müssen. Geld, das ein Konto verlässt, ist negativ, Geld, das ankommt, ist positiv, und eine Transaktion ist gültig, wenn sich ihre Buchungen aufheben. Das ist dieselbe doppelte Buchführung, die Buchhalter betreiben, nur ohne das Vokabular, das Neueinsteiger verwirrt.

Wenn du herkömmliche Buchhaltungssoftware verwendet hast, lautet die Übersetzung: Ein Soll ist eine positive Zahl und ein Haben eine negative. Siehe die Referenz Sprachsyntax dafür, wie Buchungen geschrieben werden, oder Soll und Haben erklärt für den buchhalterischen Hintergrund in einfacher Sprache.

Weil Geld immer von irgendwoher kommt, und die Nullsumme ist das, was diese Tatsache in eine Fehlerprüfung verwandelt. Wenn du 40 $ für Lebensmittel ausgibst, hat dieses Geld ein Bankkonto verlassen — beide Hälften zu erfassen bedeutet, dass die beiden sich aufheben müssen, und jeder Tippfehler in einem der Beträge wird als Fehler markiert, statt still ein falsches Saldo zu erzeugen.

Deshalb ist ein Plain-Text-Hauptbuch vertrauenswürdiger als eine Tabelle mit Ausgaben: Die Struktur selbst ist selbstprüfend. Eine Saldo-Zusicherung ist der verwandte Mechanismus, der dein Hauptbuch gegen die Realität abgleicht.

Erfasse eine Transaktion an deinem Startdatum, die den aktuellen Saldo jedes Kontos von Equity:Opening-Balances verschiebt, und füge dann eine balance-Zusicherung hinzu, um ihn festzuschreiben. Du musst deine Finanzgeschichte nicht rekonstruieren — wähle ein Startdatum, übernimm die Salden so, wie sie an diesem Tag sind, und arbeite von dort aus weiter.

Der Schnellstart führt durch ein vollständiges Beispiel für Eröffnungssalden.

Beginne grob und teile nur auf, wenn eine feinere Aufteilung eine Entscheidung ändern würde. Etwa zwanzig Konten reichen für den Anfang völlig aus; wenn du dich fragst, ob „Expenses:Food" Lebensmittel von Restaurants trennen sollte, ist der nützliche Test, ob du tatsächlich anders handeln würdest, wenn du die Aufteilung kennst.

Umbenennen und Aufteilen später ist ein Suchen-und-Ersetzen in einer Textdatei, also sind die Kosten eines einfachen Starts gering. Kontonamen verschachteln sich, sodass du mit einer breiten Kategorie beginnen und sie später in Unterkonten aufteilen kannst, ohne die Geschichte neu zu schreiben — siehe Wie man einen Kontenplan entwirft, wenn du eine Struktur zum Nachbauen möchtest.

Eine Tabellenkalkulation kann dir nicht sagen, wann sie falsch ist. Plain-Text-Buchhaltung erzwingt die doppelte Buchführung, sodass jede Transaktion selbstprüfend ist, und die Datei bleibt greppbar, diffbar und skriptbar, solange es Textdateien gibt. Außerdem bekommst du echte Versionshistorie: git log auf deinem Hauptbuch zeigt genau, was sich wann und warum geändert hat.

Der praktische Unterschied zeigt sich bei mehreren Konten, Währungen oder Investitionen, wo eine einseitige Tabellenkalkulation stillschweigend von der Wahrheit abdriftet. Siehe Transparente und prüfbare Buchhaltung.

Wenn du nur wissen willst, was du für Kaffee ausgegeben hast, ja — eine Tabellenkalkulation reicht. Die doppelte Buchführung verdient sich ihren Platz in dem Moment, in dem du mehrere Konten, eine Hypothek, ein Brokerkonto oder mehr als eine Währung hast, denn genau das sind die Situationen, in denen einseitige Erfassung Geld verliert, ohne es dir zu sagen.

Eine nützliche Denkweise: Doppelte Buchführung ist eine Prüfsumme für deine Finanzen. Siehe die Einführung für die ausführlichere Begründung.

Nein. Fava ist eine vollständige Weboberfläche über derselben Textdatei — Bilanzen, Gewinn- und Verlustrechnungen, Diagramme und Transaktionseingabe — und Beancount.io betreibt sie für dich mit deinem Hauptbuch in der Cloud. Die Textdatei bleibt die Quelle der Wahrheit, sodass du die Weboberfläche täglich nutzen und nur dann zum Terminal wechseln kannst, wenn du möchtest. Wenn du ein Terminal bevorzugst, erstellt, prüft und berichtet der bea-Befehl über dieselbe Datei — siehe den CLI-Schnellstart.

Siehe UI-Funktionen für das, was die Oberfläche kann, oder probiere die Live-Demo aus.

Die meisten importieren 80–95 % der Transaktionen und geben den Rest manuell ein. In grober Reihenfolge der Zuverlässigkeit: ein direkter OFX/QFX-Download von deiner Bank, ein CSV-Export plus Importregeln, eine Aggregator-Verbindung und — nur als letztes Mittel — ein PDF-Kontoauszug, der in CSV umgewandelt wird. Beancount.io's Bank-Sync übernimmt die Verbindung und Kategorisierung für dich.

Rechne damit, eine Regel pro Institut zu schreiben oder anzupassen: CSV-Exporte von Banken sind notorisch inkonsistent, und ein Händlername mit einem nicht maskierten Komma ist ein echtes und häufiges Problem. Siehe Smart Import für den automatisierten Weg.

Für eine einmalige Datei erledigen zwei kostenlose Browser-Konverter den mechanischen Teil, ohne etwas hochzuladen: CSV zu Beancount für Tabellenkalkulations-Exporte und OFX & QIF zu Beancount für die .ofx-, .qfx-, .qbo- und .qif-Downloads, die Banken anbieten, wenn sie gar kein CSV anbieten.

Importer deduplizieren gegen bereits in deinem Hauptbuch vorhandene Einträge, indem sie nach Datum, Betrag und Zahlungsempfänger abgleichen, und markieren alles Mehrdeutige zur Bestätigung durch dich, statt zu raten. Der übliche Arbeitsablauf markiert unsichere Importe als ausstehend, damit du sie prüfst, bevor sie Teil der dauerhaften Aufzeichnung werden.

OFX macht das einfacher als CSV: Jede Transaktion trägt eine FITID, die die Bank über Downloads hinweg stabil hält, sodass ein Importer nach Identität statt nach Schlussfolgerung abgleichen kann — der OFX-Konverter bewahrt sie als id:-Metadatenfeld auf.

Die andere Hälfte der Antwort sind Überträge: Geld, das zwischen zwei Konten wechselt, die dir gehören, taucht in den Exporten beider Banken auf. Erfasse es einmal als einzelne Transaktion mit zwei Buchungen.

Nein — und für viele Menschen ist genau das der Grund, überhaupt Plain-Text-Buchhaltung zu verwenden. Du kannst OFX oder CSV selbst von deiner Bank exportieren und niemals Zugangsdaten an einen Aggregator weitergeben. Wenn du automatische Synchronisierung bevorzugst, verwendet Beancount.io einen bankzugelassenen Aggregator, statt dein Online-Banking-Passwort zu speichern.

Lies die Details auf der Sicherheitsseite.

Füge eine balance-Zusicherung für den Schlusssaldo des Auszugs hinzu, datiert auf den Tag nach dem Abschlussdatum. Saldo-Zusicherungen werden zu Beginn ihres Datums ausgewertet, sodass die Zusicherung am nächsten Morgen alle Transaktionen bis zum letzten Auszugstag einschließt. Wenn dein Hauptbuch von der Bank abweicht, meldet bea check einen Balance failed-Fehler und beendet sich mit einem Fehlercode, was den Abgleich von einem manuellen Vergleich in etwas verwandelt, das die Software bei jedem Durchlauf prüft.

Ein monatlicher Rhythmus reicht für die meisten. Siehe Filtern und Suchen, um eine Abweichung aufzuspüren.

Nativ, und das ist einer seiner stärksten Vorteile gegenüber Consumer-Finanz-Apps. Jeder Betrag trägt seine Währung, Konten können mehrere gleichzeitig halten, und Umrechnungen werden explizit mit @ für einen Preis oder {} für Anschaffungskosten erfasst, sodass eine Wechselkursänderung niemals stillschweigend deine Geschichte umschreibt.

Nichts wird hinter deinem Rücken umgerechnet — du siehst immer sowohl die ursprüngliche Währung als auch den umgerechneten Wert. Siehe Sprachsyntax, Präzision & Toleranzen und Mehrwährungsbuchhaltung für die buchhalterische Seite.

Verwende Live-Kurse für unterstützte Assets in einem gehosteten Beancount.io-Hauptbuch oder hole Kurse in lokale Kursdateien für Upstream-Beancount und Fava. Die Auswahl ermöglicht es dir, eine Kurswährung zu wählen und verwaltete Includes zu kopieren. Kompatible bea-Versionen unterstützen ebenfalls verwaltete Includes; die Einrichtungsanleitung verlinkt auf ihre Anweisungen.

Verwaltete Kurse wirken sich auf die Marktbewertung aus, nicht auf Transaktionsbeträge oder Anschaffungskosten. Dein eigener Kurs hat Vorrang für dasselbe Datum und Paar. Aktualisierungen können während eines Ausfalls veraltete zwischengespeicherte Kurse verwenden, und ein späterer Kurs kann ein fehlendes historisches Bewertungsdatum nicht füllen.

Erfasse Käufe mit Anschaffungskosten in geschweiften Klammern — 10 AAPL {150.00 USD} — und Beancount verfolgt jedes Los separat. Wenn du verkaufst, sagst du, welches Los du reduzierst, und der Kapitalgewinn ergibt sich automatisch aus der Arithmetik, statt etwas zu sein, das du von Hand berechnest.

Beancount unterstützt die Buchungsmethoden STRICT, FIFO, LIFO und NONE. Die Durchschnittskostenbuchung wird geparst, ist aber nicht vollständig implementiert — wenn deine Steuerjurisdiktion Durchschnittskosten verlangt, plane, sie mit einem Plugin oder expliziten Losen zu verfolgen. Siehe Bestandsverwaltung.

Genau wie jede andere Ware: Eine Kryptowährung ist eine Einheit mit Anschaffungskosten, also gilt dieselbe Los- und Buchungsmaschinerie. Ein Tausch eines Tokens gegen einen anderen ist eine einzelne Transaktion, die ein Los reduziert und ein anderes eröffnet, und genau so erhältst du den realisierten Gewinn, den die meisten Steuerbehörden gemeldet haben wollen.

Siehe Kryptowährungs-Portfolio-Tracking und die fertigen Krypto-Vorlagen.

Unternehmen nutzen es, einschließlich Firmen mit Hunderttausenden von Transaktionen. Es bewältigt Periodenabgrenzung, Mehrgesellschaftsstrukturen und die Berichte, die ein Buchhalter erwartet. Die ehrlichen Grenzen sind, dass es keine gleichzeitige Bearbeitung durch mehrere Benutzer, keine integrierte Rechnungsstellungs-UI und keinen Genehmigungsworkflow für Verbindlichkeiten gibt — es ist ein Hauptbuch, kein ERP.

Siehe Branchenspezifische Einrichtungen und die Open-Ledger-Präsentation echter Firmenbücher.

Halte sie getrennt — entweder als unterschiedliche Kontenbäume auf oberster Ebene in einer Datei oder als zwei Dateien, die mit include kombiniert werden. Sie zu vermischen macht die Gewinn- und Verlustrechnung des Geschäfts bedeutungslos und erschwert die Steuerzeit, und sie zu trennen kostet im Voraus nichts.

Zwei Dateien sind meist die sauberere Wahl, sobald das Geschäft ein eigenes Bankkonto hat. Siehe Multi-File-Unterstützung.

Modelliere Forderungen als Aktivkonto und Verbindlichkeiten als Passivkonto, dann erfasse die Rechnung, wenn du sie ausstellst, und die Zahlung, wenn sie eingeht — das ist Periodenabgrenzung, und Beancount unterstützt sie direkt. Was es nicht hat, ist eine Rechnungsstellungsschnittstelle: Es verfolgt, was dir geschuldet wird, es erstellt oder versendet die Rechnung nicht.

Siehe Finanzberichtsvorlagen für die Berichtsseite, Branchenspezifische Einrichtungen für durchgearbeitete Beispiele und Forderungen verstehen für die Konzepte.

Exportiere die Berichte statt des Hauptbuchs. Dein Buchhalter will mit ziemlicher Sicherheit keine Textdatei — er will eine Gewinn- und Verlustrechnung, eine Bilanz und eine Transaktionsliste, die du als CSV oder PDF aus der Weboberfläche oder mit einer Abfrage erzeugen kannst.

Siehe die Steuervorbereitungsleitfäden, Finanzberichtsvorlagen und Abfragen mit SQL, um genau die Zahlen herauszuziehen, nach denen sie fragen.

Alle drei sind Plain-Text-Systeme mit doppelter Buchführung und ähnlichen Dateiformaten. Ledger ist das Original und der nachsichtigste Parser; hledger ist eine Haskell-Neuimplementierung, bekannt für freundliche CSV-Importregeln und Dokumentation; Beancount hat den strengsten Parser und die stärkste Unterstützung für Investitionen, Lose und mehrere Währungen, plus eine Python-Plugin-API.

Strenge ist der eigentliche Kompromiss: Beancount weigert sich, eine Datei zu laden, die es als mehrdeutig empfindet, was Fehler früh abfängt, um den Preis, wählerischer zu sein. Siehe Beancount vs Ledger CLI und Beancount vs hledger.

Nicht nativ — das ist eine echte Lücke und kein verstecktes Feature. Beancounts integrierte Budgetierung ist begrenzt, und Leute, die striktes Umschlagverhalten wollen, verwenden typischerweise ein Community-Plugin oder modellieren Umschläge als Konten.

Wenn Umschlag-Budgetierung die Hauptsache ist, die du willst, lies Beancount vs YNAB, bevor du wechselst. Für das, was heute funktioniert, siehe Budgetierung in Beancount.

Ja. Die document-Direktive verknüpft eine Datei mit einem Konto und Datum, und die Weboberfläche lässt dich diese Dokumente zusammen mit den Transaktionen, zu denen sie gehören, hochladen und durchsuchen. Belege bleiben gewöhnliche Dateien auf der Festplatte, also sind sie so portabel wie das Hauptbuch selbst.

Siehe UI-Funktionen.

Ja — Beancount.io veröffentlicht iOS- und Android-Apps zum Anzeigen deines Hauptbuchs und zum Erfassen von Transaktionen unterwegs, was die Lücke ist, die die meisten Plain-Text-Setups offen lassen.

Für schnelles Erfassen ohne App notieren viele eine grobe Notiz und gleichen sie später ins Hauptbuch ab.

Ein Jahrzehnt Privatfinanzen sind ein paar Megabyte und laden in deutlich unter einer Sekunde. Beancount berechnet Salden bei jedem Laden aus der vollständigen Transaktionsgeschichte neu, und das bleibt bis in die Hunderttausende von Einträgen schnell. Darüber hinaus ist die Grenze der Bearbeitungs- und Diff-Komfort, nicht die Ladezeit: Das Aufteilen nach Jahr mit include hält einzelne Dateien klein, aber die eingebundenen Dateien bilden weiterhin ein kombiniertes Hauptbuch, das Beancount vollständig lädt und neu berechnet, also ist es eine Bequemlichkeit der Dateiorganisation und keine Beschleunigung oder eine Möglichkeit, getrennte Bücher zu führen.

Siehe Multi-File-Unterstützung dafür, wie man ein wachsendes Hauptbuch aufteilt.