A Software Architect's View of the Design of Double Entry Accounting (2012) | Hacker News Reader

A Software Architect's View of the Design of Double Entry Accounting (2012)

ledgersmbdev.blogspot.com

79 pointsDobbs25 comments

I use double-entry bookkeeping as a metaphor when pitching software testing. It's particularly helpful with non-technical audiences who have backgrounds in law, finance, or accounting.

You write software tests for the same reason you do double entry: error detection of a technical system that has expected results. The only difference is that accounting has "real" numbers whereas software is algorithm definitions, so you have to plug in real values to run the tests.

It's also telling how similar (and unforgiving) both software and accounting can be. The mischaracterization of a column in accounting could be the difference between profitability and insolvency for your company. The mislabeling of a macro in your program could be the difference between correct execution and a segfault.

That is a great way of thinking about testing, and possibly even type systems. It really clicked with me, thank you for sharing.

> […] reason you do double entry: error detection

This is a misconception and if you think about it, it doesn’t make a lot of sense since the two records are generally generated by a system that gets a single value from the user, so it would be a software error if they did not even out.

Accounting errors are normally human errors, e.g. entering the wrong amount or specifying the wrong account, none of which are errors that double entry accounting will catch.

However, double entry accounting gives us an audit trail because it tracks how assets are moved between accounts, so if the balance of an account is not as we expect, we can go back and see exactly why it is what it is.

Double-entry accounting predates software implementations thereof. When writing values by hand into two different physical ledgers, it would serve as a limited form of error detection.

> This is a misconception and if you think about it, it doesn’t make a lot of sense since the two records are generally generated by a system that gets a single value from the user, so it would be a software error if they did not even out.

That applies to a software system, but not a handwritten ledger. In the latter, it does serve as an error detection mechanism because a human has to enter both values and other humans have to read them clearly.

You are correct, though, that the primary reason for double-entry is audit trail.

> However, double entry accounting gives us an audit trail because it tracks how assets are moved between accounts.

Ah, makes sense. My understanding of double-entry comes from history rather finance. I read a few articles on Italian history, specifically the Medici family with Florentine banks and hand-written ledgers. I'm not an accountant, in practice it makes more sense as an audit trail.

I guess you could stretch the metaphor further and say that a SCM + testing gives you the equivalent of double-entry. However in practice, I've never had much trouble convincing anyone to use a SCM :).

From the title, I thought it was a repost of something I had seen before, but it's not. What I was thinking of was "Accounting for Computer Scientists" [1], which explains double entry book keeping and profit and loss statements and balance sheets by formulating them in CS terms (directed graphs with accounts as nodes and transactions as edges). It was discussed on HN [2].

[1] http://martin.kleppmann.com/2011/03/07/accounting-for-comput...

[2] https://news.ycombinator.com/item?id=2298471

http://nothing.tmtm.com/2006/09/using-a-wiki-as-an-accountin... http://nothing.tmtm.com/2006/09/more-on-accounting-wikis/

If this is at all interesting to you, you should check out Ledger[1]. It's a command line double entry accounting system that generates reports from a lightly-formatted plain text file containing your transactions. I've been using it for years and have written a bunch of blog posts[2] detailing how I use ledger for personal (and now business) finances.

[1]: http://www.ledger-cli.org

[2]: https://www.petekeen.net/ledger

As an accountant turned programmer, I've noticed that my fellow software developers are terrible at understanding double-entry accounting and even worse at developing systems for accounting. This article uses a lot of words to not really say or explain much, if your aim is to know more about accounting look elsewhere, this article though factually correct confuses more than it informs.

As an example one thing he did specifically is to fixate on balance. Double entry accounting does is indeed a system for tracking balances of accounts but that's not all it does and it might be said that balances are a by product of what it really does. Double entry accounting tracks the flow of how money _moves_ through a system. Using double entry accounting you can get track the balances of accounts at a certain date _OR_ you can track the movement of money through accounts over a certain time period which we call an income statement. I've noticed that developers seem to fixate over the former without understanding that the latter is just as important. In other words it's not just important about how much money you have in an account but also how did the money get there?

