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