Accounting for Computer Scientists (2011) • Hacker News Board

Re: Accounting for Computer Scientists (2011)

#61

Post by dagss » Sat, Jan 03, 2026, 5:10 PM UTC

jltsiren wrote: post #54

dagss wrote: post #40

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 n…

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.

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.

Re: Accounting for Computer Scientists (2011)

#62

Post by jltsiren » Sat, Jan 03, 2026, 5:52 PM UTC

dagss wrote: post #61

jltsiren wrote: post #54

Earlier quoted context omitted.

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.

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…

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.

Re: Accounting for Computer Scientists (2011)

#63

Post by fuzztester » Sat, Jan 03, 2026, 6:39 PM UTC

ciju wrote: post #31

NikolaNovak wrote: post #9

I never understood double entry bookkeeping and that's where the author immediately loses me again: Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative" There is something so obvious about this to accounting folks that they always make the massive jump without any explanation. The previous diagram absolutely does not have positive and negati…

We wrote about it here: https://finbodhi.com/docs/understanding-double-entry It's just a convention to be able to capture the flow of money. Roughly, money comes in via Income, stays in Asset, goes to Expense (there is also Liability and Equity). Let's consider a home, as an asset. You could have got it with your own money (`Asset:Bank -> Asset:House`), or by taking a loan (`Liability:Home Loan -> Asset:House`). Both…

Hi, your compound interest article on ciju.in was good.

Any way to contact you to talk?

Re: Accounting for Computer Scientists (2011)

#64

Post by dagss » Sat, Jan 03, 2026, 7:28 PM UTC

jltsiren wrote: post #62

dagss wrote: post #61

Earlier quoted context omitted.

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…

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.

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.

Re: Accounting for Computer Scientists (2011)

#65

Post by gamblor956 » Sat, Jan 03, 2026, 7:28 PM UTC

dagss wrote: post #37

gamblor956 wrote: post #34

Earlier quoted context omitted.

This website is absolutely nonsensical and I would not recommend it to anyone to understand how GAAP or IFRS accounting works. It might be useful for someone wanting to learn unicorn fantasy land accounting. Double-entry accounting is basically checksum. For any transaction, the total in and out of all accounts involved in the transaction should be zero. If it's not, you have an error. Conceptually, one of the hard p…

This website that you call nonsensical was a huge help to me when starting to learn about accounting systems. And I have spent several years of my life working on a (special purpose, non-generalist) accounting system. The important thing is just a shift of perspective. It is just a different way of viewing the same system. The website doesn't contradict the things you write about at all. Saying "double entry book-kee…

I literally deal with accounting every day. I have used all of the major ERPs and implemented several of them, including Oracle, Netsuite, and Workday.

This website would not help a layman (i.e., non-accountant) or accounting student understand accounting, at all.

My issue with the website is not the use of credit/debit vs negative/non-negative numbers. My issue with this website is that it presents transaction flows without properly explaining the accounting logic of those transaction flows to its intended audience and even then it's way of framing transaction flows only works for the simplest transactions. The website's chosen way of explaining accounting would be actively harmful to understanding more advanced accounting issues. It would be like trying to teach someone how the internet works by framing everything in terms of plumbing.

Re: Accounting for Computer Scientists (2011)

#66

Post by jltsiren » Sat, Jan 03, 2026, 8:10 PM UTC

dagss wrote: post #64

jltsiren wrote: post #62

Earlier quoted context omitted.

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.

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 c…

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.

Re: Accounting for Computer Scientists (2011)

#67

Post by tejohnso » Sat, Jan 03, 2026, 8:51 PM UTC

msaadat wrote: post #50

NikolaNovak wrote: post #9

I never understood double entry bookkeeping and that's where the author immediately loses me again: Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative" There is something so obvious about this to accounting folks that they always make the massive jump without any explanation. The previous diagram absolutely does not have positive and negati…

The "double entry" stems from the fundamental accounting equation: assets = liabilities + equity. Whatever you have is either yours or borrowed. Change in one must have an equal change in the other to keep the equation balanced, otherwise you would lose track of how much you own and how much you owe. For example, you have £200 in cash. £100 was your own earnings, £100 your mum gave you to pass on to someone. In pure…

