Accounting Transaction

This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and I won’t be doing any corrections or updates until I’m able to find time to work on it again.

Luca Pacioli may well be to accountants what Galleio is to
physicists. He was a franciscan monk who first described one of the core ideas of
accountancy: double entry bookeeping. The idea behind double entry
bookeeping is quite simple, every withdrawel must be balanced with a
deposit. Thus everything you do to books has two elements, the
subtraction from one account, and the addition to another. In this way
money is conserved much like physicists conserve energy. For an
accountant you cannot create money, it is only ever moved around.

How it Works

When we use transactions there are actually two kinds that you
run into. A two-legged transaction only ever has two entries, which
are of opposite sign. This is very literally a single movement from
one account to another. A multi-legged transaction allows any number
of entries, but with still the overall rule that all the entries must
sum to zero, thus conserving money.

Figure 1: An example of a two legged
transaction

Figure 2: Class diagram for a
multi-legged transaction, notice that the only difference is the
multiplicity of the association: accounting transaction ->
entry

Figure 3: An example of a multi-legged
transaction. This might represent a situation where I have two checks
which I pay into my bank account with one deposit slip.

Two-legged transactions are the easiest to work with, so if
that's the way the business works, it's not worth trying to build
multi-legged transactions even though you can support a two legged
transaction with a multi-legged transaction.

With a two-legged transaction the entries are optional - you
can choose to have all the data on the transaction. This works if the
two entries really are only different in the sign of their amount.
When I lived in Britain it was always the case that it took three days
to do a transfer from one account to another. So even if I transferred
money from my checking (current) to my savings (deposit) account at
the same branch, the withdrawel from my checking account would
occur three days before the deposit to my savings account. In this
case we would need the entries so we could record the separate
dates.

Figure 4: A class diagram for an
accounting transaction without entries

With a multi-legged transaction often the difficulty lies in
how to create the transaction. A two-legged transaction can be created
in one operation quite easily. However a multi-legged transaction
takes a bit more effort. So it's worth using Proposed Object to
build up a transaction before you post it propertly to the appropriate
accounts.

When to Use It

To answer this it's worth thinking about why double-entry
bookeeping was seen as such a good idea in the first place. Basically
it all rests on finding and preventing leaks, or in other words
combatting fraud. Without double-entry bookeeping it's too easy to
just allow money to appear and dissappear misteriously. Now, of
course, double entry keeping doesn't eliminate all fraud, but it makes
that little bit easier to find which is enough that people use it.
Indeed it's grown to be so deep in the fabric of accounting that
people use it without thinking of it.

This doesn't mean you should always use Accounting Transaction. In many ways your use of this pattern depends on whether the
people in your domain use the pattern. For a start it really only
makes sense to use Accounting Transaction if you're using Account. So if you find you don't use Account you won't use
Accounting Transaction either.

Another reason not to use Accounting Transaction is when
all the entries are made by the computer. The logging and traceability
of this may well satisfy all leak chasing desires. Since you can
examine the source code and the database logs, that gives you as
plenty of leveridge - using Accounting Transaction would not
provide much more.

So you should be driven by your domain experts as to when to
use the pattern. In particular you shouln't use it as an extra feature
if the domain experts don't feel it's necessary. Like many patterns
Accounting Transaction adds complexity to a system, and
complexity adds it's own price.

Two-Legged or Multi-Legged?

If you decide to use Accounting Transaction you then
have to decide whether to use the two-legged or multi-legged versions.
Multi-legged transactions give you the greater flexibility to support
entries where a single deposit can be sum many withdrawels or
vice-versa. However many applications don't want that because their
domain only has two-legged transactions. Multi-legged transactions are
also a good bit more complicated. So only use multi-legged
transactions if you definitely need their functionality.

It's easy to make multi-legged transactions support
two-legged transactions, so it's usually quite easy to refactor from
one to the other later. So it's easy to start with two-legged and
change to multi-legged later on. The reverse is also quite
straightforward, but it's better to start with the simpler if you're
not sure.

Example: Two Legged Example (Java)

I'll give you sample code for both the two-legged and multi-legged cases, starting with the simpler two-legged case.

Indeed the two legged case really just needs a simple
accounting transaction object.

With this you just need to make the constructor for entry to be
restricted so that you can't create entries other than in the process
of transactions. In Java this is a combination of package access for
the constructor and coding convention.

Rather than using accounting transaction constructor directly,
it makes sense to provide a suitable method on the account
object.

Example: Multi-Legged Example (Java)

The multi-legged case is a good bit more awkward since a
multi-legged transaction is more effort to create and needs
validation. In this case I'm using Proposed Object
so that I can put together the transaction gradually and then post it
to the accounts once I have all the pieces together.

With this approach I need to be able to add entries to a
transaction object through separate method calls. Once I have all the
transactions, then I can post the transaction to the accounts. I need
to check that all the entries balance to zero before I can post, and
once I've posted I can't add any more entries to the transaction.

In this case I'm using a different entry class to preserve
bi-directional associations between the entry and both the
transaction and the account. (Entries are immutable, which makes
it much easier to deal with maintaining the two-way links.)

All this set up and post business points to why it's so awkward
to use a multi-legged transaction. The good news is that if you
only need two-legged transactions some of the time, you can
implement the two legged interface with a multi-legged
transaction.