Patterns for Accounting

24 January 2006

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.

Although I know of no survey that's figured it out, I would believe that a very large proportion of the world's computer systems track money. If nothing else, I guess this means that money is valuable. Indeed it's so valuable that human beings have been obsessed with tracking money for hundreds of years, there's even a rather large profession (Accountancy) dedicated to it. (As a test you can tell if an organization cares more about something than money by comparing how many trackers of the other thing it has compared to accountants.)

One of the most fundamental concepts in accounting is double-entry bookkeeping, developed in medieval times and first documented by Luca Pacioli, an Italian friar, in 1494. Fundamental to this is that you keep track of various pots of money by carefully tracking every movement of money.

The pots of money are Accounts. Each Account has a balance, which is its current value, and a list of Accounting Entrys which represent every change to the Account. The value, or balance, of the Account is derived as the sum of all the Accounting Entrys. A balance can be calculated for now, but in general a balance is over some time period, in which case it sums the value of entries that were posted within that time period.

Figure 1: Basic model of accounts, entries, and transactions.

Accounting Transactions capture the transfers between Account more explicitly by linking together the Accounting Entrys involved in a transfer.

Although I've listed these as a common group of objects, much of these are optional. I've seen systems use Accounting Entry without Account or Accounting Transaction. Essentially Account acts as a descriptor for classifying Accounting Transactions; so it is possible to use other objects as descriptors. Similarly Accounting Transaction can be dropped if you are less concerned about careful tracking of transfers as Accounting Entrys.

Making Adjustments

Accounts keep track of the monetary consequences of events, which means they work very well with Event Sourcing. When a Domain Event is processed, it can produce a set of Accounting Transactions. If all Accounting Transactions are produced from processing Domain Events then the Accounting Transactions use Event Sourcing, even if other parts of an application aren't event sourced.

In this kind of situation, Accounting Transactions lend themselves naturally to automatic fixing of errors using Retroactive Event. To do this you need to find the Accounting Transactions that were produced by the erroneous event, determine what Accounting Transactions should have been produced, and then carry out an adjustment to change the erroneous set into the correct set. There are three ways of doing this adjustment.

I've concentrated here on automatic correction using Retroactive Event, but of course you can use these same adjustment approaches to record the results of a manual change.

Significant Revisions

24 January 2006: First draft