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.
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!
It's beyond wrong. The developer here is redefining established accounting terms because he doesn't like their inconsistencies.
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.
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.
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!
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
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
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.
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.
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.
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.
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.
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.
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.
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.
Then later after learning about natural account balances, it all made sense. If an account has a debit balance, a debit increases the balance and a credit decreases it. An asset or expense account has a debit balance.
Credit balance is just the opposite. Liabilities, revenue, accounts. Credit is an increase, debit decrease. (I think equity too but I always have to look it up. Rarely work with equity accounts in my day to day)
Why are OE and L on the same side? Well to finance an asset, say a new car for your business, the company would either take on some debt (L) or you’d put in some of your own money (OE) in exchange for more ownership. I don’t know if that’s more confusing or less
BTW, nonprofits have Net Assets accounts instead of Equity accounts.
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.
That doesn't change the fact that I'd be wary of any accountant writing a blog post on how to write good quality code for production. Are there accountants out there who can do a good job of that? Absolutely. Are there many more accountants who would do a poor job of that? My guess is also yes.
It's more a case of someone who has one year of writing JavaScript shouldn't be writing on the theory of software development.
I wouldn't call it wrong per se, but it's about what would happen if I as accountant designed a database architecture. It would work, but any programmer looking at the dodgy code would think "omg what have you done?"
All account balances should normally be positive. Depending on what side of the balance sheet they are, a debit or credit could increase or decrease an accounts balance.
Everything else follows from that idea plus a bunch of terminology.
From my experience, if you're doing accounting beyond a hobby, you likely want to follow whatever GAAP (generally accepted accounting practices), and likely need to consult references for how specific cases are represented. If you then don't use the same language and conventions as everyone else, it's just even more of a pain than it is.
My experience here is that I was with a large audit company, albeit as an actuary rather than an accountant. I did have the opportunity to dig quite deep accounting records of insurance companies there. Now I own an incorporated company and do my own accounting and taxes (with GnuCash for accounting, even if I hand-rolled reporting for XBRL export and all).
Best of luck!
A transaction has two polarities, because it represents a flow of value. The credit side is the source, the debit side is the sink/destination/whatever. Let's temporarily pretend that every transaction hits exactly two accounts for the moment (which is not true), to make it easier.
Let's say we have $1000 in Cash, which is an Asset, and we want to buy a Pizza, which is also an Asset, for $20. How does this look in accounting?
Cash provides the source side, and Pizza provides the sink. Cash is credited $20, and Pizza is debited $20. If we ran the balances now, Cash would come out to $980, and Pizza would come out to $20.
Let's unwind that transaction. We're a business; we don't trade cash for pizzas. We contract for delivery of pizzas with a pizza vendor, who invoices us.
So here we are, with $1000 in Cash and $0 worth of Pizza. The pizza delivery driver comes, and hands us a pizza and an invoice. We know we have to debit Pizza $20; what is the credit source for this debit? Well, the pizza vendor has actually extended us a loan worth $20, in a sense (this is called "trade credit"), and the offsetting entry is the fact that we owe the vendor $20, as memorialized in its invoice. This goes in a Liability account, usually called something like Accounts Payable.
Current balances (if we ran them - "running the balances" is thought of by accountants as a discrete operation, just FYI):
Assets/Cash $1000
Assets/Pizza $20
Liabilities/Accounts Payable $20
Let's just leave that on the books and eat the pizza. After eating the pizza, we no longer have $20 worth of pizza, so we have to credit Assets/Pizza $20. What do we debit to offset this - i.e., where did the pizza value flow to? In this case, it would be a Depreciation account (these are debit-increased) - something like Depreciation/Eaten Pizzas. So we have:
Assets/Cash $1000
Assets/Pizza $0
Depreciation/Eaten Pizzas $20
Liabilities/Accounts Payable $20
Meanwhile, someone pays us on one of our invoices, which we had sent out earlier offscreen. When we delivered our fine $50 widget and invoiced the buyer, we entered that into our accounting system as a debit of $50 to Assets/Accounts Receivable, and a credit of $50 to Assets/Widgets. This part of the system looks like (we still have 9 widgets in stock):
Assets/Cash $1000
Assets/Widgets $450
Assets/Accounts Receivable $50
Assets/Cash $1050
Assets/Widgets $450
Assets/Accounts Receivable $0
Assets/Cash $1030
Assets/Pizza $0
Assets/Widgets $450
Assets/Accounts Receivable $0
Depreciation/Eaten Pizzas $20
Liabilities/Accounts Payable $0
Ledger entries look (conceptually, not literally) like this:
|tx id| account | debit|credit|
| 123|Cash (bank 1) | 25| 0|
| 123|Cash (bank 2) | 25| 0|
| 123|Accounts Receivable| 0| 50|
Accounting is, of course, way older than computers, so accountants like to regularly "close the books" (checkpoint the state and generate reports).
Aside, I think the mental block for techies when it comes to accounting is just that many don't want to accept that accountants understand accounting. It looks like databases to them, and those are TECH!
I think a large factor in the "programmers reinterpreting accounting" phenomenon is the fact that accounting is full of somewhat idiosyncratic terminology and conventions which are somewhat counter to modern mathematical conventions. These conventions should still be upheld in order to be mutually intelligible with the accounting world, but it seems quite unlikely they are the optimum in terms of ergonomics and ease of understanding. If we designed accounting from scratch today, I doubt we would end up with these conventions.
A naive programmer is perhaps in one of the best positions to see these idiosyncrasies and think "This is using the wrong conventions and can be made much simpler by just shifting some signs around!".
Maybe this might work for a bank where assets and liabilities are sort of flipped from a non-bank business?
For example - if you're holding someone's money for them, that's a liability - you have to pay it back some time. If someone owes you money, that's an asset - it's worth something. Banks use the cash from liabilities (people's savings accounts) to pay for assets (mortgages) and make money on the spread.
Let's see, when they lend money they don't have (which is what it is) they increase the number on your account, that is they create a big liability for themselve. On the other hand they create an asset wich is your debt to them. So accounting-wise, it works out, like theorically I could do that (lending) even if I have €0, it's all paper.
But then you're gonna go and empty that account to buy your house, reducing their liability and taking (reducing) their cash instead... that they don't have !
So how does it work ? Does it just work because you don't actually buy houses with bills and coins but with bank transfers, then just shifting the paper magic to another bank ?
To be honest I know they can do something my broke self can't, and it has to du with central banks, but what is it exactly ? Something like "if everybody happens to empty their account to cash at the same time, don't worry mate we'll print them bills and give them to you, pinky promise" ?
It would not work for a bank. The only reason they 'sort of flip' is that they give your account from their perspective. Your statement is a slice of their accounting.
Assets + Expenses + Dividends = Liabilities + Contributed Capital + Revenue
Traditional accounting takes this as says: "All accounts have positive values. All transactions contain an equal number of debits and credits. Debits always come first, are always written on the left, and so it (sort of) makes sense for debits of left hand side accounts to always increase the value of the account, while debits of right hand side accounts always decrease the value in the account. Similarly, credits come second, are always written on the right, credits of right hand side accounts increase the value of the account, and credits of left hand side accounts decrease the value of the accounts."
It turns out if you work through the implications of this, it works perfectly. I buy lunch for $5, so I must have a $5 debit and a $5 credit. That's an expense; my expenses are going up, expenses are on the left, so they go up via a debit. The matching credit could be to cash; cash is an asset, it's also on the left, credits make left hand accounts go down, that makes sense. Or the matching credit could be an accounts payable account, that's on the right hand side, and credits make right hand accounts go up, which again makes sense.
The core logic here is that changes must balance. If your changes are both on one side, one will be positive and one will be negative (summing to 0). If your changes are on opposite sides, either both will be positive or both will be negative (still summing to zero).
But, you could also re-arrange the equation further:
Liabilities + Contributed Capital + Revenue - Assets - Expenses - Dividends = 0
Algebraically, that's the same. If you built a system on that, you could say something like "All transactions must sum to zero. Asset, expense, and dividend accounts are subtracted from the balance, while other accounts are added to it." That still works. My $5 lunch increases expenses, which is a "negative type" account, so I have to either increase a matching "positive type" account (like liabilities) or decrease a matching "negative type" account (like assets) so everything stays zero. It doesn't feel...easier, but it works.
Or you could take it a step further, and weirder, and say:
Assets + Expenses + Dividends + Liabilities + Contributed Capital + Revenue = 0
That...uh....doesn't work mathematically, unless you flip the sign of all assets, expenses, and liabilities. So maybe:
(-Assets) + (-Expenses) + (-Dividends) + Liabilities + Contributed Capital + Revenue = 0
I dunno, this is getting a bit weird. Now my $5 lunch is a $5 credit and a $5 debit. Expenses has gone up, so that must be what the author calls a credit, but since expenses is a magic negative account the displayed value will go down. And then we must have a match debit (in the authors terms) which will make an account go down. And again, we can pick assets to go down (if I spent cash), except again assets is a magic flipped account so will make the displayed value of assets increase, or we could pick liabilities which is a normal account and thus the value will actually go down.
Technically, all this is interchangeable. However: The standard form (LHS = RHS, debits increase LHS and decrease RHS, credits increase RHS and decrease LHS, debits = credits) is universally used around the globe, and has been in active use since the middle ages. It's also, in my view, relatively intuitive once explained. The middle form (all accounts sum to zero) is unorthodox, but also fine. Both require to to know an equality, and ensure that each transaction respects the equality.
The linked form is, in my view, by far the least intuitive, and also re-uses accounting terms with a different meaning. Not only does it not, in my view, help novices understand accounting, but I fear learning it makes it actively harder because you'll need to unlearn it first.
But it does, technically, work.
"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 debit/credit. I’ve simplified this on the backend as I strongly feel this is a presentational issue, and not a business logic issue."
I mean, this is just....wrong. Maybe I'm not smart enough to see why this isn't completely incorrect? I mean I feel mathematically this will work but goes against so many core accounting principles it won't have much use except in the simplest of cases.