Live data from Hacker News

Double-entry bookkeeping as a directed graph

matheusportela.com

221–230 of 388 posts

Re: Double-entry bookkeeping as a directed graph

#221
post #16

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.…

I’m biased, but I hope my explanation[0] is more intuitive coming from a CPA.

[0]: https://www.winstoncooke.com/blog/a-basic-introduction-to-ac...

Re: Double-entry bookkeeping as a directed graph

#222
I see a lot of consternation about credits and debits and the nomenclature.

Something that makes this simpler to think about from a modern perspective is that accounting is older than the popular use of negative numbers. By a lot. If we were to invent accounting today, we'd probably use positive and negative accounts instead of debit and credit accounts.

Algebra over addition is second nature to us at this point, but it would not have been obvious to the average merchant in 1604, and even then, negative numbers were viewed quite poorly.

What is important is that there are always two sides to a transaction and that they are inverses of each other. This is all a credit and debit are. Inverse operations on a number.

Therefore, we can make a rule that a transaction balances when credit = debit. (aka we didn't invent money as debit + credit = 0, but remember that we didn't like negative numbers when this system was invented, so this last fact is more of a happy coincidence that happens to ALWAYS WORK, for some reason, rather than the goal).

What is then reasonable is to consider literal cash on hand to be the most positive (debit) kind of account there can be, and work backwards from there. If I want to handle an expense, then I need to invert the cash account somehow (credit it) and therefore have the opposite kind of entry for where the money went (debit it). So an expense account must have a generally debit (or positive) balance.

But where did the cash come from? Well that comes from income and I want the cash to be debit-ey so the place it came from must be credit-ey otherwise I risk writing a transaction that doesn't balance (equal zero). So then income accounts must generally be credit accounts rather than debit account (aka they hold a typically negative balance or are "credit normal").

What is really killer about this system, is it just so happens that every mundane transaction you could ever write will end up as balanced transactions and each of these possible transaction accounts end up having the same usual balance of credit or debit (negative or positive). I think that is just so elegant.

Re: Double-entry bookkeeping as a directed graph

#223

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…

Yeah, I think a more intuitive way is to replace credit and debit with State and Change as the pair of things in double-entry. It means that you don't have to swap meanings based on context and can use negative numbers intuitively.

State Accounts track your net worth

  Assets: what you own

  Liabilities: what you owe
Change Accounts track why your net worth changes

  Income: what you've earned

  Expense: what you've spent
The accounting equation that follows is ∆ State = ∆ Change:

  Assets - Liabilities = Income - Expense

Selling lemonade is +$5 Asset balanced by +$5 Income. If you substitute into the equation, it's: $5 Asset = $5 Income

Taking out a loan is +$10 Asset balanced by +$10 Loan. In the equation: $10 Asset - $10 Liability = $0.

In general, say you have a +Asset action, to balance the equation you can do it 4 ways:

  +Asset -Asset aka swapped for equal value

  +Asset +Liability aka took out a loan

  +Asset +Income aka sold something

  +Asset -Expense aka got a refund
I've left out Equity as a separate account type since you can just treat it mathematically as a Liability account.

This is the system we've implemented in our ledger API (https://fragment.dev)

Re: Double-entry bookkeeping as a directed graph

#224
post #206
post #160

Earlier quoted context omitted.

> A debit doesn't have some intrinsic meaning about the "flow of money". But it does. "Debit" is an English word with an established meaning in common usage. It means to take money out of an account. It is related to the word "debt" which is something that decreases the net worth of the debtor and increases the net worth of the creditor . If you overpay a bill, the (positive) difference between what you paid and what…

That's not entirely correct- or at least, it's more complicated than that. The question of whether a debit/credit increases/decreases an account has to do with the kind of account you're talking about. When I deposit money, it modifies two accounts at the bank: - the account which represents how much money they owe me - and the account which represents how much money they have on hand. The former is a liability, and…

The problem is that whether something is an asset or a liability depends on your point of view. If I have $100 in cash, that is an asset to me and a liability to the rest of society. If I have a $100 loan, that is a liability to me and an asset to my creditor. So there is no way to say whether something is an asset or a liability in an absolute sense. Every debt is an asset to the creditor and a liability to the debtor.

This has nothing to do with labeling transactions so that the labels conform to the common meanings of English words. When an account representing assets has its balance go up, that's a credit. When an account representing a liability has its balance go up, that's a debit. And vice versa. If I, say, draw down a line of credit for $100 and deposit the funds in my checking account, then from my point of view, my LoC should debited by $100 and my checking account should be credited for $100.

This makes sense regardless of how you think about the LoC. If you think of the available credit as an asset, then when you draw down the LoC the available credit balance goes down and it's a debit. If you think of the amount owed on the LoC as a liability, then when you draw down the LoC the amount owed goes up and it's still a debit.

> CREDIT mhink's account $100 (increasing liability)

No. This transaction does not increase liability in any absolute sense. It increases liability only from the bank's perspective. From your perspective, it increases assets.

