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.

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

It doesn't, the Equity account displays a negative number if the company is in the green (it decreases when you emit stocks), the Expense account displays positive numbers (it increases when you spend money), the Income account displays negative numbers (it decreases when you earn money).

In beancount, the accounting equation is Expense+Income+Equity=0 and all signs are always left intact (there is only addition).

So you start a company with a seed capital of $5. You borrow $5 to the bank, buy an expensive apple for $10, sell it for $15 and give the money back to the bank with an interest of $1, then close the exercise and carry the profits (don't distribute dividends). Your ledger is:

  Initial capital
    Assets:Cash +5 USD
    Equity:Seed -5 USD
  
  Borrow to the bank
    Assets:Cash +5 USD
    Liabilities:Bank -5 USD
  
  Buy an apple
    Assets:Apples +10 USD
    Assets:Cash -10 USD
  
  Sell the apple
    Income:Sales -5 USD
    Assets:Apples -10 USD
    Assets:Cash +15 USD
  
  Reimburse the bank
    Liabilities:Bank +5 USD
    Expenses:Interest +1 USD
    Assets:Cash -6 USD
  
  Close the exercise # beancount does that for you for any time period btw
    Expenses:Interest -1 USD
    Income:Sales +5 USD
    Equity:PreviousProfit +4 USD

Notice how every transaction balances to 0 just by summing it, no need to remember anything.

Now, you're at the beginning of the next exercise. To know your accounts you just compute a sum of every operation to it, again no special case. So your accounts are:

  Expenses 0 USD
  Income 0 USD # as expected at beginning of exercise
  Assets:Apples 0 USD
  Assets:Cash 9 USD
  Liabilities:Bank 0 USD
  Equity:Seed -5 USD
  Equity:PreviousProfits -4 USD

And yet again, the sum of all of that is 0.

Personally I like it, not having any special cases. Yes, it may confused an accountant (because they learned the special cases by heart ! Somebody coming with a fresh mind has no reason to be confused, it's all just conventions !) but it's simpler for me and just as consistent.

FWIW I did an accounting elective at college and ran the books for a small business for a couple of years. I'm comfortable with the conventions :-) I was just saying OP was choosing to encode the conventions differently internally and display them a different way to meet the external convention, like GMT+TZ. You need never known your computer stores time in GMT and most people don't, even the accountants.

> What's wrong with fixing inconsistencies?

Nothing, if you can convince the entire user base to do it at the same time. If you decide to unilaterally fix inconsistencies, you've just made it impossible to understand what anyone is saying without additional metadata saying which version you're using.

And if you start telling learners that your "fixed" version is all there is, hiding the actual standard that most of the world uses, you are basically lying to them and setting them up to fail.

> What's wrong with fixing inconsistencies?

There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.)

> Established accounting terms are from 500 years ago when people had trouble with subtraction.

People still have trouble with substraction compared to addition, especially with large numbers.

> What's wrong with fixing inconsistencies?

In general, nothing. It's just not the software developer's job. If the accounting profession decided to change certain terms to fix inconsistencies, that would be fine.

I think that's missing the point of the original article. Of course you have to present a view of the accounts that is consistent with accounting rules and conventions. But that doesn't necessarily mean you have to adopt that external view as an internal model for any software you're writing.

At audit time the world of “holy shit what were these people thinking?” will be colossal, because we do not get to pretend that a system is a black box at audit time.

If those records don’t make sense to an accounting professional, then they’re fucked up, and that’s all she wrote. The world of audit has seen a million shysters try to falsify their books under the guise of alternative methods, and they are not interested in some self-serving hubris from programmers about re-inventing their own profession.

So this guide isn’t just philosophically off beam. It could get someone fired or sued.

Probably not prosecuted though. Probably.

Yeah I've worked on so many systems that dealt with money. Telephone invoicing, business accounting, ticket sales, etc.

One of the businesses I worked for did online invoicing and they initially started off without double ledger accounting. I was employee 30 or so and I kept repeating "we need double ledger accounting" every month or so. Nobody really listened to me (to be fair I was young, but this was after the telephone invoicing job) until the cracks started to form. It took them years to transition to a new system. Do not re-invent accounting with your own terms. International commerce runs on it and it has figured out a lot of the edge cases.

Accounting professionals can only ever look at user interfaces. If there is a suspicion of fraud then a court can ask expert witnesses to look into the software itself.

The law does put some constraints on what accounting software must and must not allow users to do (e.g change data without leaving a trace).

But I'm not aware of any specific legal requirements regarding data representation or mandating the use of specific algorithms where mathematically equivalent ones exist.

There are no inconsistencies here.

We have an algebraic indentity, a + b = x + y. (Let's not even think about what those might represent; it doesn't matter.)

The two sides must always be equal. Any transaction must maintain that equality. Therefore, any transaction must increase both sides by the same amount, decrease both sides by the same amount, or leave both sides unchanged.

One way to ensure this is respected is to add up everything which increases the left side or decreases the right side, then add up everything which decreases the left side or increases the right side, and ensure these two subtotals match. If they do, the transaction balances, and is legal.

By convention, we call things of the first type (which increase the left side or decrease the right side) "debits", and things of the second type (which increase the right side or decrease the left side) "credits". This lets us say "debits must equal credits" as a shorthand, although again what we really mean is that the two sides must continue to balance.

The end. There's really no inconsistency here.

Generally Accepted Accounting Principles

There's a lot wrong with fixing consistencies.