4 ms·

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

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

Max-q 4y ago
> 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 4y ago
  "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.)
tepitoperrito 4y ago
I think (would love to know if I'm wrong) of it as: debit => from, credit => to
- lhuser123 4y ago
  It depends. You really need the context.
- rahimnathwani 4y ago
  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)?
- joshjje 4y ago
  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.
EvanAnderson 4y ago
> > 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 4y ago
  "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 4y ago
    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 4y ago
fuckstick 4y ago
> 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 4y ago
  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.
  - rahimnathwani 4y ago
    "they have conceptual meaning consistent across all accounts" I like this phrasing. I wish I had used it!
  - onefuncman 4y ago
    > 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.
redandblack 4y ago
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.
- rahimnathwani 4y ago
  > 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).
- jessaustin 4y ago
  ...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 4y ago
    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.)
tunesmith 4y ago
That makes sense to me in terms of assets and liabilities, but when I read https://beancount.github.io/docs/the_double_entry_counting_method.html#introduction 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.
- rahimnathwani 4y ago
  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).
- rapht 4y ago
  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.
- groby_b 4y ago
  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.

Max-q 4y ago

> 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 4y ago
"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.)

tepitoperrito 4y ago

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

lhuser123 4y ago
It depends. You really need the context.
rahimnathwani 4y ago
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)?
joshjje 4y ago
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.

EvanAnderson 4y ago

> > 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 4y ago
"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 4y ago
  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 4y ago

fuckstick 4y ago

> 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 4y ago
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.
- rahimnathwani 4y ago
  "they have conceptual meaning consistent across all accounts" I like this phrasing. I wish I had used it!
- onefuncman 4y ago
  > 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.

redandblack 4y ago

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.

rahimnathwani 4y ago
> 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).
jessaustin 4y ago
...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 4y ago
  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.)

tunesmith 4y ago

That makes sense to me in terms of assets and liabilities, but when I read https://beancount.github.io/docs/the_double_entry_counting_method.html#introduction 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.

rahimnathwani 4y ago
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).
rapht 4y ago
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.
groby_b 4y ago
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.