Summarized: a ledger is a directed graph of accounts, where edges are transactions, and each transaction is recorded twice: in the "from" node and the "to" node.
I suspect some people (even some HN readers) would find it easier to think of ledgers as lists of transactions with running totals.
[0] e.g. it's not strictly true that book value is a lower bound on company value
But I guess you could model each transaction as an edge, with the direction specifying which account is debited and which credited, and the weight determining the amount.
I don't find that particularly helpful myself, but I put that down to my unfamiliarity with graph data structures and the associated algorithms. Maybe there's something you can do more easily with a graph database, than you can if you have the same info in a table?
In your chart of accounts, each account corresponds to exactly one of these:
- Asset
- Liability
- Equity (changes in this affect the income statement)
Whenever a transaction takes place, the debits and credits must sum up. For example, when you take a bank loan, your assets increase (debit) but your liabilities also increase (credit) by the same amount.
Sometimes something touches more than two accounts. For example, if you sell a cup of coffee for $2, using up $0.50 worth of beans:
CR Revenue $2 DR COGS $0.50 DR Cash $2 CR Materials $0.50
The first two lines increase the book value of the business by $1.50.
The last two lines increase the assets of the business by $1.50 (cash up by $2, bean inventory down by $0.50).
It's easy to get confused about debits and credits. I attempted to create a memorable explanation here: https://www.encona.com/posts/debits-and-credits