[EvanAnderson]

Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money.

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.

[kojim]

Debits and credits is the only way to give your team a common, consistent "language" for dealing with money, and being able to speak this language as a dev gives you superpowers.

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.

[jimnotgym]

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

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.

[candiddevmike]

What you're describing is accrual accounting (accounts payable/receivable). It is one method of bookkeeping, but a lot of other businesses tend to use cash (which deals in absolutes, you spent 5, you earned 5, etc).

[barking_biscuit]

You can model the data in such a way that the recorded transactions can be reported on in either accrual or cash basis.

[candiddevmike]

Not sure what you mean, as far as I know the government requires businesses to pick one form and stick to it. Unless you're building accounting software you'd have no need to support both ways.

[barking_biscuit]

I build accounting software.

[EvanAnderson]

It’s common for US businesses to file taxes on cash basis but use accrual for managerial accounting.

[yobbo]

> Because of this, instead of counting money as positive or negative amounts, it uses the debits and credits.

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.

[whatshisface]

That's like choosing whether +x is a rightward or leftward facing coordinate axis. You can still use negative numbers, but you have to indicate whether positive means left or right. See also: positive and negative longitudes vs. east or west longitudes.

[kojim]

Oh completely. The "agreeing on what's left or right" in every context is the tough part, and already a solved problem with debits and credits.

[withinboredom]

Uh. No. When I refund someone I issue a negative credit on my account. It isn’t a debit, strictly speaking.

[wruza]

But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers?

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)”.

[fluoridation]

>Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5?

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).

[kojim]

I agree that from a developer's perspective and certainly in the frontend it doesn't make sense to show a positive user balance as negative. But to a finance team, cash on your company's books (debits) needs to have the opposite polarity of money that your users hold (credits). My underlying point is that it's really hard to make that the case without using the credits and debits language.

[quacked]

This little comment chain has done more for my understanding of accounting than at least 3 hours of reading online and trying to have my accounting friends explain it.

[fluoridation]

>But to a finance team, cash on your company's books (debits) needs to have the opposite polarity of money that your users hold (credits).

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.

[WorldMaker]

Having been involved in various roles of double entry accounting adjacent tools, the next level up is realizing that it is easier to display the correct sign if you store things unsigned and use debit/credit nomenclature even in your DB model/codebase. It's not just that this makes it easier to talk to the accountants using your system about the internals of that system, but that showing the right sign becomes simple "pattern matching" based on entirely on the type of account and the user's type. There's no "math" involved to switch signs based on how it is "stored" in the codebase, the displayed signs are always a UI element that is clearly dependent on its inputs.

The centuries of accountant's aversion to using negative numbers in day to day accounting usage has abstraction uses even in your codebase.

[lelanthran]

> Accounting was invented before negative numbers.

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.

[vlmutolo]

It likely originated in late 13th century Italy.

https://en.m.wikipedia.org/wiki/Double-entry_bookkeeping

[rahimnathwani]

  > "debit" and "credit" and
  > think they have to do with
  > "owing" or "being owed" 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.

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.

This seems incorrect to me.

  > A debit is the entry in the left
  > column, and a credit is an
  > entry in the right column.

Debits/credits concepts can exist (and we can operate on them) without the existence of left/right columns.

[EvanAnderson]

> > Without the context of the specific accounts being debited or credited the terms themselves mean nothing."

> 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").

[rahimnathwani]

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

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.

[EvanAnderson]

I think we're talking past each other but I'm not sure how to rectify.

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.

[rahimnathwani]

"I think we're talking past each other but I'm not sure how to rectify."

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

[onefuncman]

> 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).

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.

[redandblack]

I prefer not to ascribe semantics to accounting credit/debit - only thing that matters is it is consistently applied and balances out.

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.

[jessaustin]

...my rule is primary keys should not have a business meaning.

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.

[WorldMaker]

It certainly depends on if you are working with natural keys or artificial ones. Somewhere in the decades of applied relational calculus we lost sight of natural keys and what those even are. In part because they are hard and it turns out that few natural keys seem to exist "naturally" in real life because everything is mutable, everything is a ship of Theseus, names/addressses/everything changes. So we've turned to artificial keys for primary keys and out of momentum most of these artificial keys are simple auto-incrementing numbers and a dumb part of brain looks at simple auto-incrementing numbers and thinks "I understand these" and "I see the patterns in these" and runs off and starts using them everywhere for business logic and corporate procedure and potentially information disclosing URLs and so forth.

(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.)

[wruza]

This is correct. There are some sensible business defaults, but pure debit and credit have no specific meaning. It’s just yet another analytical dimension handily entangled with double-entry.

