[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