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