Double Entry Accounting for Developers • Hacker News Board

Re: Double Entry Accounting for Developers

#131

Post by buyx » Tue, Jul 28, 2020, 9:46 AM UTC

Accountancy is(was?) widely taught in South African high schools. It was certainly quite common in the 1990s.

I found it quite amusing when I realised that double-entry isn’t widely understood around the world, a realisation I came to after I first encountered one of many confusing “accounting for developers” posts on HN.

It was quite easy for us 13 year olds to grasp:

Assets=owners equity +liabilities (accounting equation) A=O+L

Rules: Left side of equation: Increase in an asset: debit. Decrease in an asset: credit.

Right side of equation: Increase in liabilities: credit Decrease in liabilities: debit

Increase in owners equity: credit Decrease in owners equity:debit

Expenses decrease equity, income increases equity. Capital increases equity. Drawings decrease equity.

For every debit, there must be a credit. Every transaction fits into this framework, and every transaction must balance the accounting equation.

Your bank statement appears to be reversed, because it’s written from the perspective of the bank: for them, a deposit by you increases their liability to you (a credit). Similarly when you owe them money, it’s an debit, since from the bank’s perspective, your debt is an asset to them. (Bank reconciliation is another thing we did in school.)

This really isn’t rocket science.

Re: Double Entry Accounting for Developers

#132

Post by kazinator » Tue, Jul 28, 2020, 9:56 AM UTC

racecar789 wrote: post #74

kazinator wrote: post #67

That's the silly, confusing view of accounting. Here is the smart view: 1. The sum of all accounts is zero: that's the fundamental equation. Nothing about assets, liabilities or equity. 2. A transaction updates at least two accounts, by applying deltas to them. The sum of the deltas is a transaction zero. Because of that (1) continues to hold. 3. Accounts which represent outside interests in the business run negative…

#1 and 2 are generally correct. Personally, I would remove the quote "nothing about assets, liabilities or equity". Accounting is "all about" those accounts. #3 couple edits: Change "the equity goes down by $1000" to "either equity or liabilities will increase by $1000". Equity will either remain the same or increase when a business obtains $1000 out of thin air. Change "the loan account goes down by $1000" to "the l…

Though in accounting you have to be clear about what you have versus what you owe, and transactions must target the correct accounts in order to make sense, there is no need to befuddle the fundamental equation with those details. It is much clearer mathematically to have the fundamental equation be "all accounts always add to zero". That's it; no mention of their "type". Likewise, the increments/decrements in a transaction just have to add to zero.

This is the same as conservation laws in physics; e.g. integral over a closed path over a conservative field. Or the Kirchhoff voltage law (sum of voltages around an electric circuit is zero).

Debit/credit accounting is like designing a circuit in which for some silly reason we decided to mix conventional current and electron current! Oh, this is a liability resistor, so we use electron current, but this is an asset capacitor, so we use conventional current. The circuit law then doesn't add to zero, unless you remember which elements need to have their sign flipped, and you end up with strange rules like equity volages equal asset voltages minus liability voltages.

Can you imagine doing such a thing when designing a device with hundreds of parts? Yet, big ledgers can likewise have hundreds of accounts. Then a corporation needs a small army of accountants to keep a simple thing straight.

It's not just the adding to zero that is crystal clear, but the polarities of the accounts. When I see a negative balance account in the ledger, I have a good idea that it's an equity/liability account just from the balance alone. Minus means owing, plus means having: very clear.

Re: Double Entry Accounting for Developers

#133

Post by kgwgk » Tue, Jul 28, 2020, 10:04 AM UTC

captainmuon wrote: post #127

I think I understand the mechanics of double entry bookkeeping, but what I find confusing about it is that it is the redundancy. People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice. Also you get a lot of "fictious" or virtual accounts that don't correspond to concrete piles of cash or bank accounts. It seems much easier t…

> People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice.

That's like saying that check digits in credit card numbers detect errors that only exist in the first place because we entered more digits. Or that checking the md5sum after downloading a binary file detects errors that only exist in the first place because we downloaded two files instead of one.

Re: Double Entry Accounting for Developers

#134

Post by [deleted] » Tue, Jul 28, 2020, 10:05 AM UTC

kgwgk wrote: post #133

captainmuon wrote: post #127

I think I understand the mechanics of double entry bookkeeping, but what I find confusing about it is that it is the redundancy. People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice. Also you get a lot of "fictious" or virtual accounts that don't correspond to concrete piles of cash or bank accounts. It seems much easier t…

> People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice. That's like saying that check digits in credit card numbers detect errors that only exist in the first place because we entered more digits. Or that checking the md5sum after downloading a binary file detects errors that only exist in the first place because we downlo…

[deleted]

Re: Double Entry Accounting for Developers

#135

Post by fauigerzigerk » Tue, Jul 28, 2020, 10:18 AM UTC

bdowling wrote: post #64

gowld wrote: post #41

Earlier quoted context omitted.

> It's beyond wrong. How so? > The developer here is redefining established accounting terms because he doesn't like their inconsistencies. Yes. What's wrong with fixing inconsistencies? Established accounting terms are from 500 years ago when people had trouble with subtraction.

