4 ms·

I read this article on HN ten years ago and it has been very important to me in a career working on a special purpose accounting (for automated reconciliation o

by dagss 9mo ago

I read this article on HN ten years ago and it has been very important to me in a career working on a special purpose accounting (for automated reconciliation of bank accounts of a payments processor). The biggest shift from conventional accounting is the use of negative numbers instead of debit/credit. I believe that accounting would have been a lot more accessible to professionals from science/math backgrounds if negative numbers had been used instead of debit/credit. I think biggest challenge to introducing negative numbers in accounting now is that people don't like the look of an income account accumulating a negative balance and the expense account accumulating a positive balance. But once you bend your mind around that it makes perfect sense...expense is where the money "went" (positive), income is where the money "came from" (negative). (The alternative sign convention would make cash on hand negative.) That said: Credit/debit does carry an extra bit of information, because you can put negative numbers as credit/debit to convey flow going the opposite direction of the usual one. (This can also be inferred from the accounts being credit-normal or debit-normal, just wanted to note it is not 100% the same model.) My Norwegian small business accounting system vendor (Fiken) has started to present data using +/- in addition to debit/credit columns, perhaps there is some adaption of signed numbers accounting happening..

jltsiren 9mo ago
I think the biggest challenge is that negative numbers are fundamentally a hack in this context. You don't have negative $100 in your bank account, and you don't pay negative $100 for something. Instead, you are $100 in debt or you receive $100, which is qualitatively different. Such qualitative differences should be represented using the type system.
- dagss 9mo ago
  Overdrafting accounts or negative balance in a bank account has nothing to do with what I was talking about. A negative number in my comment is just the "from" part of a flow. Just like in engineering, if you consider a dam, you can talk about the outflow as "-100 L/min" to indicate that the dam looses 100 litres per minute, for instance. That does not mean that the litres of water anywhere ever becomes negative. You do not say using negative numbers in engineering is a hack just because some numbers (like volume of water in the dam) is constrained to be positive. In accounting one instead talks about the dam being debited 100 L and the electric plant being credited 100 L. That is basically just a different way of spelling "minus". It is the same thing just using different words. And it is of course entirely possible to overdraft an account by debiting too much and get an invalid state entirely without negative numbers. Negative numbers are actually a "hack" (or useful invention) in engineering and everywhere else too. They don't actually "exist", it is an abstraction similar to imaginary numbers and real numbers. But all of these are useful.
  - jltsiren 9mo ago
    Negative numbers are a hack in the sense that they can be confusing, and it's easy to make mistakes with them. For example, I would interpret "-100 L/min outflow" as an indirect equivalent of "100 L/min inflow". To avoid confusion, you could drop terms "inflow" and "outflow" completely and talk about "-100 L/min (net) flow". Or you could separate the type and the magnitude of the flow.
    - dagss 9mo ago
      There's a difference between UI and code. In code, it is more complicated to do if (change.direction == OUT) { total -= change.value } else { total += change.value } than to simply use negative numbers and do total += change The same in accounting, it can in my experience often be convenient that your Entry database tables look like account amount --- --- income/sales -100 receivables +100 rather than account debit credit --- --- --- income/sales 100 receivables 100 The first one is just simpler, and you also get the nice graph properties (cuts, zero-sums, etc) discussed in the OP. Simpler database model, simpler code, less cases to test, easier to do ad hoc analysis queries, etc. Of course in the UI one can simply flip signs on credit-normal accounts to avoid displaying negative numbers if one wishes.
      - jltsiren 9mo ago
        Negative numbers are probably convenient, if your background is in a field, where numerical calculations are the norm. Traditional accounting is better justified from a mathematical perspective, as mathematics is more about definitions than calculations. There are usually multiple levels of abstraction in code. When choosing the one to use for a particular task, it's a good idea to prioritize both simplicity and conceptual clarity. Bad things often happen, when the two priorities disagree. And you should try to use the same terminology and same concepts as the user as much as reasonably possible. Otherwise it's easy to make wrong choices by thinking about the problem from a wrong perspective.

by dagss 9mo ago

jltsiren 9mo ago

I think the biggest challenge is that negative numbers are fundamentally a hack in this context. You don't have negative $100 in your bank account, and you don't pay negative $100 for something. Instead, you are $100 in debt or you receive $100, which is qualitatively different. Such qualitative differences should be represented using the type system.

dagss 9mo ago
Overdrafting accounts or negative balance in a bank account has nothing to do with what I was talking about. A negative number in my comment is just the "from" part of a flow. Just like in engineering, if you consider a dam, you can talk about the outflow as "-100 L/min" to indicate that the dam looses 100 litres per minute, for instance. That does not mean that the litres of water anywhere ever becomes negative. You do not say using negative numbers in engineering is a hack just because some numbers (like volume of water in the dam) is constrained to be positive. In accounting one instead talks about the dam being debited 100 L and the electric plant being credited 100 L. That is basically just a different way of spelling "minus". It is the same thing just using different words. And it is of course entirely possible to overdraft an account by debiting too much and get an invalid state entirely without negative numbers. Negative numbers are actually a "hack" (or useful invention) in engineering and everywhere else too. They don't actually "exist", it is an abstraction similar to imaginary numbers and real numbers. But all of these are useful.
- jltsiren 9mo ago
  Negative numbers are a hack in the sense that they can be confusing, and it's easy to make mistakes with them. For example, I would interpret "-100 L/min outflow" as an indirect equivalent of "100 L/min inflow". To avoid confusion, you could drop terms "inflow" and "outflow" completely and talk about "-100 L/min (net) flow". Or you could separate the type and the magnitude of the flow.
  - dagss 9mo ago
    There's a difference between UI and code. In code, it is more complicated to do if (change.direction == OUT) { total -= change.value } else { total += change.value } than to simply use negative numbers and do total += change The same in accounting, it can in my experience often be convenient that your Entry database tables look like account amount --- --- income/sales -100 receivables +100 rather than account debit credit --- --- --- income/sales 100 receivables 100 The first one is just simpler, and you also get the nice graph properties (cuts, zero-sums, etc) discussed in the OP. Simpler database model, simpler code, less cases to test, easier to do ad hoc analysis queries, etc. Of course in the UI one can simply flip signs on credit-normal accounts to avoid displaying negative numbers if one wishes.
    - jltsiren 9mo ago
      Negative numbers are probably convenient, if your background is in a field, where numerical calculations are the norm. Traditional accounting is better justified from a mathematical perspective, as mathematics is more about definitions than calculations. There are usually multiple levels of abstraction in code. When choosing the one to use for a particular task, it's a good idea to prioritize both simplicity and conceptual clarity. Bad things often happen, when the two priorities disagree. And you should try to use the same terminology and same concepts as the user as much as reasonably possible. Otherwise it's easy to make wrong choices by thinking about the problem from a wrong perspective.