Live data from Hacker News

Double Entry Accounting for Developers

django-hordak.readthedocs.io

101–110 of 237 posts

Re: Double Entry Accounting for Developers

#101

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 calculat…

I would love to make use of my strong cross-disciplinary skills like this, but I see no evidence that this is actually true.

Re: Double Entry Accounting for Developers

#102

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.

Re: Double Entry Accounting for Developers

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

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 increase in your bank account) comes onto your books. You credit cash and debit asset.

From the bank’s POV, cash came in - they debit their cash account. And they credit your account in their books. That account is a liability from their POV - they owe you the money.

Notice how the debit and credit to cash even balanced across entities. If you talk about pluses and minuses, you’ll get confused quickly.

One of the worst things that ever happened was banks issuing “debit cards”. When you take cash from an ATM, it’s a debit from the bank’s POV. The bank carries your account as a liability, which carries a credit balance. (You are the bank’s creditor!)

So the bank debits your account (credit came in again) and credits their cash (cash went out).

You credit the bank account on your books (asset went out) and debit your cash (cash came in)

Just remember that a “debit card” reflects the banks POV and don’t let that confuse you about the meaning of “debit”. Debiting an asset is generally a good thing!

When making accounting transactions, debits always balance credits - meaning they total to zero in the code itself. It’s conventional to make assets positive (hey, having lots of assets is good, right?).

OP gains nothing but confusion by turning everything upside down.

Re: Double Entry Accounting for Developers

#104

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.

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

Surely there's a big difference between earning a CPA and just knowing the basics of accounting.

I had a summer job helping out with entry in a family member's small accounting firm. I don't think that double entry accounting is that crazy of a concept that it cannot be grasped by someone without a degree in the field.

Re: Double Entry Accounting for Developers

#105
post #22
post #14

Earlier quoted context omitted.

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 acc…

Equity is similar to a liability. Ít is owed to the owners of the entity.

Making assets positive in code is conventional.

Re: Double Entry Accounting for Developers

#106
post #41

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.

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 outside world.

Re: Double Entry Accounting for Developers

#107
post #52

Earlier quoted context omitted.

Debit is where you put money. Credit is where it came from. I am not inventing this. Money in your bank is debit in _your_ accounting. You are very welcome to treat it as positive and add. As long as you keep track of where every positive number is a credit or a debit, and you learn all the rules about which accounts to add and which ones need taking away. Or you can just treat credits as positive numbers and debits…

I think you're confused on what I'm confused about. The positive or negative sign isn't the issue. You could flip all the signs and I'd still have the same problem. > Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative. But that is literally what I'm talking about. Whether the sign is positive or negative isn't the issue. It just makes no sense for this to be a…

That's easy. The $200 would be income (that had no associated expense!)

So, you credit your income account (income generally reflects your effort "going out" - did you have to make someone like you to get a gift?)

And you debit your cash account $200. Everything is balanced.

At the end of the year, you close your books by debiting income and crediting owner's equity. That's you. Congratulations!

(See my post on debit/credit above).

Re: Double Entry Accounting for Developers

#108
post #38

Earlier quoted context omitted.

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…

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.

Re: Double Entry Accounting for Developers

#109
post #108

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.

Isn't this just a matter of perspective. You are being debited by the third party, meaning they are requesting money. The bank credits your account with money when they put something in your account.

Re: Double Entry Accounting for Developers

#110
post #79

Earlier quoted context omitted.

Equity accounts are confusing.

I wish I could tell you how to remember it from first principles, but I can’t do what I did was burn the A = L + (OE/Equity) accounting equation into my head. Then I remember that the when my bank balance goes up, the bank speaks of a credit in their accounts which is a debit to assets in my account. Then L + OE must be credit accounts. Why are OE and L on the same side? Well to finance an asset, say a new car for yo…

I mean, it's not hard to remember. They're liability-like. It's just their uses in practice that're confusing.

BTW, nonprofits have Net Assets accounts instead of Equity accounts.

Post reply on HN