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.
In computerised accounting it is completely normal to use negative numbers for credits and positive numbers for debits. That way a whole trial balance sums to zero. Very neat indeed.
What is missing above is the concept of accounts to put the balance in. For instance if I have a loan I put it in an account called 'loan', and list it on my balance sheet as a creditor. It will always have a negative balance. If it doesn't there is a problem.
Alice from above owes me 5 bucks so goes in the debtors (or receivables account).
I owe bob five bucks it goes into creditors (or payables)
One classic piece of error checking is to review debtors for credit balances. It means someone has overpaid, needs a refund or screwed up posting it.
That's not quite the point of double-entry. When one account is credited, at least one other account must be debited.
All debits and credits sum to zero, but the accounts will have positive or negative balance.
Because debit and credit may be looked at differently in fee calculation. You may not be able to un-debit the same amount easily. This is just a historical/established practice, but you cannot squash the two into +/-, because you would lose “cancellation” in cases when a mistake is discovered but the quarter is done and already git-pushed to IRS/etc. See “storno (accounting)”.
That wouldn't make sense. Alice sent Bob $5, so now Alice's balance would be $5 and Bob's would be -$5? The amounts should display their balances within the app, and Alice and Bob should have their own personal balances which are independent of the app's. Before the transaction, both Alice and Bob were at $0 on their personal balances and afterwards they were still at $0, since neither of them had more dollar bills on their persons. The difference between their personal balances and their balances in the app is the value you're alluding to. $0-(-$5) for Alice and $0-$5 for Bob. This difference could be interpreted as the amount that each owes to the app (positive for Alice because she owes and negative for Bob because he is owed).
Then you're arguing how the value should be displayed. There's no reason to prefer one sign or the other in the codebase, as long as it's always displayed correctly to the correct actors.
The centuries of accountant's aversion to using negative numbers in day to day accounting usage has abstraction uses even in your codebase.
Counting was invented before negative numbers, but "double-entry accounting", which is what people refer to when they say debit and credit, was only invented in the 18th century, IIRC.
> "debit" and "credit" and
> think they have to do with
> "owing" or "being owed" money.
When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account.
Examples:
- bank credits a customer account => bank owes more to its customers
- company credits income account => company owes more to its shareholders
- company credits accounts receivable => company owns less in unpaid invoices
> Without the context of the
> specific accounts being debited
> or credited the terms
> themselves mean nothing.
> A debit is the entry in the left
> column, and a credit is an
> entry in the right column.
> This seems incorrect to me.
You can't derive the change in assests, liabilities, or equity without know which accounts are being debited and credited. The terms "debit" and "credit" themselves don't tell you anything by themselves. Without the context of accounts the terms are meaningless. I think programmers get hung-up on thinking that they have meaning in isolation (i.e. thinking that "a debit means somebody owes us money").
> I think of it as 'owing' (liability) or 'owning' (asset).
> When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account.
That's my point. When you know they type of account being debited or credited you can reason about how it affects the balance of the account and the managerial context of the transaction (i.e. "somebody owes us money because the debit was to a receivable account").
This is true, but it doesn't negate my point (that debit and credit have meaning independent of the type of account).
I know this because I have used the principle many times in practice, to define charts of accounts, to define rules for posting different types of transactions etc.
Given a debit of $500 and two matching credits of $250 how is the owner's equity position affected?
A programmer, unfamiliar with accounting, might think that "debit" and "credit" carry enough meaning in this context to answer the question.
You and I know that without knowing what account types are being debited and credited we have no way of explaining what the managerial result of that entry is. That's an unanswerable question w/o more context. That's my point.
Let me give it one last try :)
You're claiming the truth of two propositions:
A) Without the context of the specific accounts being debited or credited the terms [debit and credit] themselves mean nothing.
B) Without the context of the specific accounts being debited or credited we have no way of explaining what the managerial result of that entry is.
I agree with B, but do not agree with A.
When an account is CREDITED, this always represents an increase in liabilities[0] (or equivalently, a decrease in assets).
When an account is DEBITED, this always represents an increase in assets (or equivalently, a decrease in liabilities).
The two statements above are true as written. If you were to exchange the capitalized text (turning CREDITED into DEBITED and vice versa), the statements would no longer be true. Therefore credit and debit each have some distinct meaning.
[0] I treat 'shareholders equity' as being a liability in favour of shareholders
> When an account is DEBITED, this always represents an increase in assets (or equivalently, a decrease in liabilities).
This is where you're wrong. You can credit and debit Accounts Payable and Accounts Receivable. If you credit AP, you're increasing liability, if you credit AR, you're increasing assets.
This is incorrect. If you credit AR, you're decreasing assets.[0]
[0] https://www.freshbooks.com/hub/accounting/debit-and-credit#:....
I think what you mean here is that a debit balance in an asset account is presented as a positive amount, whereas a debit balance in a liability account would show as a negative amount.
This is true, but that doesn't mean a credit has the opposite effect depending on whether it's applied to an asset or liability account. Consider that you have two different accounts with your bank:
- a current account (usually the bank owes you money, i.e. usually a credit balance from the bank's POV)
- a loan account (you bought a car on credit, and owe the bank money, i.e. a debit balance from bank's POV)
For the bank, the current account is a liability ($1,000) and the loan account is an asset ($25,000).
When you deliver a bag containing $5,000 to the bank, the bank will credit one of these two accounts. They'll either increase the current account to $6,000, or decrease the loan account to $19,000.
In either case, the credit has the same effect: your net debt to the bank is decreased by $5k.
money OWNed = money OWed
And thus:
Assets = Liabilities + Equity
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.
OMG I so agree with this. I worked at a company where we wasted so much time, and moved so much more slowly, just because some previous technical person hadn't completely thought through the implications of ever including primary keys on the GL feed. The whole time I was there I begged the accounting drones to forget about this concept, repeatedly enlisting the marketing department who claimed to believe that velocity was a good thing, but I too failed. Eventually I realized that if we didn't give them primary keys they would have to lay off multiple people whose only function was to look at primary keys. Instead I should have invested more effort in programmatically generating the database entries that drove this whole boondoggle.
Not the first, and also not the last, place I worked where the CFO could have been the least honest person in the building.
(And then simple auto-incrementing numbers turn out to be not so simple indeed the first time you need to shard or otherwise decentralize your database for whatever reason.)
I don't think there's an easy answer here. We can't return to the ideal of natural keys, because reality has shown that's a pipe-dream. We can focus on using more artificial primary keys that don't look like simple auto-incrementing numbers like GUIDs and Snowflakes and ULIDs and string slugs and more, but those aren't without overhead or tradeoffs both at the database level in the raw and in the user experience and these business processes that we don't want to use our raw database IDs but we can't just give a more natural equivalent either. ("How can I refer to Issue 6D038E7E-A0D8-45EB-AAC6-1E3FEC9DA5B8 on the phone or in a meeting?" "How can I excel spreadsheet my way through the system's data without being lost?" Etc and so forth. On the one hand it feels like a failure in the system if so many processes still need to work outside of and around the system, but on the other hand humans and businesses are social creatures and these side processes arise naturally like breathing to that combination of humans inside a business.)
This fact is rarely mentioned in business talks so people have a whole variety of ideas what they mean, as you can see itt.
I think most people agree with you. They prefer to memorize some rules, or just look them up. Personally, I find having a simple principle helps me reason about new situations (new transaction types).
Taking this as sympathetically as possible - which is tough - because do you really think the person you are replying to on this forum with the given response does not understand principles in the abstract?? This really is quite condescending.
The entire point of a statement like this is that debit and credit are fundamentally abstract - such that when they have no essential features above their effect on the account.
I mean did you bother to read the clarifying following sentence before you selectively quoted?
Except programmers quite often get the conceptual meaning wrong and incorrectly generalize further. Credit and debit just mean increase or decrease in account balance. You cannot know how it affects liabilities or assets without knowing what type of account is being modified.
I like this phrasing. I wish I had used it!
That’s because the system is not built by programmers. Some accounts (that’s accounting accounts, not bank accounts) are positive for you and some are negative. You need to know what kind of account it is to know if debit is good or bad for you.
That's definitely not the reason I consider GP's comment incorrect.
(I'm a qualified accountant.)
So if somebody gives you $100 in cash, you book that as $100 in your "cash" asset. But... the books must balance! And so, you need to book -$100 on the "income" side, because that's where the cash comes from.
If you're not happy with "because it needs to follow the rules" alone, replace "income" with "other people's money". For you to get cash, somebody else needs to give up cash.
The reason you differentiate between asset/liability and income/expense accounts is that you can't really fully balance the latter two. You don't know all the details happening to "other people's money". You know everything happening to your assets and liabilities.
As a result, income/expense are accounted over time ("I made $x/year") while assets liabilities are a value ("I have $357 in my cash drawer") - for the former two, all you know is the delta over time you cause.
Think of "shareholder's equity" aka "owner's equity" as being a liability. After all, doesn't a company owe all its earnings to its owners?
Now, consider that:
- all income is a liability owed to shareholders. So any new income is an increase in the amount owed to these shareholder 'creditors', represented by a credit entry
- similar but opposite reasoning says that a new expense is represented by debit entry
If you feel uncomfortable seeing shareholders in the same category as creditors, consider that companies can choose two ways to fund themselves: equity (which creates shareholders) or debt (which creates creditors).
A credit entry is a source, and a debit entry is a sink. When I do $4000 worth of consulting services work for Joe Bloggs, this gets entered as a $4000 credit to Income - Consulting Services (the source of the flow of funds), and a $4000 debit to Accounts Receivable (the destination of the flow of funds). Income, here, represents the outside world from the perspective of my business. Later, the receivable becomes cash when Mr Bloggs writes me a check, so I credit Accounts Receivable $4000 and debit cash (actually something like Assets - Coolbank Business Checking) $4000.
Can you share a couple of example (or maybe use the same examples I did)?
I have had to train developers on the simple concept of a ledger, which totally baffled them. It is event sourcing. You write, never update. If you want to offset a previous transaction you just record a new one. Want to know the account balance, just add up every amount within the range of entries you care about.
Once they grasped that they were wanting to use the terms debit and credit in that context. Not cool. If you are tracking single accounts you only need negative and positive amounts. If the account/ledger is not offsetting another debit/credit there is no need to introduce that concept and complicate things. If you do, the finance team is going to wonder what other accounts you are offsetting. If the answer is none, brows wrinkle and confusion sets in.
And ffs don't ever send them a spreadsheet or report with currency symbols in it. Major peave.
Accountants have been using event sourcing (immutable ledgers) for hundreds of years. Powerful.
Every complex finance problem I have run into in software dev was easily and elegantly solved with immutable records.
If you look at equity as money owed to shareholders, then the left side of the balance sheet is money owned, and the right side of the balance sheet is money owed.
Money OWNEd = Money OWEd
Assets = Liabilities + Equity
Somehow transaction intermediaries made some incredible bullshity product differentiation out of those words... and what makes everything worse is that, since they are intermediaries, every transaction is both a debit and a credit on their own accounting.
"Red means positive, as in I'm positively sure you owe me a lot of money."
It's kind of like being given a cheat code.
In took an undergrad accounting class centuries ago. I'm a CS major, but we were required to take a beginner class in accounting, which in retrospect was a good thing.
In the accounting class (the double-entry bookkeeping part), for any transaction two accounts were involved:
- Money was "debited" into one account. ie., money came into that amount (balance increased)
- That same money was "credited" from another account. ie., money left that account (balance decreased).
However, my bank seems to use the terminology in the opposite way. If $10 comes into my bank account, I get a message saying "$10 was credited into your account".
Likewise, if I send money elsewhere the message would be "$10 was debited from my account".
I'm told that if you look at it in some convoluted way the meaning of "debit" and "credit" is infact the same, even though at first glance is seems to be the opposite.
Now that I think about it, there was something to do with "asset", "liability" etc, on which the meaning of the terms depended on.
That's because you are a creditor to the bank. After you put cash into your bank account, the bank owes you cash. You are lending them your cash, and the more you lend them, the more of a creditor you are. That's why they say your account is in credit.
When you take too much cash out of the bank, it's obvious you are a debtor to the bank. You owe them. You're in debt to them. That's why taking cash out is called debiting. The more you take out, the closer to a debtor you become, though hopefully on balance you've been more of a creditor than a debtor.
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.
My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves mean nothing.
Aside: A 100-level knowledge of accounting can confer near "super powers" when it comes to dealing with finance and accounting people. Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.