Live data from Hacker News

Double Entry Accounting for Developers

django-hordak.readthedocs.io

21–30 of 237 posts

Re: Double Entry Accounting for Developers

#21
Here's one for computer scientists: "Accounting for Computer Scientists" by Martin Kleppmann [1]. It was discussed on HN [2]. There have been several reposts of it since then, including one 8 months ago, but only the original got any discussion.

[1] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

[2] https://news.ycombinator.com/item?id=2298471

Re: Double Entry Accounting for Developers

#22
post #14
post #10

Earlier quoted context omitted.

I always felt that equation was confusing. Because then the sign has to be taught separately, or numbers have to have two columns (credit and debit) and you need to understand where each one is. assets + liabilities + equity = 0 Seemed much more general. Double entry just became: everything (transactions, whole companies) sum to zero. Then just one other little thing (where money comes from in a transaction is positi…

Your formula is not correct. If you want to do it that way, it should be assets - liabilities - equity = 0. Think of it this way. When you start a company, you invest $100. For the company accounting, that is $100 in the bank account/asset and $100 in equity. $100 - 0 - $100 = 0 Now you take a loan for $100. Now you have $200 in the bank account, a $100 liability, and $100 in equity. $200 - $100 - $100 = $0.

It is not incorrect. To make everything positive (and use the subtraction as you have) you need to have two different types of 'positivity' Credit and debit. And then you have to remember which things are subtracted and added so it gets back to balancing. That's why it gets so complicated.

Money in your bank account is _negative_. It is a _debit_ in your accounts (this is not my invention this is true). Your bank account statement is from the bank's perspective. The money came from you, so it is a credit from their perspective only. Try to submit your statutory accounts with 'bank credit' and you'll get in trouble! Your software or accountant will definitely flip it to become a debit!

Your transaction to start your account:

Equity: $100 (or $100CR)

Bank account: $-100 (or $100DB)

Loan:

Debt: $100 (or $100CR)

Bank account: -$100 (or $100DB)

Accounts:

Assets > Bank account: $-200 (or $200DB)

Liabilities > Debt: $100 (or $100CR)

Equity: $100 (or $100CR)

Re: Double Entry Accounting for Developers

#23
I learned double entry accounting. "Debits decrease and credits increase" is just one way to represent the numbers; I have also seen the other way around (where debits are positive). But more commonly, the presentation is such that debits increase the accounts on the left, and credits increase the accounts on the right. (Nevertheless, the explanation there does work.)

Some time ago (while I was bored in the accounting class), I invented "matrix accounting" (I was trying to invent something else, specifically, using complex numbers in accounting, which I concluded was impossible, but matrix math works). In this matrix accounting, "debits" and "credits" don't really exist and the presentations mentioned above are really just different eigenvectors. The accounting equation has this form:

   = 0
(Note that all of the components here are real, and not complex; also note that financial vector space is a kind of projective space.)

Re: Double Entry Accounting for Developers

#24
post #16

Can’t tell whether it’s intentional as part of this slightly modified approach, but under classic accounting the contribution in the first example would be equity not income. I’m glad more accounting software is out there but tbh as accountant I can’t see myself using this. The whole debit always decreases thing kills a core part of the mental framework I use to reason through more complicated scenarios. I guess that…

> >accountants don’t like negative numbers.

> That’s the first I hear of that

It might be more accurate to say that Western accounting evolved before the concept of negative numbers became widely accepted in the Western world. Negative numbers were invented (or "discovered", depending on your preferences in the philosophy of mathematics) in China, and from there spread to India, and from India to the Islamic world by the Middle Ages. But when Western mathematicians learnt about them from Arab/Islamic mathematics, there was a lot of philosophical pushback – at first, Westerners didn't think the idea was valid. The idea was rather alien to the Western philosophical tradition originating in Plato and Aristotle. It was only really in the 19th century that Western mathematicians overcame all their philosophical objections and embraced them wholeheartedly. And then it took even longer for the concept to spread from academic mathematics into other disciplines and general education. By then, a lot of the Western tradition of accounting and bookkeeping had already formed without any reliance on the concept of negative numbers. (The concept of "credit" and "debit" serves a somewhat similar function, but is not quite the same concept.)

And accountants do use negative numbers. But, maybe if modern Western accounting had developed in a culture that looked on negative numbers more positively (excuse the pun), they might use them much more than they do?

Re: Double Entry Accounting for Developers

#25
post #11
post #6

I kind of expected to see a good, pragmatic explanation of why double-entry accounting is useful, the kinds of mistakes it catches, etc... kind of weird to see almost no emphasis on the double-entry nature at all.

I agree: it catches entry errors, which is really handy in a system where you're hand-writing them twice. But if you're writing a computer system that's simply duplicating one entry from a human in two places in data store, is that "double entry"? is it useful? But the idea that you would want to reconcile one view with another independently reported one is super useful. (Almost every financial-oriented company build…

"debits and credits balance" is a very useful constraint to have in your system in order to maintain data integrity. Transactions can also get quite complex - think of a salaried payroll deposit - this is a transaction with 5-10 splits from various accounts. Even a typical ecommerce sale might have 4-5 when you include commissions owed, shipping, sales tax, etc.

Re: Double Entry Accounting for Developers

#27
post #10

I think the most important equation to understand about accounting is assets = liabilities + equity ROA, ROE, etc come from the above formula.

I always felt that equation was confusing. Because then the sign has to be taught separately, or numbers have to have two columns (credit and debit) and you need to understand where each one is. assets + liabilities + equity = 0 Seemed much more general. Double entry just became: everything (transactions, whole companies) sum to zero. Then just one other little thing (where money comes from in a transaction is positi…

Yeah. It's all left over from the fact that double entry bookkeeping is older than the use of negative numbers. Start with the rule that every account has to be positive and you get all of the inane rules.

CPAs are the OG Luddites, refusing to use negative numbers to make their jobs simpler and easier to understand.

Re: Double Entry Accounting for Developers

#28
post #21

Here's one for computer scientists: "Accounting for Computer Scientists" by Martin Kleppmann [1]. It was discussed on HN [2]. There have been several reposts of it since then, including one 8 months ago, but only the original got any discussion. [1] https://martin.kleppmann.com/2011/03/07/accounting-for-compu... [2] https://news.ycombinator.com/item?id=2298471

Yeah, Klepperman's is the best explanation I've read of accounting. (And I had a college course on the subject). The clarity of it reminds me of the classic "Calculus Made Easy" text.

In contrast, the article in this post is terrible. Tons of footnotes referring to exceptions. I feel like the author is trying to summarize a subject he doesn't understand himself.

Re: Double Entry Accounting for Developers

#29
Note to people looking for job security: there is a HUGE need for developers who understand finance. The fundamental problem is that most finance people can't speak the language of software development (the biggest problem I've seen is that finance people tend to be very poor at writing out a spec of what the software should do - they're much better at looking at a set of examples and then telling you if the calculations are right or wrong). Similarly, most software developers don't know enough about the intricacies of the finance world when building financial software.

I had a colleague who (over years of experience) got to be so good at teasing out requirements from the finance people that I called him "The Finance Whisperer". His skill at crossing the finance-software worlds was unparalleled, and he could command a large premium for this knowledge.

Re: Double Entry Accounting for Developers

#30
post #10

I think the most important equation to understand about accounting is assets = liabilities + equity ROA, ROE, etc come from the above formula.

I always felt that equation was confusing. Because then the sign has to be taught separately, or numbers have to have two columns (credit and debit) and you need to understand where each one is. assets + liabilities + equity = 0 Seemed much more general. Double entry just became: everything (transactions, whole companies) sum to zero. Then just one other little thing (where money comes from in a transaction is positi…

Think of it this way: Assets - Liabilities = Equity

If we deduct everything that we owe (Liabilities) from everything that we own (Assets), whatever is left belongs to the shareholders (Equity).

Post reply on HN