11–20 of 388 posts
In this case, you can be more precise about the type of graph: double-entry accounting creates a Directed[0] Bipartite Graph[1] with Labelled Edges[2]. Every edge is between a Transaction and an Account nodes, which makes it bipartite, and the amounts are edge labels.
[0] https://en.m.wikipedia.org/wiki/Directed_graph
My understanding of double-entry bookkeeping is that it does not care who Alice bought the book from, nor what their accounts look like. Instead, the "double entry" that complements the money leaving Alice's cash ledger is the entry of the value of the book into Alice's "book ledger", one decreases by $20, and the other increases by the same amount.
My understanding of double-entry bookkeeping is that it does not care who Alice bought the book from, nor what their accounts look like. Instead, the "double entry" that complements the money leaving Alice's cash ledger is the entry of the value of the book into Alice's "book ledger", one decreases by $20, and the other increases by the same amount.
In an organisation's accounting (Alice LLC), the basis entry would state a debit (increase of expense) in the book expenses account, credit (decrease of asset) in the cash balance. The complete entry would then make a reference to the invoice/receipt of the purchase and the contact details of the bookstore (address, chamber of commerce registration ID, tax number, etc.).
The exact level of detail is determined by how 'complete' your books are supposed to be. A book expense might not mean much to Alice LLC (which does not deal in book sales/purchases), but a laptop should (see more on the subject of fixed asset registries), or a large invoice from a business from a different country (which will require a lot more diligence with tax 'metadata').
On the other hand, the bookstore definitely cares more about books and will then consider the sale and replenishment of its book inventory, and once again introduce more meta-accounting data (see more on the subject of management/manufacturing accounting).
Don't store the account data. Instead store the transactions. Compute the accounts from that. The table "Transactions" should have the fields: Date, Amount, SourceAccount, TargetAccount, Description.
That is how it becomes beautiful in my opinion. Unlearn this habit of thinking in accounts just because that is what you know from your bank statements. Think in cash flows.
(Ok, this is too simple for the tax use case. Sometimes transactions have multiple sources or targets. So my schema above needs to be adapted for that. My point is that the thinking should still be different.)
I get that this is supposed to be a simplification for educational purposes, but I find this is simplification is an oversimplification, since it omits the key point.
I think people underestimate the beauty and impact of accounting. Just a tiny number of formulas (accounting identities [1]) and statements (P&L, balance sheet, etc.) can represent what's going on in any org in ways that can be roughly comparable. Reminds me of the "fundamental theorem of calculus" or "central dogma of biology". Accounting is also where we get math and written language [2] as ancient Mesopotamian civ…
Negative numbers were first used around the 3rd century in China and took until the 16th century to be used in Europe. Modern double-entry bookkeeping was invented in the 14th century in Europe. So if you ever wonder why they traditionally use a column for debit and one for credit, with definitions that seem a bit strange: that was the best way to make it work with only positive numbers.
I find it a strange choice to explain double-entry bookkeeping with the example of "one entry for Alice, one entry for Bob". That's really not what it's about. It's obvious that a transaction with two parties could be recorded in two places, but to me the crucial point of double-entry bookkeeping is that it requires two entries for each party of the transaction . So if Alice buys book from Bob, four entries are made.…
and bob is not even doing any bookkeeping. he is bookselling ;-)
Hi, all! I'm not an accountant but decided to study double-entry bookkeeping and basic accounting a while ago. I learned a lot from many places, including great threads here on HN, and wanted to give back to the community. In this article, I explain the mechanics of double-entry bookkeeping and how I came to realize it's a directed graph. I know there are many accounting nerds on HN so please feel free to criticize o…
Still too complicated. It goes wrong with "Let’s add the Transaction column to our table." Don't store the account data. Instead store the transactions. Compute the accounts from that. The table "Transactions" should have the fields: Date, Amount, SourceAccount, TargetAccount, Description. That is how it becomes beautiful in my opinion. Unlearn this habit of thinking in accounts just because that is what you know fro…