Live data from Hacker News

Double-entry bookkeeping as a directed graph

matheusportela.com

271–280 of 388 posts

Re: Double-entry bookkeeping as a directed graph

#271

Double-entry bookkeeping is the original CRDT. Just by maintaining a local invariant -- debits and credits in a transaction sum to zero -- a distributed network of agents attending to their own ledger can reliably maintain a global consistent state (like, money is neither created nor destroyed), or heal it in the case of corruption.

Came here for this comment. I’ve always kept an eye open for anyone who has applied this insight to something. There is something also satisfying about how accessible accounting is vs any other domain you encounter invariants (like noethers theorem, group theory, or equivariant neural networks)

Re: Double-entry bookkeeping as a directed graph

#273
post #190

Earlier quoted context omitted.

> You really don't need to use terminology like debit/credit for accounting. That's exactly right -- you don't need to. The problem is that people do use this terminology, and they use it in a way that conflicts with common usage, which makes a very simple concept vastly more confusing than it needs to be.

> which makes a very simple concept vastly more confusing than it needs to be. Agreed. The concepts are all very simple. You can throw away all of the domain-specific terminology and reason about accounting theory with nothing but positive and negative numbers. The utility of the confusing terminology and age old accounting frameworks isn't obvious unless you are a practitioner living "in it". It's not until you face…

Sorry, I don't buy it. By the time you get to the point where you're doing the accounting for an F500 company you have been thoroughly indoctrinated into the conventional way of doing things. That doesn't mean that the conventional way isn't deeply flawed. It's kind of like the use of British units in the USA rather than metric. You have 350 million people who are thoroughly comfortable with miles and feet and inches and gallons and whatnot, but that doesn't mean that metric isn't objectively superior.

Re: Double-entry bookkeeping as a directed graph

#274
post #32

> Definition 6: Credit An entry that represents money leaving an account. > Definition 7: Debit An entry that represents money entering an account. Not really, the meaning of debit and credit depends on the type of account: https://en.wikipedia.org/wiki/Debits_and_credits Maybe there's a reason why it takes more than one course to become a CPA ( https://www.accounting.com/careers/cpa/how-to-become/ ).

Second sentence of that wikipedia article is: "A debit entry in an account represents a transfer of value to that account, and a credit entry represents a transfer from the account."

Re: Double-entry bookkeeping as a directed graph

#275
post #205

Earlier quoted context omitted.

Depreciation isn't relevant here, again, you're confused in the types of assets, not all of them are depreciated, only some with some specific properties like time of expected user. Just read the definition of assets in any (accounting) dictionary, or try to record your snack purchase in real accounts and see which side of the balance sheet this account end up in (hint: inventories, assets).

The person you're replying to is confused, but that's because accounting can be confusing. An account is fundamentally either an asset or a liability. When you buy something with a credit card, you've incurred a liability, and gained an asset, no matter what you've purchased. If you use a debit card or cash, you're trading one asset for another. One of the basic asset categories is expenses. That's the confusing part…

This comment fleshes out what I'm saying here: https://news.ycombinator.com/item?id=39992035

Re: Double-entry bookkeeping as a directed graph

#276
post #262

Earlier quoted context omitted.

Do you actually do that? When people are working late at the office and you order pizzas you put that into your inventory and then remove it as people consume the pizzas? I record that into a separate operating expenses account meant for this kind of fringe benefit, not into inventory. Pretty small so I do the accounting as well, but I think I'd lose my mind if I had to record them into inventory. Then when they leav…

you don't need to record the halves, nothing stops your pizza order to be automatically recordered as -A_cash +A_inventory -A_inventory + L_expenses Sure, if your pizza is frozen and consumed in another period, your books will not reflect reality, but so what, when talking about the very basics of accounting you offset that misrepresentation of a simple example by gaining an important pedagogic benefit! Which one, th…

Perhaps this is obvious to you, but I don't see what I'm gaining by doing this. My inventory management system will have different things unless I'm also recording these pizzas in there for the day. And it will show my inventory valuation as fluctuating when I do things like lunch or dinner for the team. It really seems useless to me when running the business.

Re: Double-entry bookkeeping as a directed graph

#277

