Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Double Entry Accounting for Developers

django-hordak.readthedocs.io

Post reply on HN
Print view View original

81–90 of 237 posts

Re: Double Entry Accounting for Developers

#81

Post by juped »

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…

It's actually less wrong, but still wrong, to say the exact opposite (i.e., "Debits always increase and Credits always decrease").

Re: Double Entry Accounting for Developers

#82

Post by patmcc »

juped wrote: post #78
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…

This comment expressing confusion on this valiantly misguided OP seems like a good place to throw my standard explanation out into the aether to do neither readers nor myself any good. A transaction has two polarities, because it represents a flow of value. The credit side is the source, the debit side is the sink/destination/whatever. Let's temporarily pretend that every transaction hits exactly two accounts for the…

One minor "error" - depreciation only happens on capital assets, that should be a Pizza Expense.

Re: Double Entry Accounting for Developers

#83

Post by juped »

patmcc wrote: post #82
juped wrote: post #78

Earlier quoted context omitted.

This comment expressing confusion on this valiantly misguided OP seems like a good place to throw my standard explanation out into the aether to do neither readers nor myself any good. A transaction has two polarities, because it represents a flow of value. The credit side is the source, the debit side is the sink/destination/whatever. Let's temporarily pretend that every transaction hits exactly two accounts for the…

One minor "error" - depreciation only happens on capital assets, that should be a Pizza Expense.

Yeah, I guess eating pizza usually counts as opex.

Re: Double Entry Accounting for Developers

#84

Post by patmcc »

akgoel wrote: post #8
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…

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?

Banks and non-banks don't treat assets/liabilities in different ways in accounting - banks just engage in transactions most other businesses don't, as a normal matter of business.

For example - if you're holding someone's money for them, that's a liability - you have to pay it back some time. If someone owes you money, that's an asset - it's worth something. Banks use the cash from liabilities (people's savings accounts) to pay for assets (mortgages) and make money on the spread.

Re: Double Entry Accounting for Developers

#85

Post by sago »

mehrdadn wrote: post #76
sago wrote: post #72

Earlier quoted context omitted.

