Double Entry Accounting for Developers

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.

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 increase, credits decrease)

A few rules:

Balance Sheet Accounts carry over every year. Things like cash, accounts receivables and payables, loans and equity in the company carry over year after year.

Income Statement Accounts close out at the end of the year and close in to the equity and cash parts of the balance sheet (depending if a dividend was declared). The Income statement accounts are zero at the beginning of every fiscal year. The balance sheet accounts carried over from the previous year.

One example of the above to illustrate the mechanics of double entry accounting:

Lets say you bought a car for your business in cash. you would credit cash (to decrease your cash account) and debit an asset account (a balance sheet account) for the car. when you depreciate the car over time you would credit the car account at some interval for the depreciation amount thus reducing its value and debit the expense in the current period thus increasing expenses in the current period.

The reason I know this is because completed an undergrad at ASU in finance/accounting and then CS after that. It was waste of time.

The division of accounts into credit- and debit-normal with a strong anti-negative-entry bias (to the point of contra sub-accounts for recurrent activities that go in the opposite direction of the parent account’s normal) seems to me like it provides an important QC feature, especially when books are kept or reviewed manually. It's a lot easier to see “this is not the kind of thing that belongs in this account” than “that is not the right sign for that activity”. And the resulting categorizations are useful in their own right, and it's important to remember that accounting is not just about adding numbers, but about categorizing the associated activities.

Income > Work: $200 (or $200CR)

Assets > Bank Account: -$200 (or $200DB)

This is exactly how it would be stored in any software system behind-the-scenes, and how it would be submitted in statutory accounts. The only thing that makes this look weird is that you are used to seeing your bank account statement with 'credit'. But that's only because the bank account statement is from their accounting perspective.

Money comes from somewhere (Positive, Credit); it goes somewhere (Negative, Debit).

The entire confusion about signs and what to add and remove, and what categories 'increase' with debit or credit, it all disappears when you allow negative numbers. I guarantee your accounting software _will_ simply store them as positive or negative. It is frustrating that it appears so complex simply because of avoiding negative numbers.