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.
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 renaissance 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 correspond 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.
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.
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.
Microservices3