|
|
|
|
|
by kgwgk
2148 days ago
|
|
I do understand the difference between debit and credit. The point is not whether you can balance the books looking at them when they fit in a single page. The point is that in a balance sheet assets appear as $x (where x is rarely negative, an asset with negative value would become a liability). People want assets to be positive in the balance sheet. This may be a convention but it's a reasonable convention. I don't think you're helping developers who try to understand accounting by telling them that assets are negative quantities (it may make sense as an implementation detail, but not so much as an accounting concept). |
|
1. positive numbers represent the default for an account (A positive number in a debit account is a debit, but a positive number in a liability say, is a credit). This is done a lot. But he causes a lot of rules about when to add and went to subtract what the balance with what. I think this is why they lot of double entry bookkeeping and has a hard reputation. Certainly if you coded it you would have to code all those rules manually.
2. The approach I'm used to of having negative numbers in the debits and positive credits. This makes all the double accounting balancing much simpler. But I can see it may confuse some people when assets are negative.
3. Make credits at the beauty of an debits positive (incidentally I only today learned that beancount does it this way). Again balancing and double-entry accounting becomes simpler. Now money in the bank would be positive, like your bank statement. But sales income would be negative (it is a credit). I wonder if that would confuse people.
So maybe that's why UI should make everything positive and undifferentiated. But given the amount of time the Accounting 101 has to drill in all the rules of what