Replacement Adjustment
Adjust a set of incorrect accounting entries by deleting them and replacing them with the correct entries.
29 December 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.
How it Works
Errors are an inevitable part of any human activity, computers allow us to make larger errors more quickly. In an accounting context these errors show up as Accounting Entrys with incorrect values, perhaps even entries that shouldn't be there and entries that are missing.
When we find these errors we need to fix them. Using accounts give us a particular structure which allow us to clearly find and fix these kinds of errors.
There are three stages in making an Replacement Adjustment: finding the erroneous entries, determining what the correct entries should have been (the hindsight entries) and then making the adjustment to the account to fix it. With Replacement Adjustment the adjustment is simply deleting the erroneous entries and creating new hindsight entries.
How you find the erroneous entries, and how hard it is to find them, depends very much on how you design your system. If there's been no thought to error correction, it could mean quite an exercise of trawling through logs. There's little I can really say about this task in general.
A way to make all of this easy is to use Event Sourcing for your accounts. This way each Accounting Entry is tied to the Domain Event that caused it. It's usually easy to narrow down which Domain Events led to the problem and then follow the links to determine the erroneous entries.
The next task is to determine the hindsight entries. You can do this with a one-off calculation by hand, excel, or a script. One-offs are a good technique if the adjustments are rare. Another way to do it is to use the system itself by building a Parallel Model. You can make a Parallel Model with all the corrections in place, process the events and query the model to determine the hindsight entries. If you are able to compare accounts between the corrected model and the original you can use this mechanism to find both the incorrect and hindsight entries.
Once you have identified the incorrect and hindsight entries then making the adjustment is simple. You delete all the incorrect entries and create the hindsight entries.
When to Use It
Replacement Adjustment is one of three patterns for account adjustment, the others are . Replacement Adjustment is the simplest of the trio, but its weakness is that it deletes the erroneous entries, thus distroying the history of the old event. In some cases, such as when you've issued a payment from the account, this won't work because you lose the background for the payment. So Replacement Adjustment is a good technique to use when you don't need for history, but that's the limit of its usefulness.
Often you'll find that entries can be deleted within a certain time period, but then need to be fixed. If you send out a monthly bill, you may be able to use Replacement Adjustment until you send out a bill. After that you have to use one of the other techniques.
If you are using Event Sourcing you don't lose all history since you can regenerate the deleted entries in a Parallel Model. This may be sufficient for your needs, in which case you can use Replacement Adjustment more widely.