I started a (now dying of bitrot for a couple years) accounting system in C++ that let you see your balance at every point in time.

All transactions were recorded as individual entries and every single one of them had to match for it to be processed.

So for a specific point in time, it was easy to simply re-run the transactions from last start to that point.

Some years ago I would have really appreciated the help of someone with your knowledge.

Right now I'm focusing on a videogame.

The blog entry is clearly not an accounting tutorial, but a historical overview of a process that led to current conventions.

I don't understand why the author is so fixated on the idea that "a business owns nothing for itself." The statement doesn't seem to mean anything, its just a confusion about what equity is. Equity is the value of the portion of the assets that are not owed to creditors (not liabilities); in some structures, the accounting of equity is divided between the multiple owners of the entity, but not always.

Double-entry bookkeeping is just this obvious fact, taken to a conclusion: every transactions of money is balanced; an equal amount of money is credited and debited in each transaction.

Yes, it's a terribly confused explanation of the concept 'equity'. For example it has no way of explaining the difference between the paid-in amount and par value of stock, as far as I can tell (is there a word in English for this difference, btw? In Dutch it's called 'agio' but I can't seem to find one specific word for it in English).

Agio is used in English as well. It is an Italian word denoting the difference of two numbers due to a diverging method of assessing it. It is thus most often used to denote the money banks keep in various transactions. The meaning you specify in Dutch is most closely related to the use of agio to name the difference of the face value of silver coinage and their real metal content.

Ah, thanks for that.

I think equity is the hardest concept in accounting for people to intuit. It's easy to understand what Assets and Liabilities are, and what Revenues and Expenses are. It's not even that hard to understand accrual concepts of depreciations.

When I teach basic accounting to colleagues, I usually start with the accounting equation:

    Capital = Assets - Liabilities

Then later I go on to explain that you can rearrange that equation:

    Assets = Capital + Liabilities

One way to think of that is that the sum total of everything the business has (Assets) has a claim on it from either creditors (Liabilities) or owners (Capital).

So, it's really true that the company owns nothing for itself.

A lot of people have difficulty getting their heads around double-entry and, therefore, accounting in general. Different explanations seem to work for different people.

For anyone looking for an intro to accounting, I highly recommend Frank Wood's "Business Accounting 1".

Lol, at my current job, their accounting system is designed so that all transactions modifications are an UPDATE or DELETE instead of an INSERT. It makes auditing impossible. At the end of the month, the numbers don't even come close to adding up.

(The correct way to design an accounting system is that, if a record is changed, you do an INSERT rather than updating the old record in place. Then there's always an audit trail.)

I've been taken aback in the Bitcoin world just how many programmers do not understand double-entry accounting and don't implement anything near it in their systems when they do any transaction that is not recorded on the blockchain (exchanges in particular come to mind). When you're moving around other people's money this is quite important.

...those of us who design and write software find that our approaches are relatively orderly but fragile. Aspects of a system fail to support each other, and we basically add complexity to the system in order to hold it together. Highly engineered systems are thus brittle

Honestly? I am more likely to conclude that the author is not yet very mature as a programmer.

Or has a distorted view of what "engineered systems" are.

Rather prideful response there.

Most systems I've ever worked with (I end up working on existing systems much more than implementing from scratch) are brittle somewhere in the sense of being potentially incompatible with some random enhancement X sans major rewrites. And when major rewrites aren't possible we resort to complexity.

As developers we're all aware of this and often refer to it as managing technical debt, no?

I was aware this could come across the that way when posting and am no paragon of perfection, but that doesn't change my perception. Technical debt is technical debt, and a brittle and complex system that evolves as a patchwork is just an admission of software development driven by bad process.

Reply on news.ycombinator.com