I suspect the misconception might be that you think individual accounts must balance (Or think that what I'm saying). Transactions always balance, companies always balance. In double entry accounting you track where money came from to you. You are right in not having to worry where they get their money from. But you do have to track how/why it came to you. You will have an account in your accounting of 'income' (it's…

Ah okay thanks a ton! I think that clears it up. So basically: - The idea is that every source/destination ("node") of funds keeps their own account for every node they deal with. And every transaction ("directed edge") necessarily needs to be tracked by both accounts in an equal and opposite manner. - This is mainly only useful for businesses, as they generally have multiple sources of income (and/or multiple credit…

Yes on both fronts. Thanks for continuing until we've got on the same page.

The only slight curve ball in your part one is that transactions are not always between two accounts. The joke is that 'double entry' sometimes has more than two.

The classic example is sales tax. E.g. a transaction:

Revenue>Product $100CR

Liability>Sales tax $5CR

Asset>Bank $105DB

(Although the specific form/standard categories will massively depend on how sales tax works in your jurisdiction.)

There are plenty of other examples (in my consulting: the customer paid some their bill in advance, or I pay a bill in a different currency and have to pay a fee).

So I like the idea of making it a topology question, but it would be nice if it were only two.

Re: Double Entry Accounting for Developers

#86

Post by mehrdadn »

sago wrote: post #85
mehrdadn wrote: post #76

Earlier quoted context omitted.

Ah okay thanks a ton! I think that clears it up. So basically: - The idea is that every source/destination ("node") of funds keeps their own account for every node they deal with. And every transaction ("directed edge") necessarily needs to be tracked by both accounts in an equal and opposite manner. - This is mainly only useful for businesses, as they generally have multiple sources of income (and/or multiple credit…

Yes on both fronts. Thanks for continuing until we've got on the same page. The only slight curve ball in your part one is that transactions are not always between two accounts. The joke is that 'double entry' sometimes has more than two. The classic example is sales tax. E.g. a transaction: Revenue>Product $100CR Liability>Sales tax $5CR Asset>Bank $105DB (Although the specific form/standard categories will massivel…

Yeah I almost mentioned multiparty transactions too, but thought I'd keep it simple since I got the crux of it :) thanks!

Re: Double Entry Accounting for Developers

#87

Post by patmcc »

mehrdadn wrote: post #44
sago wrote: 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…

> assets + liabilities + equity = 0 So how does this actually work? Say I worked for 8 hours at $25/hr. I get a $200 deposit in my checking account; that increases my assets. How is the sum still zero?

This is why "assets = liabilities + equity" works much better.

You would increase assets by $200, since you got that much cash (cash is an asset). You would increase equity by $200 as well (often accountants will call that "Owner's Equity") since your personal stake in this business (yourself, here) has gone up. That's the double entry.

Re: Double Entry Accounting for Developers

#88

Post by rahimnathwani »

I'd recommend you avoid this article. It is more confusing than necessary, and the accounting entries (at least in the first example) are wrong/unconventional.

The articles mentioned by dragonsh (Beancount documentation) and mtlynch (Martin Kleppmann's site) are great. But I feel unsatisfied by the way they discourage understanding of debits and credits, by just giving you something to memorize, e.g.

"Now, by convention, accountants flip the sign on all of the blue and pink nodes’ balances, which means that the two sums end up being equal. And that’s why it’s called a balance sheet."

You don't need to memorize which accounts are negative and which are positive. Just relate them to the English words 'debtor' (someone who owes money) and 'creditor' (some who is owed money), and you can work out the right entries for any transaction.

You credit (CR) an account when you're recording:

- an increase in the amount your company owes, or - (equivalent) a decrease in the amount some other entity owes your company

The other entity could be a supplier, a customer, or one of your own shareholders.

Examples of credits that can be identified by the above rule:

- A customer pays you some money they owed you: CR 'Assets - Accounts Receivable'

- A supplier sends you an invoice: CR 'Assets - Accounts Payable'

- You send an invoice to a customer: CR 'Revenue'

The last example might be confusing at first. Why is revenue like something you 'owe' someone? Because any profit the company you make does not really belong to the company, but to the shareholders.

If you can work out whether one side of a transaction is a debit or a credit, you know the other side is the opposite. So, for the above transactions:

CR 'Assets - Accounts Receivable' / DR 'Cash'

CR 'Assets - Accounts Payable' / DR 'Expenses'

CR 'Revenue' / DR 'Assets - Accounts Receivable'

Re: Double Entry Accounting for Developers

#89

Post by jonahbenton »

arnonejoe wrote: post #45

The debit and credit statement is incorrect. It depends on if it's an Asset, Liability, Equity Revenue or Expense. Balance Sheet (Assets = Liabilities + Equity) Assets (debits increase, credits decrease) Liabilities (debits decrease, credits increase) Equity Accounts (debits decrease, credits increase) Income Statement (Revenue - Expenses = Income) Revenue Accounts (debits decrease, credits increase) Expenses (debits…

Presumably that means the Finance/Accounting was a waste of time. That's too bad. From an opportunity perspective the combination of accounting and CS has never been stronger. The tech in debt and banking is going through total wholesale rebuilding over the next 10 years. Asset tokenization changing the definition of ownership. On and on. Hope you get to leverage that special expertise. Good luck.

Re: Double Entry Accounting for Developers

#90

Post by kazinator »

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…

That is wrong; the equity and liability accounts run negative in this view, because they represent external interests in the business. When equity increases, the equity account representation of it decreases; i.e. decrements toward negative infinity.

> Equity will either remain the same or increase when a business obtains $1000 out of thin air.

By "out of thin air" I meant that the business doesn't owe the money other than to its owners as equity. Like say the business won that in a lottery or something.

> Obtaining a loan will increase cash/increase liability accounts

You don't get the system obviously; you're thinking in the broken credit/debit system.

Post reply on HN