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.
I agree. However, the problem is that you can either make the vocabulary consistent or you can make the math simple, never both.
Making the math simple means you have to make a decision to always treat debits as positive and credits as negative or the other way around. You just have to be consistent.
Making the vocabulary work means you have to switch signs based on account type. But that makes the math and hence the software complicated and error prone.
Assets being positive makes sense. But debiting an asset account to make it more positive is counter intuitive. And expenses being positive doesn't make much sense either, because having lots of expenses is not so good, is it?
We're just accepting the inconsistent vocabulary as a price for having a simple mathematical model.
Expenses come in and cash goes out. Debit expense, credit cash.
From an accountancy POV, the debits of a transaction equal the credits. From a software POV, the account changes total zero. There is a difference in what the word “balance” means.
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.
Your credit card is linked to an account in someone else's books. They opened that credit account for you.
Debits come in to an entity, credits go out.
> That is the complete opposite of common usage.
Nah, it's exactly the usage you are used to from statements you get.
> When I get a credit on my credit card statement, it means money is coming in to me.
When you get a credit card statement, it's a statement of the portion of your account in the card issuer’s books.
If you were keeping books for the card, they would be mirror images of the bank’s books.
Your credit card account is an asset from Visa’s POV. And a liability from your POV.
When Visa refunds that fee, it reduces their asset. And on your books, it reduces your liability.
A debit on your books is a credit on the counterparty’s books. A plus on your books is a minus on the counterparty’s books.
It’s likely the only reasonable implementation of a blockchain but we won’t know that for sure until cryptocurrency matures enough to develop reasonable controls. I’m not holding my breathe because then it’s just an accounting system with reasonable controls built in and there are already more than enough of those built with databases.
OP has chosen a consistency in the operation of debit+credit sign and applied a 'display adjustment' to implement the classification. This actually sounds like a lower entropy way to remember it -- no left hand/right hand stuff, just 'There two account types are sign reversed on display'. But it will confuse anyone who isn't indoctrinated to the convention, but one could argue that it is these various conventions that make double entry seem arcane in the first place!
The easy way to remember this is just to think that the right hand side is what you think it should be, and the left hand side isn't.
Double entry book keeping is under appreciated - it's one of the earliest examples of error correction and detection coding kicking around.