Ross Anderson’s book Security Engineering (the second edition of which is now available online for free) is generally quite good; but it’s still possible to tell, from the varying quality of the chapters, which subjects he personally has a lot of experience with. One of these is banking; his chapter on banking security is extraordinarily good. It even explains the reason for double-entry bookkeeping.

Double-entry bookkeeping is basically the standard in the financial world. (The phrase is not to be confused with “keeping two sets of books”, which means having a second set of books with fake entries – the second set likely also in double-entry form, for a total of four entries for most transactions.) But though I’d seen the mechanics of double-entry bookkeeping described many times before, I’d never seen the point of it. Okay, each transaction is registered in two places – as a debit to one ledger and a credit to the other ledger. (The convention they use seems backwards: for example, if you have $100 in cash, the “cash” ledger gets assigned negative 100 dollars. But that’s just a sign convention: you can just imagine negating all the numbers, and then it makes sense. Or you can be an accountant for long enough that your brain gets wired backwards, and then it will make sense even as it is.) And okay, the system has the feature that all the ledgers have to add up to zero, which serves as a way of checking it. (To establish this feature, things like “profit” and “debt” ledgers are introduced for what otherwise would be money sources and sinks.) But what does this buy you? Well, obviously it buys you compliance with laws and regulations, which often demand that you use double-entry bookkeeping. But what is the point of those regulations? Why is this particular check likely to catch errors or fraud?

Anderson explains: where it makes sense is when you have a large company where each ledger is kept by a different person. (The system was invented in medieval Italy; one imagines a large merchant house with a room filled with scribes, each taking care of his own ledger as other people stream in and out telling them what has been bought and sold.) Then, with double-entry bookkeeping, one person can’t fudge the books on his own; two or more people have to collude.

When the whole system gets put onto a computer, that advantage usually goes away, since the computer (or whoever subverts it) can fudge two ledgers as easily as it can fudge one. Another advantage of the system, back in the pre-computer era, was that the supervisory effort was minimal: just the boss going around at the end of the day, adding up all the ledgers and raising hell if the total wasn’t zero. With a computer there is no point in minimizing the supervisory effort, at least not the part of it that the computer does: even elaborate schemes involving lots of cryptographic signatures would scarcely strain a modern computer.

Still, there’s something that actually used to make sense, there. Anderson writes as if it still can make sense, but it’s hard to see how: your software would somehow have to be organized so that different ledgers lived in different trust domains – say, on different computers administered by different people. For a large multinational company, that might even be a natural thing to do; but for others it would take a lot of extra effort – much more than just buying a “double-entry bookkeeping” software package in order to computer-whip the regulations.

In any case, as traditions go, this is not a particularly harmful one: the multiple ledgers can be useful for categorizing expenses and revenues; and in the process of eliminating the ancient security advantages of the system, modern accounting software also eliminates the inconvenience of having to enter everything twice.