Double Entry Accounting for Developers • Hacker News Board

Re: Double Entry Accounting for Developers

#181

Post by cm2187 » Tue, Jul 28, 2020, 1:13 PM 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…

True. Though accounting in general is rocket science. You just need to look at the thickness of the accounting standards book [1]. As soon as you are looking at a large group with several levels of consolidation spanning jurisdictions with different accounting standards and doing any operation that is non trivial, the accounting treatment becomes a minefield. Where I work we have a team dedicated at looking at thorny accounting issues. Outside of that team, I don’t think anyone in the organisation (including the financial reporting dept) can pretend to really understand everything.

[1] http://a1.amlimg.com/ODhlOTU0NjZkODUxYWU1OTAwOWUwYjg3YmM0OGV...

Re: Double Entry Accounting for Developers

#182

Post by tgb » Tue, Jul 28, 2020, 1:13 PM UTC

buyx wrote: post #172

inopinatus wrote: post #166

Earlier quoted context omitted.

It doesn’t quite. You’ll also need to consider allocations and accounting for tax (sales and income), depreciation, transaction fees, warehousing, shipping revenue and expenses, revenue and expense recognition, discounts, returns, overpayments, prepayments, futures, chargebacks, refunds, credit notes, invoicing, subscriptions, subsidies, tariffs, reconciliation, adjustments in the current financial year, adjustments…

I specifically stated it was an unsophisticated example. GP wanted to know what happens with the "simplest transaction" when he buys a banana.

Yeah, exactly. The first or second example in any explanation should be buying a banana that you immediately eat. That way the reader sees that an "account" doesn't have to be a bank account nor even a collection of physical goods that exist, it's just a virtual bucket made to keep track of certain transactions. Until I figured that out, double-entry made no sense at all. This is all exacerbated by the common "Assets = Liabilities + Equity" equation which hides expenses entirely. All of this is, of course, a problem about pedagogy in the quick guides found all over the internet. (Including the one linked to here, though the second example is at least an expense but not in the way that would enlighten a beginner.)

Re: Double Entry Accounting for Developers

#183

Post by dragonwriter » Tue, Jul 28, 2020, 1:15 PM UTC

lisper wrote: post #108

wrycoder wrote: post #103

Earlier quoted context omitted.