This fact is rarely mentioned in business talks so people have a whole variety of ideas what they mean, as you can see itt.

[rahimnathwani]

> I prefer not to ascribe semantics to accounting credit/debit

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).

[fuckstick]

> Debits/credits concepts can exist (and we can operate on them) without the existence of left/right columns.

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?

[tunesmith]

That seems uncharitable - the person you're replying to is saying that debit/credit are more than fundamentally abstract, and that they have conceptual meaning consistent across all accounts.

[onefuncman]

> conceptual meaning consistent across all accounts.

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.

[rahimnathwani]

"they have conceptual meaning consistent across all accounts"

I like this phrasing. I wish I had used it!

[Max-q]

> This seems incorrect to me.

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.

[rahimnathwani]

"That’s because the system is not built by programmers."

That's definitely not the reason I consider GP's comment incorrect.

(I'm a qualified accountant.)

[tunesmith]

That makes sense to me in terms of assets and liabilities, but when I read https://beancount.github.io/docs/the_double_entry_counting_m... and it described income as being negative and expense as being positive, it broke my brain a little bit.

[groby_b]

Very simple explanation: Entries in double-entry accounting always need to balance - you need two.

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.

[rahimnathwani]

Maybe the following will help. It might not click immediately but, when it does, there will no longer be any need to memorize what debits/credits are in the context of each of assets/liabilities/equity.

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).

[juped]

That's because it's just wrong, like everything from the docs of ledger and its descendants (and every "accounting for developers" article, except surprisingly not TFA here!), and accountants are just correct to use unsigned numbers.

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.

[tunesmith]

This makes a lot more sense to me. Source and sink. And I think illuminates why double-entry is confusing to non-business individuals, because we don't tend to think of Accounts Receivable for our persons.

[rapht]

An income is something you owe to your shareholders. So if you think of what you own as (+) and what you owe as (-), which is how debut/credit is conventionally shortcut, an income is a negative number.

[tepitoperrito]

I think (would love to know if I'm wrong) of it as: debit => from, credit => to

[joshjje]

In my thinking, as a programmer, debit = positive, and credit = negative. NOW, what type of account those are going to like others have said changes things, but fundamentally if you are adding a positive amount to an account thats a debit, and if you are adding a negative amount thats a credit.

[rahimnathwani]

I don't understand what you mean well enough. So you might be right or you might be wrong :)

Can you share a couple of example (or maybe use the same examples I did)?

[lhuser123]

It depends. You really need the context.

[datavirtue]

You just look silly trying to build financial software without understanding and implementing double-entry or ledgers. You have to know when to employ debit and credit nomenclature and be able to easily explain the reactions in the system...or you look silly. Sort of like when accountants start talking about databases and APIs without proper training.

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.

[astrange]

Why don’t they like currency symbols?

[jwarden]

It's correct that "debit" and "credit" don't have to do with "owing/being owed" money. But they do have to do with "OWNing/being owed". This apparently subtle difference provides powerful insight.

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

A debit either increases money OWNed on the left side of the balance sheet, or decreases money OWEd on the right side.

[kinleyd]

Sadly, I gave up accounting in high school after failing to reason through the meaning of 'credit' and 'debit' (Yes, I went in too deep!). My epiphany came in B-school when I tackled it again, when I finally figured out what your instructor summarized.

[marcosdumay]

Yep, you debit or credit an specific account, and to make things extra confusing, a debit on one account is always the same as a credit on a different account (and the other way around).

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.

[bgro]

It gets really confusing when you talk about "in the red" or the black / red coloring and it depends on which side of the books you're on for what it means. I get this mixed up with electrical engineering every time now. I never feel comfortable jumping a car.

"Red means positive, as in I'm positively sure you owe me a lot of money."

[CSMastermind]

I was lucky enough to work on a billing system early in my career and pick up some rudimentary knowledge of accounting. I can confirm that even being able to 'speak the language' a little bit provides immense value to you as a developer.

[Mezzie]

Also can confirm as an accountant's kid.

It's kind of like being given a cheat code.

[2143]

> Sometimes non-accounting people get hung-up on the words "debit" and "credit"

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.

[jlokier]

> If $10 comes into my bank account, I get a message saying "$10 was credited into your account".

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.

[EvanAnderson]

On the bank's books your account is a liability (money the bank owes you). Simplistically, when you deposit money the bank's cash balance is debited and your account is credited.

[tantalor]

> debit is the entry in the left column, and a credit is an entry in the right column

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.

[0xdeadbeefbabe]

What is super powerful about thinking of income as a credit account?