- Auch wenn Buchhaltungsbegriffe ungewohnt sind, lässt sich doppelte Buchführung als Modell für Geldflüsse verstehen, wenn man sie als Struktur betrachtet, die Konten und Salden über die Zeit verfolgt
- Eine Tabelle, die nur den aktuellen Saldo überschreibt, verliert den Verlauf der Änderungen; ein Ledger hingegen fügt bei jeder Transaktion Einträge hinzu und bewahrt Historie sowie Korrekturspuren
- Einfache Buchführung kann ausreichen, um Änderungen je Konto zu erfassen; wenn sich jedoch mehrere Konten gemeinsam bewegen, sollten die zugehörigen Einträge zu einer Transaktion gebündelt werden, um Quelle und Ziel sichtbar zu machen
- Bei der doppelten Buchführung müssen pro Transaktion ausgehende und eingehende Beträge gleich sein; diese Gleichgewichtsbedingung hilft in der manuellen Buchhaltung wie eine Checksumme, Fehler zu finden
- Betrachtet man Konten und Transaktionen als Knoten sowie Soll- und Haben-Einträge als gerichtete Kanten, wird das Buch zu einem mit der Zeit wachsenden gerichteten Graphen; auch Finanzberichte lassen sich als dessen Visualisierung verstehen
Welche Informationen verloren gehen, wenn man nur Salden erfasst
- Buchhaltung bedeutet, zählbare Dinge über die Zeit zu verfolgen; hier liegt der Fokus auf Geldflüssen
- Im Beispiel beginnt Alice am 1. Januar 2024 mit $100 und Bob mit $50
- Wenn Alice Bob $20 für ein Buch zahlt, beträgt Alices Saldo $80 und Bobs Saldo $70
- Ein Konto (account) ist dabei der Ort, an dem Geld gespeichert wird, und ein Saldo (balance) ist die Geldmenge, die sich zu einem bestimmten Zeitpunkt auf dem Konto befindet
- Wenn man nur den aktuellen Saldo überschreibt, ist schwer zu erkennen, warum Alice $80 hat
- ob sie ursprünglich $0 hatte und $80 erhalten hat
- oder ob sie von $10.000 ausgehend $9.920 ausgegeben hat
- Eine Methode, die nur Saldo-Snapshots speichert, löscht den Ablauf der Veränderungen
Ledger der einfachen Buchführung und unveränderliche Aufzeichnungen
- Um den Änderungsverlauf zu bewahren, sollte bei jeder Transaktion eine neue Zeile hinzugefügt werden, statt bestehende Werte zu ändern
- Ein Ledger-Eintrag enthält üblicherweise die folgenden Informationen
- Description: eine für Menschen lesbare Beschreibung wie Transaktionsbeschreibung, Zahlungsempfänger oder Referenznummer
- Date: das Datum der Transaktion, das auch für periodische Gruppierungen wie Monatsberichte genutzt werden kann
- Balance: der Kontosaldo nach der Transaktion; redundante Information, aber nützlich für die Datenprüfung
- Jede Zeile ist ein Eintrag (entry), und die Sammlung der Einträge eines Kontos ist ein Ledger
- In Alices Ledger stehen am 1. Januar 2024 ein opening balance von $100 und am 1. Februar 2024 bought book mit -$20
- In Bobs Ledger stehen opening balance $50 und sold book $20
- Diese Methode ist ein System der einfachen Buchführung (single-entry bookkeeping)
- Jedes Konto hat sein eigenes Ledger
- Es werden Einträge erfasst, die jeweils ein Konto betreffen
- Für kleine Unternehmen oder persönliche Finanzen kann das gut passen
Ein Ledger verhält sich wie Event Sourcing
- Eine wichtige Eigenschaft eines Ledgers ist, dass die Daten unveränderlich (immutable) sind
- Sobald ein Eintrag geschrieben wurde, wird er nicht geändert, damit die vollständige Historie erhalten bleibt
- Wenn der Buchpreis fälschlich mit $20 erfasst wurde, der tatsächliche Preis aber $30 beträgt, ginge durch Ändern der bestehenden Zeile der ursprüngliche Betrag und die Tatsache der Korrektur verloren
- Besser ist es, einen neuen Eintrag hinzuzufügen, der den bestehenden Eintrag ausgleicht, und anschließend den korrekten Eintrag erneut zu erfassen
- Der Eintrag -$20 wird mit +$20 storniert
- Danach wird ein neuer Eintrag von -$30 erfasst
- Der endgültige Saldo ist ebenfalls $70, aber Fehler und Korrekturgrund bleiben erhalten
- Diese Methode ähnelt Event Sourcing in der Informatik
- Ereignisse, die im System auftreten, werden gespeichert
- Der aktuelle Zustand wird berechnet, indem die Ereignisse erneut abgespielt werden
- Der Zustand zu einem bestimmten Zeitpunkt kann rekonstruiert werden
Wann doppelte Buchführung nötig wird
- Bei Transaktionen, in denen mehrere Konten gemeinsam bewegt werden, lässt sich die Beziehung mit einfacher Buchführung allein nur schwer eindeutig erkennen
- Alices -$20 und Bobs +$20 sind dasselbe Geld; betrachtet man nur einfache Ledger, ist das jedoch nicht davon zu unterscheiden, dass Bob das Geld von Charlie erhalten haben könnte
- Bündelt man zugehörige Einträge zu einer Transaktion (transaction), lässt sich ausdrücklich festhalten, dass sie zum selben Ereignis gehören
- Transaction 1: Alices opening balance
- Transaction 2: Bobs opening balance
- Transaction 3: Alice kauft von Bob ein Buch
- Eine Transaktion ist eine Gruppe zusammengehöriger Einträge, die unterschiedliche Konten betreffen
- Doppelte Buchführung verbindet zugehörige Einträge auf Transaktionsebene, damit Geldflüsse zwischen Konten sichtbar werden
Soll, Haben und Gleichgewichtsbedingung
- Die traditionelle Buchhaltung stellt Geldflüsse in zwei Spalten dar: debit und credit
- Credit: ein Eintrag, bei dem Geld aus einem Konto herausfließt
- Debit: ein Eintrag, bei dem Geld in ein Konto hineinfließt
- Wenn Alice Bob $20 zahlt, wird Alices Konto mit $20 credit und Bobs Konto mit $20 debit erfasst
- Die Begriffe credit/debit bei Bankkarten und die Buchhaltungsbegriffe debit/credit werden unterschiedlich verwendet
- In Papierbüchern wurde das Format des T-Kontos (T-account) verwendet, bei dem die linke Seite debit und die rechte Seite credit ist
- In Computersystemen muss man nicht zwingend zwei Spalten beibehalten
- Man kann in einer Spalte
TypeDebit oder Credit eintragen undAmountseparat führen - Oder man kann eine einzelne Betragsspalte verwenden, in der credit negativ und debit positiv ist
- Man kann in einer Spalte
- Statt der traditionellen Begriffe können incoming money und outgoing money weniger verwirrend sein
Transaktionen sind nicht auf zwei Einträge beschränkt
- Das Kernprinzip der doppelten Buchführung ist, dass sich die Gesamtsumme des Geldes im System nach jeder Transaktion nicht ändert
- Der Saldo eines bestimmten Kontos kann steigen oder fallen, aber die Summe aller Kontosalden muss konstant bleiben
- Auch ein Opening Balance muss, um ausgeglichen zu sein, irgendwoher stammen
- Im Beispiel wird ein Bank-Konto hinzugefügt, über das Alices $100 und Bobs $50 als aus der Bank herausfließend erfasst werden
- Dieses Bank-Konto ist eine Art temporäres Konto zur Einhaltung der Regeln und entspricht in der Buchhaltung einem contra account
- Bei jeder Transaktion müssen ausgehendes und eingehendes Geld gleich sein; das funktioniert in der manuellen Buchhaltung wie eine Checksumme (checksum), um Fehler zu erkennen
- Auch komplexe Transaktionen lassen sich nach demselben Prinzip modellieren
- Alice zahlt Bob $20 und dem Kreditkartenunternehmen $2 Fremdwährungsgebühr
- Bob erhält $20 von Alice und zahlt $2 Umsatzsteuer an die Steuerbehörde sowie $1 Gebühr an das Kreditkartenunternehmen
- Das Kreditkartenunternehmen erhält $2 von Alice und $1 von Bob
- Die Steuerbehörde erhält $2 von Bob
- In diesem Fall enthält eine einzige Transaction 3 genau 8 Einträge
- „Double-entry“ bedeutet nicht, dass eine Transaktion nur zwei Einträge hat, sondern dass sie zwei Seiten hat: eine, auf der Geld herausfließt, und eine, auf der Geld hineinfließt
Das Buch als gerichteten Graphen betrachten
- Doppelte Buchführung kann als Modellierung von Geldflüssen als gerichteter Graph verstanden werden
- Die Entsprechungen im Graphen sind wie folgt
- Konten sind Knoten im Graphen
- Transaktionen sind ebenfalls eigene Knoten
- Credit-Einträge sind ausgehende Kanten vom Konto zur Transaktion
- Debit-Einträge sind eingehende Kanten von der Transaktion zum Konto
- Der Betrag eines Eintrags ist der Wert der Kante
- Der Kontosaldo ist die Summe der eingehenden Kanten minus die Summe der ausgehenden Kanten
- Transaction 1 verschiebt $100 von Bank zu Alice
- Transaction 2 verschiebt $50 von Bank zu Bob
- Transaction 3 verschiebt $20 von Alice zu Bob
- In dieser Darstellung beträgt Alices Saldo $80 und Bobs Saldo $70
Modellierungsentscheidung: komplexe Transaktionen aufteilen
- Wenn Gebühren und Steuern alle in eine Transaktion aufgenommen werden, bekommt Transaction 3 viele Kanten und wird komplex
- Derselbe Geldfluss kann auch in kleinere Transaktionen aufgeteilt werden
- Aus Alices Konto fließen $22 ab
- Bob erhält $19
- Die übrigen $3 gehen an das Kreditkartenunternehmen
- Bobs Umsatzsteuer von $2 wird als separate Transaction 4 behandelt
- Unabhängig davon, wie Transaktionen und Einträge gruppiert werden, können die endgültigen Kontosalden gleich sein
- Alice: $78
- Bob: $67
- Tax authority: $2
- Credit card company: $3
- Buchhaltungssysteme sind flexibel genug, um unterschiedliche Anforderungen abzudecken; wie Transaktionen und Einträge gruppiert werden, sollte passend zum Geschäft festgelegt werden
Finanzberichte als Visualisierung des Graphen
- Der Graph wächst mit der Zeit, wenn neue Transaktionen hinzugefügt werden
- Die grundlegenden Eigenschaften des Graphen bleiben erhalten
- Konten bleiben Knoten
- Transaktionen bleiben Knoten, die Geldflüsse erzwingen
- Bei jeder Transaktion muss die Summe der ausgehenden Beträge der Summe der eingehenden Beträge entsprechen
- Balance sheet, income statement und cash flow statement lassen sich als Visualisierungen dieses Graphen verstehen
- Kategorien wie assets, liabilities, equity, income und expenses lassen sich als Knotengruppen im Graphen betrachten
- Aus der Graphperspektive lässt sich intuitiver verstehen, wie credit und debit die Salden der jeweiligen Kategorien erhöhen oder verringern
1 Kommentare
Meinungen auf Hacker News
Doppelte Buchführung mit „ein Posten bei Alice, ein Posten bei Bob“ zu erklären, wirkt wie eine seltsame Wahl
Dass etwas an zwei Stellen verbucht werden kann, wenn es zwei Transaktionsparteien gibt, ist selbstverständlich; der Kern ist aber, dass für jede Partei der Transaktion zwei Posten nötig sind. Wenn Alice von Bob ein Buch kauft, entstehen vier Posten
Ich verstehe, dass das eine didaktische Vereinfachung sein soll, halte es aber für eine übermäßige Vereinfachung, die den Kern weglässt
Wenn man zum Beispiel Verbindlichkeiten aus Lieferungen und Leistungen mit Bargeld bezahlt, sendet man gleichzeitig eine Nachricht an den Akteur Accounts Payable und den Akteur Cash; jeder Akteur übersetzt das Ereignis entsprechend seiner Eigenart in Soll/Haben und hält seinen Saldo aktuell. Aus dieser Perspektive bedeutet doppelte Buchführung eher, dass jedes Ereignis von einer geraden Anzahl von Akteuren genau einmal absorbiert werden muss
Wenn man Payment Rails baut, kann dieses Ereignis selbst auch eines von einem Paar von Ereignissen sein, die aus einem Meta-Ereignis zur Verfolgung der Transaktionsabsicht abgeleitet wurden. Die Kanten des Graphen, von denen man in der Buchhaltung spricht, sind nicht Geld, sondern eher Daten innerhalb einer Hierarchie abgeleiteter Ereignisse
Allerdings macht der Originaltext nicht klar, wofür diese Analogie gedacht ist, und ich fürchte, sie stiftet eher mehr Verwirrung, als sie zu reduzieren
Bobs Buchhaltung interessiert mich nicht; ich will nur meine eigene Buchhaltung nachverfolgen. Wenn ich ein Buch gekauft habe, interessiert mich, wie diese Transaktion in meiner Buchhaltung nach den Regeln der doppelten Buchführung zu erfassen ist
Außerdem macht Bob keine Buchhaltung, sondern verkauft ein Buch ;-)
Wie müsste man diesen Text überarbeiten, damit der „double“-Teil richtig erklärt wird? Ginge das auch nur aus der Sicht von Bob oder Alice?
Zum Beispiel kann eine Bank entscheiden, dass ich einen Kredit wahrscheinlich nicht zurückzahlen werde, und ihn in ihren Büchern auf 0 abschreiben. Ich kann weiterhin vorhaben zu zahlen und die Verbindlichkeit in meinen Büchern stehen lassen. Die Bank erzeugt die entsprechenden Posten in ihrem System, Soll und Haben gleichen sich aus, und selbst wenn ich nichts tue, bleibt mein Hauptbuch im Gleichgewicht
Doppelte Buchführung hat nichts mit anderen Rechtssubjekten zu tun, sondern nur mit den eigenen Büchern
Ich finde, die Schönheit und Wirkung der Buchhaltung wird unterschätzt
Mit sehr wenigen Formeln, nämlich der Bilanzgleichung, und Abschlüssen wie Gewinn- und Verlustrechnung sowie Bilanz kann man ungefähr vergleichbar darstellen, was in einer Organisation passiert. Es erinnert mich an den Fundamentalsatz der Analysis oder das zentrale Dogma der Biologie
Buchhaltung ist auch ein Ursprung von Mathematik und Schriftsprache. Die antike mesopotamische Zivilisation verwendete zunächst „Buchhaltungs-Token“, die die Form von Gegenständen nachahmten, um Waren zu verfolgen; daraus kann man die Entwicklung von Schriftsprache, etwa Hieroglyphen, ableiten
Später schuf Al-Khwarizmi Al-Jabr, also Algebra, um islamisches Erbrecht zu lösen; als die Regeln der Erbverteilung zu Gleichungen wurden, entstand der Bedarf, sie schnell und exakt zu lösen. Al-Khwarizmis Verfahren zur Lösung quadratischer Gleichungen ist der Ursprung des Namens „algorithm“
https://en.wikipedia.org/wiki/Accounting_identity
https://en.wikipedia.org/wiki/History_of_accounting
https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
https://en.wikipedia.org/wiki/Al-Jabr
https://en.wikipedia.org/wiki/Al-Khwarizmi
Negative Zahlen wurden in China etwa im 3. Jahrhundert erstmals verwendet und waren in Europa bis ins 16. Jahrhundert nicht weit verbreitet. Die moderne doppelte Buchführung entstand im Europa des 14. Jahrhunderts
Die traditionelle Methode mit getrennten Soll- und Haben-Spalten und Definitionen, die etwas seltsam wirken, war deshalb die beste Möglichkeit, nur mit positiven Zahlen zu arbeiten
Viele wichtige Aspekte des Organisationsdesigns korrelieren nur lose mit Finanzabschlüssen
Erst nachdem Buchführung in allen Schichten der Gesellschaft Wurzeln geschlagen hatte, wurden negative Zahlen als ebenso real akzeptiert wie positive
Doppelte Buchführung ist sehr leicht zu verstehen, wenn man die lächerlichen Begriffe „credit“ und „debit“ weglässt.
Der Kern ist, dass die Bilanzgleichung immer wahr bleiben muss. Die Grundformel lautet Equity = Assets - Liabilities, und da Gewinn letztlich ins Eigenkapital eingeht, wird daraus Equity + Income - Expenses = Assets - Liabilities. Wenn man negative Werte eliminiert, ergibt sich Equity + Income + Liabilities = Assets + Expenses.
Diese Gleichung muss immer wahr sein; andernfalls wäre Geld einfach aus dem Nichts entstanden oder verschwunden. Wenn man also einem Konto auf der linken Seite der Gleichung Geld hinzufügt, muss man entweder einem Konto auf der Gegenseite denselben Betrag hinzufügen oder auf derselben Seite denselben Betrag abziehen.
Verkauft man zum Beispiel Limonade für 5 Dollar, erhöht man Sales (Income) um 5 Dollar und zugleich Current Account (Assets) um 5 Dollar.
„credit“ und „debit“ sind deshalb lächerlich, weil sich ihre Definition je nach Kontotyp umkehrt, und diese absurde Sprachverwendung ist der Hauptgrund dafür, dass Leute verwirrt sind.
Der Dozent in einem Accounting-Kurs auf Stufe 100 hat es ziemlich knapp formuliert: Debit ist ein Eintrag in der linken Spalte, Credit ist ein Eintrag in der rechten Spalte. Was diese Transaktion für das Geschäft bedeutet, hängt vom Konto ab.
Für jemanden, der keine Buchhaltung gelernt hat, ist diese Verwendung der Begriffe extrem verwirrend, und viele Antworten an verwirrte Personen sind zwar technisch korrekt, aber zugleich wenig hilfreich. Sie setzen nämlich voraus, dass man die Begriffe bereits kennt.
Die Frage „Warum wird mein Bankkonto debited, obwohl der Kontostand steigt? Ist debit nicht negativ? Wird mein Barbestand als negativ angezeigt?“ ist eine wirklich gute Frage. Intuitiv bedeutet direct debit, dass Geld abfließt, mit einer debit card gibt man Geld aus, und debit klingt wie debt; also denkt man leicht, debit sei immer negativ.
Es ist zugleich amüsant und frustrierend, wie Leute beim selben Wort aneinander vorbeireden, als sprächen sie unterschiedliche Sprachen. Manchmal driftet es auch dahin ab, dass an kleinen Formulierungen herumgekrittelt wird, nur um zu zeigen, dass man recht hat.
Denn aus Sicht der Person, die 5 Dollar für Limonade ausgibt, trägt sie diese 5 Dollar ganz sicher nicht in ihren Sales-Posten ein. Ich verstehe noch nicht vollständig, worin genau die Verwirrung besteht, die in diesem Artikel und in den Kommentaren beschrieben wird.
credit bedeutet Herkunft, debit bedeutet Ziel.
Wenn man einem Kunden 10.000 Euro in Rechnung stellt, entsteht zum aktuellen Wechselkurs ein Anspruch im Wert von 11.000 Dollar. Dann schreibt man dem Ursprungskonto „Income: Customer A“ 11.000 Dollar gut und belastet „Assets: Accounts Receivable“ mit 11.000 Dollar.
Wenn der Kunde später zahlt, der Wechselkurs sich aber bewegt hat und man nur 10.500 Dollar erhält, dann ist der ursprünglich mit 11.000 Dollar erfasste Anspruch die Herkunft; daher schreibt man Accounts Receivable 11.000 Dollar gut. Da man 10.500 Dollar Cash erhalten hat, belastet man cash mit 10.500 Dollar, und um Soll und Haben auszugleichen, belastet man „Expenses: Loss on Foreign Exchange“ mit 500 Dollar.
Normalerweise liquidiert man ein Unternehmen nicht an jedem Geschäftstag; warum sollte man diese 500 Dollar also zwanghaft in ein fiktives Sofortliquidationsszenario pressen? Man erfasst sie einfach als Ausgleich von credit und debit.
Es gab viel zu viele Diagramme, in denen die unabhängige Variable auf der Y-Achse stand.
„Credit ist ein Posten, bei dem Geld aus einem Konto herausgeht, Debit ist ein Posten, bei dem Geld in ein Konto hineingeht“ ist nicht korrekt.
Die Bedeutung von debit und credit hängt vom Kontotyp ab: https://en.wikipedia.org/wiki/Debits_and_credits
Vielleicht gibt es einen Grund dafür, dass man mehr als ein Fach braucht, um CPA zu werden: https://www.accounting.com/careers/cpa/how-to-become/.
Für mich wirkt es wie eine Methode aus der Zeit, als Menschen Einträge machten und Rechnungen ausführten, bei der man die Arbeit verdoppelte, um bestimmte Fehler zu finden. Für sich genommen ergibt das Sinn.
Aber vielleicht, weil ich in einer Welt aufgewachsen bin, in der Computer alle Berechnungen erledigen, wirkt es wie ein Verstoß gegen das Prinzip, dieselbe Arbeit nicht zu wiederholen. Wenn man denselben Inhalt an zwei Stellen einträgt, wird am Ende zwangsläufig eine davon falsch sein.
Wenn Buchhaltung heute neu entworfen würde, würde man es meiner Meinung nach nicht so machen. Dass ich kein Buchhalter bin und es nicht verstehe, heißt nicht, dass das System falsch ist; aber die Verwirrung, die ich dabei empfinde, dass „credit ein Aktivkonto verringert“, fühlt sich wie ein Signal an, dass etwas Grundlegendes nicht stimmt.
CR-Einträge erhöhen das, was das Unternehmen schuldet, also seine Verpflichtungen gegenüber Gläubigern oder Anteilseignern, und DR-Einträge erhöhen das, was das Unternehmen besitzt.
Zur Beziehung zur Bilanzgleichung siehe hier: https://news.ycombinator.com/item?id=32501707
Bei den Begriffen credit/debit scheint es viel Verwirrung zu geben.
Wenn man es aus moderner Sicht einfacher betrachten will, sollte man sich daran erinnern, dass Buchhaltung viel älter ist als die breite Verwendung negativer Zahlen. Würde man die Buchhaltung heute erfinden, hätte man vermutlich positive/negative Konten statt debit/credit-Konten verwendet.
Algebra auf Basis der Addition wirkt für uns heute natürlich, war für einen durchschnittlichen Händler im Jahr 1604 aber keineswegs selbstverständlich, und negative Zahlen waren damals ebenfalls nicht besonders gern gesehen.
Wichtig ist, dass eine Transaktion immer zwei Seiten hat und diese zueinander inverse Operationen sind. Credit und debit sind letztlich inverse Operationen auf Zahlen.
Deshalb kann man die Regel aufstellen: Wenn credit = debit, ist die Transaktion ausgeglichen. Modern ausgedrückt könnte man auch debit + credit = 0 sagen, aber als dieses System entstand, mochte man negative Zahlen nicht; daher ist das eher ein glücklicher Zufall, der immer gilt, als das eigentliche Ziel.
Es ist sinnvoll, Bargeld in der Hand als das am stärksten positive, also debit-artige Konto zu betrachten und von dort rückwärts zu denken. Um eine Ausgabe zu verbuchen, muss man das Bargeldkonto in die Gegenrichtung behandeln, also credit buchen, und dort, wohin das Geld gegangen ist, als Gegenposten debit buchen. Daher haben Aufwandskonten normalerweise einen Debit-Saldo.
Woher kam das Bargeld? Aus Einnahmen. Wenn man Bargeld debit-artig machen will, muss die Quelle credit-artig sein, damit die Transaktion nicht aus dem Gleichgewicht gerät. Deshalb sind Ertragskonten normalerweise credit-Konten, haben also üblicherweise einen negativen Saldo oder sind „credit normal“.
Das Schöne an diesem System ist, dass alle alltäglichen Transaktionen auf ausgeglichene Buchungen hinauslaufen und die möglichen Konten jeweils eine konsistente übliche Saldo-Eigenschaft haben, nämlich normalerweise credit oder debit. Wirklich elegant.
Wenn man sich das und die Bilanzgleichung merkt, kann man die normalen Salden aller anderen Kontotypen daraus ableiten.
Vor etwa einem Monat habe ich im PTA-Subreddit eine Diskussion darüber begonnen, wie man die PTA-Syntax intuitiver machen könnte. Jemand schlug vor, „from“, also credit-/negative Konten, und „to“, also debit-/positive Konten, mit Pfeilen darzustellen. Die Zahlen haben kein Vorzeichen, und die Begriffe „credit“ und „debit“ werden ebenfalls nicht verwendet, wodurch es sich deutlich intuitiver anfühlt.
https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
Der Hintergrund zu negativen Zahlen ist interessant.
Es ist immer noch viel zu kompliziert. Schon bei „Fügen wir der Tabelle eine Transaction-Spalte hinzu“ läuft es in die falsche Richtung.
Man sollte keine Kontodaten speichern, sondern Transaktionen. Konten kann man daraus berechnen. Eine „Transactions“-Tabelle braucht Felder wie Date, Amount, SourceAccount, TargetAccount und Description.
Aus meiner Sicht wird es genau dann elegant. Man muss die Gewohnheit ablegen, kontenzentriert zu denken, nur weil man es von Kontoauszügen gewohnt ist, und stattdessen in Cashflows denken.
Für Steuerzwecke ist das natürlich zu simpel. Es gibt Fälle, in denen eine Transaktion mehrere Quellen oder mehrere Ziele hat, daher müsste das obige Schema angepasst werden. Der Punkt ist aber, dass sich die Denkweise ändern sollte.
Das ist ein Zeichen dafür, dass ein Programmierer clever sein wollte und versucht hat, kumulierte Summen zu pflegen, statt sie aus den ursprünglichen Transaktionen zu berechnen. Dort lauern Drachen.
Ein besseres Design besteht aus einer Header- und einer Detailtabelle.
Header: TransactionID, Date, Description sowie benötigte Felder wie posting status oder reconciliation status
Detail: TransactionID, LineNumber, Account, Amount, Description sowie benötigte Felder wie eine subledger-Referenznummer
So kann eine einzelne Transaktion eine beliebige Anzahl von Konten beeinflussen. Letztlich spiegelt die Transaktion dann einen Geschäftsvorfall wider, der mehrere Konten betreffen kann.
Im Detail ist es etwas komplizierter, etwa weil die Outputs jeder Übertragung die Quelladresse enthalten müssen, aber die Idee ist dieselbe. Wie an anderer Stelle in diesem Thread erwähnt, braucht jede Transaktion mehrere Inputs und mehrere Outputs.
Alle Transaktionen stehen in einer Klartextdatei, und wenn eine Auswertung nötig ist, wird daraus ad hoc das gesamte Hauptbuch erzeugt.
Ich bin zwar kein Buchhalter, habe mir aber vor einiger Zeit vorgenommen, doppelte Buchführung und die Grundlagen der Rechnungslegung zu lernen, und habe an vielen Stellen viel gelernt, darunter in guten HN-Threads.
In diesem Beitrag erkläre ich, wie doppelte Buchführung funktioniert und wie mir klar wurde, dass sie ein gerichteter Graph ist. Auf HN gibt es viele Rechnungswesen-Nerds; falls etwas falsch ist, freue ich mich über Kritik oder Korrekturvorschläge.
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
Ich wünschte, meine Controller würden die Vertriebszahlen als solchen grafischen Flow aufbereiten. Ab einer gewissen Größe wird Rechnungslegung ziemlich schwierig, bis zu dem Punkt, an dem man im Accounting-Policy-Team Leute auf Professorenniveau braucht.
Was ich aus der Statistik gelernt habe: Grafik ist wichtig. Mit der passenden Abstraktion lässt sich jede Kennzahl als Graph ihrer Bestandteile darstellen. Plötzlich ging mir ein Licht auf.
Auf der einen Seite steht Geld, das herein- oder hinausfließt, auf der anderen ein Produkt oder eine Dienstleistung. Das ist die doppelte Buchung im Rechnungswesen. Das mag offensichtlich und einfach erscheinen, aber in meinem Bereich verstehen das nicht viele.
Ein gut geschriebener Artikel, aber man sollte vorsichtig sein, wenn man Begriffe neu definiert, die allgemein anerkannte Bedeutungen haben.
Debit/Credit in Incoming/Outgoing umzubenennen wirkt wie ein weiterer Fachjargon und kann verwirren. Jeder Bookkeeper versteht, was credit cash und debit expense bedeutet.
Das in incoming/outgoing umzubenennen hilft weder den Leuten, die die eigentliche Arbeit machen, noch denen, die diese Arbeit erklären müssen. Es ist wertvoller, die seit Jahrhunderten nützliche Terminologie zu lernen, als sich auf eine Analogie zu stützen.
Wenn solche Diskussionen auf HN auftauchen, sagt immer jemand: „Das ist ganz einfach. Credit ist einfach …“, und kurz darauf kommt eine Antwort: „Du hast es genau verkehrt herum. Ganz einfach: Credit ist …“
Von mir aus könnten diese Begriffe für immer verschwinden.
Wenn Geld credited wird oder man eine credit card benutzt, fühlt es sich gut an, als käme irgendwoher Geld; debit klingt wie debt und fühlt sich schlecht an, als würde mein Geld weniger.
Ich weiß, dass die Bezeichnungen tatsächlich Gründe haben, aber wenn ein Fachgebiet auf unintuitivem Jargon besteht, der mit allen Verwendungen kollidiert, die Außenstehende kennen, könnte man wohl auch weniger überladene, andere Begriffe verwenden.
Wenn man die richtigen Fachbegriffe korrekt verwendet und damit Gespräche führen kann, steigt die Glaubwürdigkeit enorm.
Ich verstehe nicht ganz, warum es wie Fachjargon wirken soll, die Rechnungswesen-Begriffe debit/credit in Alltagssprache zu erklären. Vielleicht liegt das daran, dass ich Laie bin.
Jemandem ohne Accounting-Hintergrund credit/debt als „Geld geht hinein, Geld geht hinaus“ zu erklären, scheint im Kontext dieses Artikels völlig in Ordnung. Funktioniert die „echte“ Definition von credit/debit hier in einer bedeutsam anderen Weise?
David P. Ellerman stellt einen mathematischen Ansatz für Rechnungswesen vor, der auf dem basiert, was er die Pacioli group nennt.
Ein provisorisches Element der Pacioli group sieht aus wie x//y, wobei x und y nichtnegative ganze Zahlen sind. x//y und u//v gelten als äquivalent, wenn die Kreuzsummen x+v und y+u gleich sind.
Die Gruppenoperation ist x//y + u//v = (x+u)//(y+v), das Inverse von x//y ist y//x, und das neutrale Element ist 0//0. Mehr Details finden sich zum Beispiel in diesem Dokument: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...
Ich habe das Gefühl, hier etwas zu übersehen. Wobei hilft es, Transaktionshistorien als gerichteten Graphen zu betrachten?
Gibt es dabei eine Verbesserung gegenüber der jahrhundertealten Praxis der doppelten Buchführung?
Bei einem Spielzeugbeispiel mit ein paar Transaktionen scheint es gerade so zu funktionieren, aber man muss sich nur vorstellen, wie der Graph aussieht, wenn zwischen Knotenpaaren Dutzende oder Hunderte Kanten entstehen. Ich sehe auch nicht, wofür allgemeine Graphalgorithmen nützlich sein sollen.
Das fühlt sich an, als würde man eine Zange als Hammer benutzen. Klar, man kann das machen, aber warum sollte man?
Erstens ist es eine weitere Möglichkeit, das Konzept zu verstehen. In den meisten Fällen ist das vielleicht irrelevant, aber wer weiß, ob ein schwieriges Accounting-Problem durch Anwendung von Graphentheorie gelöst werden kann – oder umgekehrt ein graphentheoretisches Problem durch Rechnungswesen.
Zweitens ist es eine weitere Möglichkeit, Flüsse zu visualisieren. Nicht alle haben hohe Finanzkompetenz oder ein gutes Zahlengefühl; statt ihnen eine Tabelle mit Zahlenspalten zu geben und sie die Flüsse aus den Zahlen ableiten zu lassen, kann man sie räumlich darstellen. Nicht jedes Tool ist nur für Experten gedacht.
Die gesamte kumulierte Historie als einen Graphen zu betrachten, kann übertrieben sein, aber schon ein Filter nach Transaktionsdatum könnte Erkenntnisse liefern, die andere Visualisierungen übersehen. Noch nützlicher könnte es werden, wenn man es mit anderen Informationen wie Standorten querverweist.
Er liefert keine Rechtfertigung, und die Aussage des Autors, diese Visualisierung habe zu einem klareren Verständnis beigetragen, wird durch den Kategorienfehler geschwächt, der entsteht, wenn man doppelte Buchführung von Anfang an auf Geek-Art erklärt.
Außerdem wurde nur eine sehr einfache einzelne Transaktion dargestellt. Ich sehe nicht, wie man abstraktere Themen mit einer graphbasierten Visualisierung erfassen soll, etwa unterschiedliche steuerliche und bilanzielle Abschreibung, Anpassungen von Fremdwährungsgewinnen und -verlusten, die Zuweisung von franked dividends, PAYG, für andere verwahrte Beträge oder die teilweise Erfassung von abgegrenzten Erlösen.
Ingenieure entdecken nachträglich grundlegende Prinzipien, die in anderen Bereichen längst vorhanden waren, während Software beginnt, diese Bereiche nachzubilden.