Live data from Hacker News

Double Entry Accounting for Developers

django-hordak.readthedocs.io

141–150 of 237 posts

Re: Double Entry Accounting for Developers

#141

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…

If the only thing required to untwist the system is to switch the sign of everything on the liabilities side maybe it wasn’t so twisted after all.

At least you have the good taste of keeping assets positive, unlike other people. :-)

Re: Double Entry Accounting for Developers

#142
post #38

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…

The operation performed by debit/credit depends on the classification of the accounts. Accounts are listed traditionally with Assets on the left, and Liabilities and Equity on the right. A debit to a Liability account is a minus, and a credit is a plus, but it's the other way around on the asset side, where a debit is a plus, and a credit is a minus. (This kind of thing happens when English mugs other languages - Ita…

> The operation performed by debit/credit depends on the classification of the accounts.

OP has chosen a consistency in the operation of debit+credit sign and applied a 'display adjustment' to implement the classification. This actually sounds like a lower entropy way to remember it -- no left hand/right hand stuff, just 'There two account types are sign reversed on display'. But it will confuse anyone who isn't indoctrinated to the convention, but one could argue that it is these various conventions that make double entry seem arcane in the first place!

Re: Double Entry Accounting for Developers

#143
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…

The stumbling block for me learning it was understanding how to record the simplest and most common transactions like buying a banana. Surprisingly many explanations only use examples like paying your home mortgage where the credit and debit side of things are clear. But then they never tell me about where on earth does my banana go as a credit since I'm not stockpiling bananas to later sell. Even though that use case is almost all of my transactions!

Re: Double Entry Accounting for Developers

#144
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.

It's wrong in the sense that anyone who's studied standard accounting will look at your books and consider them to be incorrect. This is important if you want to share your books or reports with your local tax office, who will begin investigating you for committing tax fraud. It's the same reason why no one fixes the HTTP "Referer" header typo. You can, but if you do then you'll have difficulty communicating with the…

> look at your books

I think OP is encoding the sign-reversal internally though, right? It "displays" the two incorrectly classified account types exactly per the standard convention instead of re-applying the convention at every operation. All reports would follow the 'Classic' conventions. At least that was my reading!

Re: Double Entry Accounting for Developers

#145
Accountant here. This article is just wrong. You could memorize debit/credit rules but when dealing with non-finance persons, I avoid mentioning debit/credit as it gets confusing and generally its not needed anyway. Here's how I would explain basic accounting (income statement is ignored for simplicity).

Every transaction has two legs: what it is and whose it is. That is the basis of the accounting equation: assets (what) = equity (mine) + liabilities (someone else's). An increase in assets must be balanced with an increase in either equity or liabilities, and vice versa.

Re: Double Entry Accounting for Developers

#146
post #128
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 ledger-cli (upon which beancount is based) immediately useful. However, since you mentioned Emacs, I should say that I use ledger-mode in Emacs to add entries. But I do most of my reporting directly on the command line.

Re: Double Entry Accounting for Developers

#148
post #143
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…

The stumbling block for me learning it was understanding how to record the simplest and most common transactions like buying a banana. Surprisingly many explanations only use examples like paying your home mortgage where the credit and debit side of things are clear. But then they never tell me about where on earth does my banana go as a credit since I'm not stockpiling bananas to later sell. Even though that use cas…

To an expense account.

Re: Double Entry Accounting for Developers

#149
post #143
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…

The stumbling block for me learning it was understanding how to record the simplest and most common transactions like buying a banana. Surprisingly many explanations only use examples like paying your home mortgage where the credit and debit side of things are clear. But then they never tell me about where on earth does my banana go as a credit since I'm not stockpiling bananas to later sell. Even though that use cas…

If your banana is for consumption and you pay cash: Then debit Food Expenses (decrease equity) and credit Cash (decrease assets). Accounting equation is balanced.

If your banana is for resale and you pay cash: Credit Cash (decrease assets) and Debit Trading Stock (increase assets). Accounting equation is balanced.

If your banana is for consumption and you buy it on credit from your supplier: Credit Loan account (increase liabilities). Debit Food Expenses (decrease equity). Accounting equation is balanced.

If your banana is for resale and you buy it on credit: Debit Trading Stock (increase assets). Credit Loan account (increase liabilities). Accounting equation is balanced.

If your banana is for resale and it spoils before you sell it: Credit Trading Stock (decrease assets) and Debit Spoilage Expenses (decrease equity). Accounting equation is balanced.

If your banana is for resale and you sell it [this one I'm a bit rustier on, it's been 25 years, but I'm pretty sure it's correct]: Debit cash (increase assets). Credit Sales income (increase equity). ALSO Debit Cost of Sales (an expense, so decrease equity). Credit trading stock (decrease assets). Accounting equation is balanced. (Your Gross Profit is reflected in Sales minus Cost of Sales).

Granted, these are unsophisticated examples, and based solely on decades-old high school-level accountancy, but I think your banana example should be covered here.

Re: Double Entry Accounting for Developers

#150
post #8

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…

Even bullet 4 has assets and expenses multiplied by -1. Completely .... wrong. Maybe this might work for a bank where assets and liabilities are sort of flipped from a non-bank business?

They’re not flipped. From a bank’s point of view, any money they hold on your behalf is a liability. Your bank statement is an extract from their books. When they take a fee, it’s a debit on your statement, because it’s a credit to revenue on theirs.
Post reply on HN