> What's wrong with fixing inconsistencies? In general, nothing. It's just not the software developer's job. If the accounting profession decided to change certain terms to fix inconsistencies, that would be fine.

I think that's missing the point of the original article. Of course you have to present a view of the accounts that is consistent with accounting rules and conventions. But that doesn't necessarily mean you have to adopt that external view as an internal model for any software you're writing.

Re: Double Entry Accounting for Developers

#136

Post by keegancsmith » Tue, Jul 28, 2020, 10:20 AM UTC

buyx wrote: post #131

Accountancy is(was?) widely taught in South African high schools. It was certainly quite common in the 1990s. I found it quite amusing when I realised that double-entry isn’t widely understood around the world, a realisation I came to after I first encountered one of many confusing “accounting for developers” posts on HN. It was quite easy for us 13 year olds to grasp: Assets=owners equity +liabilities (accounting eq…

Also surprised by all these articles. But your point made me realise that most people didn't do accounting in high school like I did (also a South African). I wonder what some other uncommon high school curriculums from other parts of the world are.

In retrospect I wish what we learnt in High School was more focussed on personal finance than essentially constantly doing double entry data capture.

Re: Double Entry Accounting for Developers

#137

Post by eginhard » Tue, Jul 28, 2020, 10:20 AM UTC

neolog wrote: post #128

braho wrote: post #121

Earlier quoted context omitted.

Not only is Martin Blais' explanation very helpful, his software, Beancount, is also very suitable for any personal finance projects, especially if you have a background as Developer. Personally, I combine beancount with fava and find it much better than e.g. GnuCash.

Is beancount the kind of tool that's mostly useful if you put a lot of time into it, like Emacs? Or is it immediately useful with even small investments of time?

I found it easy to get started with the very basics (e.g. recording of simple transactions) and I'm just reading up more over time on how to handle more complex things like splitting expenses with a partner or investments. Thanks to Python I was also able to customise my setup almost right away. There is also an Emacs mode for those who have already made that investment.

Re: Double Entry Accounting for Developers

#138

Post by ecaradec » Tue, Jul 28, 2020, 10:27 AM UTC

captainmuon wrote: post #127

I think I understand the mechanics of double entry bookkeeping, but what I find confusing about it is that it is the redundancy. People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice. Also you get a lot of "fictious" or virtual accounts that don't correspond to concrete piles of cash or bank accounts. It seems much easier t…

I didn't see the purpose of it when I got told of the principle at school. The supposed control of error detection feel like a very vague benefit to me. Especially now with computers. Actually hashing of the chain of values would probably be more secure (like bitcoin yes).

However, I think the real value in double entry accounting is that it not only represent money you have but also things you own: If you buy a pen, you have less money, but you have an extra furniture pen and your accounting can reflect that. It can also reflect the loss of value of the pen over time.

It is also useful if you get in debt to buy something: you transfer money from a debt account to your current account, you buy the thing you wanted to buy and appropriatly report the value of what you own in accounting. You now have a thing, and a debt to be repaid in whatever term was agreed.

It's also very useful as a tool of control for state. All exchanges you have with other entities are recorded in a separate account. It's possible to take that account and check that the other entity accounting book match exchanges they have with you.

Re: Double Entry Accounting for Developers

#139

Post by rbg246 » Tue, Jul 28, 2020, 10:53 AM UTC

junkrat002 wrote: post #102

goat_whisperer wrote: post #4

From the site: "I found the core explanation of double entry accounting to be confusing. After some time I distilled it down to the following: "Debits decrease the value of an account. Always. [1] Credits increase the value of an account. Always. [1] "[1] (1, 2) This is absolutely not what accountancy teaches. You’ll quickly see that there is a lot of wrangling over what account types get increased/decreased with a d…

Ex-finance SWE here. I closed the article after that part. If you don't understand accounting and read this, you'll only be more confused when you learn how accounting actually works. For the most part, devs in general should not be teaching accounting. There's a reason that it is so challenging to earn a CPA.

It's not that hard to qualify, it's the equivalent of three years software engineering experience with some side study.

It's more a case of someone who has one year of writing JavaScript shouldn't be writing on the theory of software development.

Re: Double Entry Accounting for Developers

#140

Post by dom_hutton » Tue, Jul 28, 2020, 10:53 AM UTC

keegancsmith wrote: post #136

buyx wrote: post #131

Accountancy is(was?) widely taught in South African high schools. It was certainly quite common in the 1990s. I found it quite amusing when I realised that double-entry isn’t widely understood around the world, a realisation I came to after I first encountered one of many confusing “accounting for developers” posts on HN. It was quite easy for us 13 year olds to grasp: Assets=owners equity +liabilities (accounting eq…

Also surprised by all these articles. But your point made me realise that most people didn't do accounting in high school like I did (also a South African). I wonder what some other uncommon high school curriculums from other parts of the world are. In retrospect I wish what we learnt in High School was more focussed on personal finance than essentially constantly doing double entry data capture.

I suspect accounting is a topic common in commonwealth countries curriculum (heh no pun intended) - Australia included it as well.