Re: Double-entry bookkeeping as a directed graph

#225

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…

The purpose of the words "credit" and "debit" is the same purpose of the structure of double-entry bookkeeping: to make every statement unambiguous, no matter what order or context you put the words in. By replacing familiar verbs like "paid" and "earned" with the nouns "debit" and "credit", we can write sentences where the order of words doesn't change the meaning, and where we never need to figure out what tense (past, present, future) to apply.

To simply write that, "Bob's account has a credit of $12 and a debit of $7" is timeless. That sentence can go anywhere, and always be explicitly correct. It is context-free grammar: the same category that all programming languages belong to. Because a programming language is context-free, it can be perfectly understood (and translated) by a parser and compiler. Because statements using the nouns "credit" and "debit" are context-free, they can be perfectly understood as the data they represent.

> The "credit" and "debit" terminology is ridiculous because their definitions swap around depending on which account you're talking about, which is an utterly absurd (mis)use of language and the main reason people find this confusing.

On the contrary! Their definitions are always the same. They apply specifically to the account you are talking about, because they are that account: an account is a list of credits and debits.

The reason that people get confused is that we are used to using verbs like "paid" and "earned". When we use verbs, the data is the transaction, not the account. When we use the nouns "credit" and "debit", the data is the account, and not the transaction. Most people are introduced to these words with "credit card" and "debit card". That was the mistake, because cards are used for transactions, which is precisely the wrong context to use these words. It would have been much more clear to talk about "crediting cards" and "debiting cards".

Re: Double-entry bookkeeping as a directed graph

#226
post #193

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'm with you so far. > the goal is to keep the accounting equation true at all times Perfectly reasonable. > For example, you sell a lemonade for $5. You add $5 to Sales (Income) and add $5 to Current Account (Assets). And now you've completely lost me. Money appeared. Lemonade disappeared. I want to…

> 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 you might keep track of your lemonade as well (which I think is what you're talking about when you refer to assets). The lemonade sale would then lead to a decrease in your lemonade asset and and an increase in your expenses (cost of goods sold), so the right hand side of the equation balances.

So when selling lemonade there are actually 2 things happening:

1. Your income and your assets (your amount of cash) both increased. Income and Assets are on different sides of the =, so the equation still balances

2. Your lemonade assets decrease and you incurred the cost of that lemonade as an increase of your expenses. Those are both on the same side of the =, so the equation still balances.

Re: Double-entry bookkeeping as a directed graph

#227
post #164

Earlier quoted context omitted.

On the other hand some things in how accounting is traditionally done suffer from accounting predating a lot of "modern" math. 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 defin…

Then this would be one of those cases where working around a problem (the lack of negative numbers) actually resulted in a superior product. You don't want negative numbers because that would require the description of a category to change based on whether it is positive or negative. You wouldn't want to be changing "Assets" to "Liabilities" every time the number goes below zero. You don't need negatives in accountin…

> You don't want negative numbers because that would require the description of a category to change based on whether it is positive or negative

That's actually already how it works, the kind of inverse you use depends on if the account is credit-normal or debit-normal. You end up in the same place.

> Imagine showing negative revenue. That would be mostly useless.

Revenue is already credit instead of debit, which if you were consistent in using negative numbers, a negative revenue be completely correct (so you would want to sweat if revenue was a positive number). It's weird, but it lets your cash on hand be a positive number, which is just a necessary consequence of the system.

> Imagine how misleading it could be to show $0 in expenses last month, when in reality, you had $100 in expenses, but you subtracted $100 out because you returned some big purchase from last month and got a refund.

Wouldn't that be accurate? This would be a debit of 100 and a credit of 100 which nets a balance of 0. But individually you would see the transactions and could sum the credits and debits if you were so inclined.

Alternatively, contra-accounts exist if reporting these individually is material for some reason.

Re: Double-entry bookkeeping as a directed graph

#228
I recently wrote my own bookkeeping software based on a budgeting spreadsheet my wife found a long time ago and used for years. It wasn’t until reading this (and some of these comments and other references) that I realized it’s actually a disguised double-entry bookkeeping system. No wonder it works so well!

Re: Double-entry bookkeeping as a directed graph

#230

Earlier quoted context omitted.

The accounting equation is the right thing to think about. People want debit and credit to mean something more than they need to. My 100-level accounting instructor said it pretty succinctly: Debit means an entry in the left column. Credit means an entry in the right column. What a transaction means for the business depends on the accounts.

It sounds like your accounting instructor may have focused too much on implementation details (left/right), and too little on accounting principles. The terms debit and credit have meaning independent of their columnar position on a traditional ledger. I could create a ledger with the columns reverse or (shocking!) use a computer program with a data structure that doesn't encode the concept of left or right. I think…

The sheer amount of discussion this has created (both here and back in August, 2022, when you and I commented back and forth to each other in your link) validates my my instructor's philosophy to me. Concentrating on the accounts and the accounting equation, ignoring any "meaning" for the words debit and credit, results in the "right answer" without a lot of consternation.
Post reply on HN