Accounting For Developers, Part I

Problem with this is it's a convention. Accountants in Australia could do it the other way (credit on left) and it works just as well.

Accounting was invented before negative numbers. Because of this, instead of counting money as positive or negative amounts, it uses the debits and credits. Instead of subtracting funds from one account and adding them to another, we talk about crediting one account and debiting another.

But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers? Using positive and negative numbers gets ambiguous.

If your app lets Alice sends Bob $5, we remove $5 from Alice’s account and add $5 to Bob’s account. So it seems fair to say that if both user accounts started at $0, Alice’s balance is -$5, and Bob’s balance is $5. Let's represent it that way in your DB.

Your CFO would disagree. From your company’s perspective, what these balances mean is that Alice owes you $5, and the company owes Bob $5. In other words, if the company went out of business tomorrow, you'd have to go out to collect $5 from Alice so that you could give Bob the $5 he rightfully thinks he’s holding inside of your app. Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5?

It gets even more confusing if your software deals with financial instruments like loans, investments, or invoices. Dealing with every balance in your application as a simple positive or negative number gets really confusing, and will cause both ledgering issues and communication breakdowns between your eng and financial teams.

As others have mentioned a basic double-entry accounting transaction includes two pieces of information: "where did the value come from" and "where did it go". This aspect of double entry book keeping I think is the less interesting one and you'd be right in not seeing any big deal as compared to single entry accounting... a check register style accounting with categories fits that definition pretty well. The debit/credit recording of double entry book keeping is really about the next point. Note that I used the word "value" because that value isn't necessarily cash, though value is always expressed in money terms.

The next aspect, and the important aspect, is not the transaction but the accounting equation: Assets = Shareholder's Equity + Liabilities. This is where the formalisms of double entry accounting start to differentiate itself from single entry accounting. This equation expresses what it is we ("the company") own (assets) and who has a claim on it (shareholders and others we owe such as lenders). All of our accounts are assigned into one of these three categories and whether we debit or credit an account depends on this categorization relative to the accounting equation. So if I buy a hot dog for lunch with my bank card I'll credit my bank account (an asset account) which reduces it's value and debit an expense account which is a special kind of shareholder's equity account. Shareholder's equity = retained earnings from prior years + (current revenue - current expenses). When I book the expense debit the result is that shareholder's equity decreases. On the other hand if I use the same bank account to buy a house... I still credit the bank account (an asset account) but now I debit a real estate account (a different asset account) which reflects that I changed the form of the property I had (cash to real estate), but I didn't change the shareholder's equity position or the liability position (yes, there are fees and most people buy houses with borrowed money... but ignore that for this discussion).

In the single entry world everything aside from the transaction itself is simply left to you to figure out. There really aren't additional formalities which guide you in getting a deeper understanding of the accounting data you generate. You could emulate this stuff, but typically something like Quicken isn't going to help you be sure your following these formalities. For many interested in personal accounting, not having these formalities is fine. But in business, the accounting equation and the many expansions of that equation tell you about the business is a way that is (should be) reasonably consistent from business to business. It's more than: "do I have enough in the bank for the next transaction", it's really about a clear statement of health and direction derived from the transactions.

I think of this as being similar to primary key constraints - my rule is primary keys should not have a business meaning. I have walked into many situation where they would have implemented so - and usually will fail to convincing them otherwise.