I’ve found the best way is to remember the phrase, “Debits come in and credits go out.” Let’s say you have a bank account. Your view of that account is opposite from the bank’s view. You have $100 cash. That’s an asset from your POV, and it carries a debit balance on your books - when you received it, the cash “came in”. You walk into the bank and deposit it. The cash goes out of your books, but an asset (the increas…

> Debits come in and credits go out. That is the complete opposite of common usage. When I get a credit on my credit card statement, it means money is coming in to me. When I get a debit on my debit card, it means money is going out from me. It's not rocket science, or at least it shouldn't be. And yet somehow accountants have managed to turn it into something even more confusing.

> > Debits come in and credits go out.

> That is the complete opposite of common usage.

Nah, it's exactly the usage you are used to from statements you get.

> When I get a credit on my credit card statement, it means money is coming in to me.

When you get a credit card statement, it's a statement of the portion of your account in the card issuer’s books.

If you were keeping books for the card, they would be mirror images of the bank’s books.

Re: Double Entry Accounting for Developers

#184

Post by cm2187 » Tue, Jul 28, 2020, 1:15 PM UTC

dom_hutton wrote: post #140

keegancsmith wrote: post #136

Earlier quoted context omitted.

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.

No accounting in the French general high school curriculum. And I can’t see it being introduced (it would be seen as an unacceptable intrusion of capitalism in education).

Re: Double Entry Accounting for Developers

#185

Post by wrycoder » Tue, Jul 28, 2020, 1:20 PM UTC

lisper wrote: post #108

wrycoder wrote: post #103

Earlier quoted context omitted.

I’ve found the best way is to remember the phrase, “Debits come in and credits go out.” Let’s say you have a bank account. Your view of that account is opposite from the bank’s view. You have $100 cash. That’s an asset from your POV, and it carries a debit balance on your books - when you received it, the cash “came in”. You walk into the bank and deposit it. The cash goes out of your books, but an asset (the increas…

> Debits come in and credits go out. That is the complete opposite of common usage. When I get a credit on my credit card statement, it means money is coming in to me. When I get a debit on my debit card, it means money is going out from me. It's not rocket science, or at least it shouldn't be. And yet somehow accountants have managed to turn it into something even more confusing.

Your checking account is a liability from the bank’s POV.

Your credit card account is an asset from Visa’s POV. And a liability from your POV.

When Visa refunds that fee, it reduces their asset. And on your books, it reduces your liability.

A debit on your books is a credit on the counterparty’s books. A plus on your books is a minus on the counterparty’s books.

Re: Double Entry Accounting for Developers

#186

Post by kgwgk » Tue, Jul 28, 2020, 1:20 PM UTC

sago wrote: post #179

kgwgk wrote: post #164

Earlier quoted context omitted.

Yes, balancing is important. That’s why I’d prefer to end with assets that make sense in the balance sheet (or maybe you're happy to ignore balance sheets and don't want meaningful numbers?). I don’t see what do you gain by making the assets negative. Believe it or not, I’ve seen financial accounts quite more complex than two lines (and they never included those CR/DB annotations in the balance sheets or income state…

This has been an interesting conversation with several people. I am really surprised how much negative numbers are confusing or interpreted as my idiosyncrasy. > I’ve seen financial accounts quite more complex than two lines Definitely. For hundreds of years the convention has been columns. Credit values in the right-hand column, debit values in a left-hand column. The column is the label of which type of money it is…

I have no problem with negative numbers.

But most people would find your idea of using negative numbers for assets rather idiosyncratic.

It's more natural to say that the assets of Goldman Sachs are $1trn than to say that they are -$1trn, for example.

Re: Double Entry Accounting for Developers

#187

Post by everlost » Tue, Jul 28, 2020, 1:21 PM 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…

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

This is the non-intuitive part for me. Everything else seems logical. Why would you debit an asset when it increases?

Re: Double Entry Accounting for Developers

#188

Post by dragonwriter » Tue, Jul 28, 2020, 1:24 PM UTC

gowld wrote: post #41

bdowling wrote: post #20

Earlier quoted context omitted.

> I mean, this is just....wrong. It's beyond wrong. The developer here is redefining established accounting terms because he doesn't like their inconsistencies.

> 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?

There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.)

> Established accounting terms are from 500 years ago when people had trouble with subtraction.

People still have trouble with substraction compared to addition, especially with large numbers.

Re: Double Entry Accounting for Developers

#189

Post by wrycoder » Tue, Jul 28, 2020, 1:27 PM UTC

kgwgk wrote: post #116

lisper wrote: post #108

Earlier quoted context omitted.

> Debits come in and credits go out. That is the complete opposite of common usage. When I get a credit on my credit card statement, it means money is coming in to me. When I get a debit on my debit card, it means money is going out from me. It's not rocket science, or at least it shouldn't be. And yet somehow accountants have managed to turn it into something even more confusing.

Common usage has turned the terms into something confusing. It's not the accountants fault. Your credit card is linked to an account in someone else's books. They opened that credit account for you.

If you want to track the bank account on your own books, what they call a debit, you call a credit. Ït’s a mirror image.

Debits come in to an entity, credits go out.

Re: Double Entry Accounting for Developers

#190

Post by wrycoder » Tue, Jul 28, 2020, 1:39 PM UTC

everlost wrote: post #187

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…

> Rules: Left side of equation: Increase in an asset: debit. Decrease in an asset: credit. This is the non-intuitive part for me. Everything else seems logical. Why would you debit an asset when it increases?

Because an asset account carries a debit balance.

Debts aren’t good or bad.

Just remember: “debits come in, credits go out”.