| EAA-dev Home |

WORK-IN-PROGRESS: - this material is still under development

Patterns for Accounting

Last significant update: 24 Jan 06

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

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 Jan 06: First draft