Live data from Hacker News

Double-entry bookkeeping as a directed graph

matheusportela.com

321–330 of 388 posts

Re: Double-entry bookkeeping as a directed graph

#321

Earlier quoted context omitted.

“If everyone is incompetent, all software will be bad”. Got it, thanks.

You were the one advocating for incompetence.

That was not the incredible burn you hoped for, because it kinda suggests a lack of consideration for the practical design of a modern computer, in which memory is tiered in orders of magnitude of time latency from CPU registers on down through on-die caches and so forth, each tier effectively acting as a local cache for the next level. Writes are super expensive and bust cache lines and coherency all the way down to main memory and in many applications touch persistent storage and even introduce network latencies in distributed systems.

By contrast, ALUs are stupendously well optimized for the baseline computational task of adding up integers.

The difference between nanoseconds and milliseconds is vast. It is consequently very often cheaper to recalculate a sum using data already in cache memory than to save it and later fetch it, or (even worse) to read a value precalculated by a neighbouring computer.

Furthermore, the distinction only matters for accounting systems at high scale. For the average small business accounting, it is de minimis: your computer performs more computation when resizing a browser window than it does in recalculating an account balance from scratch.

Re: Double-entry bookkeeping as a directed graph

#322
post #287

Earlier quoted context omitted.

Sure, but if you want to keep your terminology consistent with the math, you would then have to make a distinction based on the types of the accounts involved in a journal entry. E.g, this would be correct: increase bank increase equity but this would be incorrect: increase bank increase receivables If all numbers are positive then there would be no way to check whether the journal entries balance out without conside…

> you would then have to make a distinction based on the types of the accounts involved in a journal entry That's right. The distinction is based on whether the account represents an asset or a liability. > increase bank > increase receivables You would have to define what you mean by "bank" in order for this to make sense. But in general, receivables represent money that a company is owed from orders that have not y…

Yup, this is the same way of thinking I described here: https://news.ycombinator.com/item?id=39994335

Instead of grouping together accounts into credit-normal and debit-normal, to make things balance, I think it’s more intuitive to group accounts by usage and use negative numbers.

Asset and Liability accounts appear on a Balance Sheet and are called State accounts. State accounts track the current state of your net worth.

Income and expense accounts appear on an Income Statement and are called Change accounts. Change accounts since they track why your net worth changed.

Re: Double-entry bookkeeping as a directed graph

#323
post #308

Earlier quoted context omitted.

One way to think about is you always "credit" the source of the money. If you get money from somebody you "credit" them for giving you the money. You say "I must give you credit for having done this". If money goes into your bank-account you don't credit your bank-account because money didn't come from there it went there. If you don't credit the bank account you must be doing something else and that is called "debit…

Thanks this explanation helps. Does that mean that from the banks perspective my deposits are a liability?

Yes! Because you can remove your deposits from the bank and they also have to pay you interest on that balance. Your mortgage is an asset to the bank for the opposite reasons.

Re: Double-entry bookkeeping as a directed graph

#324
post #48
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/ ).

Every time I look at accounting, the different kinds of accounts baffle me. I can never keep straight what each kind of account is used for, or which ones have positive credits and which ones have negative credits. As far as I can tell, the point is to double the amount of work in the hopes of catching certain kinds of errors. Which makes sense when you have humans making the entries and humans doing the arithmetic.…

The reason isn’t to double the amount the work to catch errors. storing both sides genuinely stores extra metadata about the transaction that is not captured by only storing it once.

In double-entry, you’re tracking two different things: - Your current net worth. These are tracked in State accounts (Asset and Liability). - The reasons your current net worth changed. These are tracked in Change accounts (Income and Expense).

Say $5 enters your bank account, that’s recorded as an increase in an Asset account. Whether your net worth changed or not depends on the reason. There’s lots of reasons that could have happened, and that’s recorded as the second entry: - Took out a loan: increase in Liability (no net worth change) - Got paid back for a loan: decrease in Asset (no net worth change) - Sold something: increase in Income (net worth did change) - Got a refund: decrease in Expense (net worth did change)

I agree that re-engineering accounting is necessary for software engineers to build financial systems. I think it’s time to ditch credits and debits and instead deal in State and Change accounts with negative numbers.

PS I go more into it here: https://news.ycombinator.com/item?id=39994335

Re: Double-entry bookkeeping as a directed graph

#325

Double-entry bookkeeping is very easy to understand once you ditch the ridiculous "credit" and "debit" terminology. Essentially, the goal is to keep the accounting equation true at all times. The equation is: Equity = Assets - Liabilities. Eventually, earnings (Income - Expenses) will become part of equity, so splitting that out, you have: Equity + Income - Expenses = Assets - Liabilities. Rearranging to get rid of t…