> Double entry tracks ownership explicitly: £100 would be recorded in Equity and £100 in Payables.

Isn't it more about showing the -100 in the mum account and the -100 in the company account so that everything balances to zero?

Re: Accounting for Computer Scientists (2011)

#68

Post by oasisbob » Sat, Jan 03, 2026, 9:14 PM UTC

TuringTest wrote: post #44

Havoc wrote: post #17

Earlier quoted context omitted.

>I never understood double entry bookkeeping It only makes sense in the context of a company. Yes you can shoehorn it into a personal context and/or treating it like some sort of database like hn's accounting posts love to do but that's not what the real accounting world looks like at all. An accountant armed with a low/no code solution isn't going to write great code. That I think is obvious to every hn reader. But…

> I know a decent bit of both worlds so that disconnect in perceptions always amuses me. Double-entry bookkeeping was from its inception an error-correction code that could be calculated by hand. Modern databases contain much more powerful error correction methods in the form of transactional commits, so from a pure technical point, double-entry bookkeeping is no longer needed at all; that's why programmers have a ha…

> from a pure technical point, double-entry bookkeeping is no longer needed at all

Just because databases are transactional doesn't mean the entire system is. Double-entry accounting still helps catch errors.

A concrete example, since people like to think databases dealing with money are especially transactional, when they're not ...

I used to work at a small regional bank. In the course of some network maintenance, I accidentally disrupted the connectivity to an ATM while a customer was doing a transaction.

The next day, our accounting folks caught a problem with reconciliation, and the customer called to follow up as well. My interruption caused a deposit to proceed far enough to take their checks and money, but failed to credit the customer's account.

It's very hard to orchestrate transactions perfectly across multiple organizations and systems. You can't hand-wave this away by pointing at db consistency guarantees. Traditional accounting techniques will catch these errors.

I'm not sure that ATMs even have the ability to communicate certain failure classes back to the acquiring bank. eg, a cash dispenser malfunction is common enough to be mentioned by VISAs network rules explicitly, but as far as I know will almost always require manual reconciliation between the ATM operator and the network.

Re: Accounting for Computer Scientists (2011)

#69

Post by adamcharnock » Sat, Jan 03, 2026, 10:06 PM UTC

phil-martin wrote: post #26

adamcharnock wrote: post #15

Earlier quoted context omitted.

I wrote this a long time ago. It does tend to upset some people, but it did work as an accurate and testable mental model: https://django-hordak.readthedocs.io/en/latest/accounting-fo...

Thank you for writing and sharing that. It's one of the simplest and sane explanations I've seen. How did discussions go with accountants separating the debits/credits into being a presentation issue?

Well, they didn’t like it! :) I considered just providing views onto the tables that would present the data in the way that made the accountants happy. But in the end we just ended up changing to using separate debit/credit columns. They managed to talk me around somehow, but I don’t remember the details any more. I think this was the relevant issue:

https://github.com/adamcharnock/django-hordak/issues/59

Re: Accounting for Computer Scientists (2011)

#70

Post by ErroneousBosh » Sat, Jan 03, 2026, 10:38 PM UTC

cryptonector wrote: post #32

NikolaNovak wrote: post #9

I never understood double entry bookkeeping and that's where the author immediately loses me again: Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative" There is something so obvious about this to accounting folks that they always make the massive jump without any explanation. The previous diagram absolutely does not have positive and negati…

It's like Newton's third law of motion, that "every force has an equal and opposite reaction", which when I was a wee child made no sense to me because "surely then nothing would happen". The key was that the equal and opposite reactions are on different objects. It's the same thing with double entry accounting! The two entries are on different accounts.

> which when I was a wee child made no sense to me because "surely then nothing would happen"

I've literally just had this conversation today about jet aircraft with my 5-year-old, and how when you push air out of the jet engine really fast, that action pushes the nozzle forwards - it's not pushing against anything, it's like if you push against the sides of a box.

But he's still not quite got it, so we're going to go to the workshop and play with a high-volume fire pump.