
A Software Architect's View of the Design of Double Entry Accounting (2012) - Dobbs
http://ledgersmbdev.blogspot.com/2012/08/a-software-architects-view-of-design-of.html
======
lchengify
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.

~~~
sorbits
_> […] 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.

~~~
vonmoltke
> 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.

------
tzs
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...](http://martin.kleppmann.com/2011/03/07/accounting-for-computer-
scientists.html)

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

~~~
vdm
[http://nothing.tmtm.com/2006/09/using-a-wiki-as-an-
accountin...](http://nothing.tmtm.com/2006/09/using-a-wiki-as-an-accounting-
system/) [http://nothing.tmtm.com/2006/09/more-on-accounting-
wikis/](http://nothing.tmtm.com/2006/09/more-on-accounting-wikis/)

------
zrail
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](http://www.ledger-cli.org)

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

------
hoipaloi
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.

~~~
hoipaloi
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?

~~~
Shorel
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.

------
tatterdemalion
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.

~~~
roel_v
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).

~~~
nasmorn
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.

~~~
roel_v
Ah, thanks for that.

------
fsk
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.)

------
jboggan
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.

------
contingencies
_...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.

~~~
Glyptodon
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?

~~~
contingencies
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.

