Accounting Entry

An allocation of a sum of money

22 January 2005

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.

I withdraw $100 from my checking account on Tuesday. This would be an accounting entry whose amount is $100, whose date is Tuesday, and whose descriptor is my checking account.

A contractor spends $300 on electrical supplies for work on my house on Saturday. This would be an accounting entry whose date is Saturday, amount is $300 and descriptors are the project for the work on my house, and the cost category of electrical supplies.

Three barrels of Old Peculier are delivered to the Square and Compass. This would be an accounting entry whose amount is a three barrels (a quantity) and whose descriptors were Old Peculier and the Square and Compass.

Accounting revolves around money, and is essentially about the classification of money: where it comes from, what it is used for, even what it should be used for. From renaissence days the way of recording this is the entry in a ledger, in those days a physical book. Such entries record money coming and money coming out. They also record things that don't actually result in any handover of money at all, such as transfers.

How it Works

The pages of the ledger corresponds to a particular classification of money, these days they would be called accounts, so Account often goes with Accounting Entry. Indeed in Analysis Patterns I put them in the same pattern. But this is not always the case. Some see entries without accounts, some all entries as just parts of accounts. I'll talk about the case where they are closely joined in Account, until then just think of accounts as one possible descriptor for an entry.

It's not a stretch to think of an entry as something interesting that affects the domain, so it may well be that Domain Event applies to Accounting Entry. Sometimes I see this, sometimes I see the two separated. The important thing is that you need to ask the questions raised by Domain Event when you are using Accounting Entry. (Should the entries be immutable? Which dates should they have?)

Often there are specific rules for when an entry can be changed. It may be allowed to change entries when they are in an open state, but not to change them when they are closed, or booked.

In a particular model, you will usually model the descriptors as separate classes with separate relationships to the entry. So if we are doing job costing, we might want to mark each entry with a project and a cost type. The project and cost type are the descriptors for the entry. In our model we would show these as separate relationships as in Figure 1.

Figure 1: Project and cost type as descriptors.

Using Event Sourcing

Event Sourcing works particularly well with Accounting Entry because you can represent all accounting changes from an event as a set of newly created Accounting Entry. If you then link the Accounting Entry to the Domain Event that caused them, that allows you to quickly form a link between the Domain Event and its consequences. Not just does this make a strong audit trail, it also allows you to easily carry out the processing needed for Retroactive Event.

Figure 2: Connecting a Domain Event to all the Accounting Entry created due to it helps auditing and later processing.

When to Use It

You should use entries whenever you need to record each change in some quantitative value. The most obvious case is record all changes in a monetary value, and indeed this is the common case as money is sufficiently central to most businesses to require this level of tracking.

The pattern suggests the most common case, where entries are made for monetary amounts. However you can use this pattern whenever you want to classify quantities of something or indeed anything that contains differences, such as diffs in source code control system. Doing this sounds dangerously like using some over-generic model to model anything. Such over-generic models are a dangerous mermaid, whose beauties lure many many an analyst to an annoying, if not exactly fatal, variation on drowning. But the value of the abstraction lies in whether other patterns that build on Accounting Entry make sense. So bear it in mind as a possibility, just make sure you can swim first.

Example: Simple Example (Java)

In its simple state, Accounting Entry is mostly a simple data holder.

interface Entry {
   Entry newEntry (CostType costType, Project project, Money amount, Date date);
   CostType getCostType();
   Project getProject();
   Money getAmount();
   Date getBookingDate();

The descriptors will usually appear as explicit types in any particular application of the pattern.

Entries may often be immutable at all times or they may be mutable until they are booked. This would lead to setting methods along the lines of:

    void setCostType (CostType arg) {
       if (isOpen())
        costType = arg
       else
        throw new ImmutableEntryException();
    }