'Double-entry bookkeeping is very easy to understand once you ditch the ridiculous "credit" and "debit" terminology.' I love it, let's do it! Thank you this is very helpful. The whole credit/debit terminology usage here is incredibly confusing to someone who hasn't studied accounting and many of the comments and replies to people who are confused are, while technically correct, simultaneously, unhelpful - to those no…

I think the fundamental problem is the traditional accounting equation:

  Assets + Expenses = Liabilities + Equity + Income
We try to group the accounts by left and right side and find a common term for them (credit-normal and debit-normal). But it’s really hard to come up with an intuitive answer for why Assets and Expense should be on one team, and why the rest should be on the other team. So we just pick some team names and say shut-up-and-calculate.

What if we re-arranged the equation to:

  Assets - Liabilities = Income - Expenses
The accounts on the left side track your net worth. The accounts on the right side track why net worth changes. What should be the names for the two sides? I call them State and Change.

You can then ditch credits and debits and ask - what is the impact of this financial transaction on my net worth? The equation will tell you which accounts should go up and go down using positive and negative numbers.

I go more into how this works here: https://news.ycombinator.com/item?id=39994335

Re: Double-entry bookkeeping as a directed graph

#326
post #126

Earlier quoted context omitted.

Cash account is credited $1000, and Gifted (or Cash_Gifted) account is debited $1000.

That method only works if money can be created out of thin air, and also destroyed. The grandparent comment was pretty clear that money cannot be created out of thin air, nor can it be destroyed. A curious contradiction. How do we resolve it?

While money can’t be created or destroyed (unless you run a central bank…), value can be. Ledgers always have a specific perspective, and that perspective can assign a different value to something than someone else.

In the case of gifting something, from the perspective of the gifter, they destroyed some value they had on their books and got nothing of value in return. There’s an account type for tracking why your net worth decreased - Expense accounts. The giftee received value and they have an account to track why their net worth increased - Income accounts. If value was objective, then the net worth decrease on one side would exactly equal the net worth increase on the other.

With something like cash, the unit of account and the store of value are the same thing - so 100 USD objectively the same value in everyone’s ledger. But say you were gifted a painting. The gifter may have valued this painting at 100 USD, while the giftee actually thinks it’s worth 50 USD. If the gifter didn’t tell them the price, there would be no way of knowing they recorded different numbers. So in this transaction value was destroyed.

The same thing happens when you buy and sell things. Say the painting was sold instead of gifted, then the difference in what the buyer and seller thought the painting was worth is value that was created and destroyed. Each person’s net worth would go up or down depending on whether they thought the painting was a bargain or overpriced. When providing services, value is created at the moment of usage and a ledger will track the creation of value in your landscaping business.

Re: Double-entry bookkeeping as a directed graph

#327
Not a fan of people changing the terminology used in a domain. It confuses people in the domain (accounting) and makes their lives just slightly more harder. Keep in mind, sometimes the software you write is pushed hard by the incompetent CIO that “wAnTs To ReDuCe ToOlS” or gets a kickback from the vendor. That person doesn’t have to deal with it on a daily basis but the poor workers have to deal with this shite software.

The impression of that poor software reflects poorly on the rest of us.

Re: Double-entry bookkeeping as a directed graph

#328
post #15

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…

Any time I've dealt with bookkeeping or accounting software where I find functionality like "Rebalance accounts" I become suspicious and wary. I know that the programmer has tried to be clever and keep running totals, versus calculating them the source transactions. There be dragons there.

imo, realistically you'll end up with both for payment-operations - just recalculating balances for accounts with millions of transactions also causes issues

Re: Double-entry bookkeeping as a directed graph

#329
post #15

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…

> 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. This is a bad design, please don't do this. The better design is to have header and detail tables: Header: TransactionID, Date, Description, (other fields as required, e.g., posting status, reconciliation status, etc)…

yes, that's the gnu cash implementation (also used by formance for example) - I don't love it tbh, yes you can add multiple postings under a single transaction, but.. if you look at one of those postings, or just the transaction in general you don't directly know which posting originates from what account, you have to sorta map it based on amounts

Re: Double-entry bookkeeping as a directed graph

#330
post #20

Earlier quoted context omitted.

Isn't having to replay every transaction in history to query current balance rather inefficient?

It's a trade off. Immutability is a big enough win to pay the price of a few extra CPU cycles. In practice it's very quick anyway. Computers are very good at adding numbers together (it's almost like it's what they were made for!). I keep all my accounts for over 12 years in one file and I still don't notice any delay when calculating balances etc. If it does become a problem then one solution is to take sums at some…

I mean, yes for personal accounts with a couple of thousand transactions - sure. But esp. in payments or in exchanges there can be accounts with millions of transactions a day. So you get a double-whammy - those are hot-accounts which also slow down the system, recalculating the balance for those accounts each time a transaction happens isn't an option
Post reply on HN