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

[rahimnathwani]

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

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