Everyone should do their own accounts. I've been doing it for over 12 years and I'm so glad I've kept up with it. I don't bother keeping my ledger immutable, though. The point about immutability is that whatever happened is immutable (because it's in the past; it already happened!) and the ledger should just reflect that. So if I somehow made a mistake in my ledger I just correct it. I keep my ledger in git so that d…

Great idea to treat of personal finances like a business. Also makes a great source of data for stats.

Can you share more on the system you've come up with? In what format do you store the data? Do you store files per account, or per day, etc.? Do you have a CLI helper to quickly read, write, edit the files? Maybe you can even share a demo repo?

Re: Double-entry bookkeeping as a directed graph

#278
post #253

Earlier quoted context omitted.

> If you spend $X on sheep, you credit $X where? Debit it from where? You debit your 'sheep' account (maybe called sth like inventory) and you credit your cash account, or a liabilities towards suppliers account. Your equity stays constant in either case (no profit or loss impact), if you paid cash you've swapped X worth of cash for X worth of sheep, otherwise your liabilities went up by X. When they die, you debit s…

Thank you. I really appreciate that. It still feels exactly the opposite of what I thought a credit and debit were. Surely when you add sheep, you credit the sheep account and debit the cash. I get it. It's just a shift.

Yeah, best not to think of any semantics wrt to the words debit and credit. Debit is left-hand side, credit is right-hand side, and just remember the rules how they work :)

Re: Double-entry bookkeeping as a directed graph

#279
post #107

Earlier quoted context omitted.

Negative numbers have no place* in accounting, and people need to stop thinking "oh, credits are just negative numbers" and hopelessly confusing themselves and others by putting nonsensical signs on an unsigned magnitude of flux. * you can actually think of oddball reasons you might consider a "negative credit/debit", but it's more akin to something like a negative mass in physics

I tried using John Wiegley's Ledger, which uses negative numbers. Everything was great about Ledger except for that part - I just couldn't wrap my head around it.

Yeah, I had basically the same problem with it.

Re: Double-entry bookkeeping as a directed graph

#280
post #255
post #226

Earlier quoted context omitted.

> Money appeared. Lemonade disappeared. I want to see the corresponding +$5 and -$5. If I understand your comment correctly, where you're getting confused is, you're reading Current Account (Assets) to mean your inventory of lemonade. What they actually mean in this case is money moved from Income to your Assets (e.g. your cash register). That's why assets went up in this example. Of course for your lemonade business…

Thanks for moving this along. I knew beforehand that I will always get Credit and Debit wrong, but now I guess I can add Income and Assets to that. > What they actually mean in this case is money moved from Income to your Assets (e.g. your cash register). Usually when people say 'moved', it implies a decrease in one place and an increase elsewhere, and yet: > 1. You got income and your assets (your amount of cash) bo…

> Usually when people say 'moved', it implies a decrease in one place and an increase elsewhere, and yet

Yeah, I'm with you there. Personally I think this would be simpler if accounting just used negative numbers instead of a credit and debit side. That said, it's not super complicated. It's all derived from the accounting equation (explained well in this comment [1]):

Equity + Income + Liabilities = Assets + Expenses

Any transaction you do, needs to maintain that equation. That means that the changes either need to add to zero on one side or need to add to the same on both sides.

- E.g. in the example I'm selling lemonade: I'm increasing my cash (an asset, so on the right side) by $5, so I need to also increase the left side by the same, meaning an increase of $5 in the Income account.

- Or let's say I'm buying more lemons for my business. My cash (asset) goes down, but my inventory (also asset) goes up by the same amount.

- If I bought those lemons with my credit card instead, my inventory (asset) would go up and my liabilities would go up by the same amount.

In all cases the equation still holds after the transaction.

----

NB

You could construct an alternative way of accounting where the equation looks like this: Equity + Income + Liabilities + Assets + Expenses = 0

In this world, moving money would indeed align better with your intuition. E.g. selling lemonade would be -5 Income and +5 Assets (going from income to assets). That's for instance how Beancount does it [2]. Note that that also means that Equity, Income and Liabilities will now (generally) be negative numbers.

[1] https://news.ycombinator.com/item?id=39992035

[2] https://beancount.github.io/docs/the_double_entry_counting_m...

Post reply on HN