Adjusting Transactions

Even accountants make mistakes. In the old days, each account had a list of transactions, with running totals. A new transaction was added to the end of the list, and the running totals were updated. It was easy to go back to any day and see what the running totals were then, and easy to add a new transaction. However, it was hard to undo a transaction, or to post a transaction out of order. Deleting or changing a transaction would require updating all the running totals after that transaction, which was very hard when they were written in a book in ink. Correcting arithmetic mistakes was bad enough, but changing the transactions themselves would destroy the audit trail that transactions were originally designed for.

Therefore: never change a transaction once it has been posted, but instead post a new "adjustment" transaction to carry out the change.

The result is that most accounts have three kinds of transactions: one that makes them get bigger, one that makes them get smaller, and an adjustment transaction. Ideally there will be few adjustment transactions, but they always seem to be necessary.

I always thought that "adjusting" transactions made the balance of the account get bigger or smaller. I think that the only difference between a "normal" transaction and an "adjusting" transaction is the reason for making the entry. -- ShalomReich

True. However, isn't your statement just confirming that the only difference between the two transactions is the reason (i.e. description) for that transaction?

For example - If I have multiple accounts with my bank, some of which (savings) the bank pays me interest and some of which (loans) I pay the bank interest. If I adjust the amount of interest received from the bank downward (because of a previous error in which I added $100 due to a typo), how does this transaction differ from one in which I pay $100 interest on my loan account?

-- ShalomReich

Interesting stuff can fall out of this pattern.

To take a very non-hypothetical case: I was just asked to generate trend graphs for our bug tracking software. The significance of `I was just asked' is no one had collected any historical data. Uh-oh.

However, our bug tracking software has something like AdjustingTransactions. That, eighty lines of Perl, a couple of dozen lines of shell script (for computation, plus about another hundred or so for user interface; can you say ``OverEngineering''?)-:, and I had historical trend data back from June 1995.

I've used similar tricks to collect tool usage data to predict how many licenses we need (and which licensing schemes are the most expensive!)

-- PaulChisholm

After some more thought I came up with a reason why AdjustingTransactions are different from BusinessTransactions - they are related to a prior transaction (or transactions). In a system with a good audit trail this linkage can be followed. -- ShalomReich

Question: What if the effects of one transaction were dependent on the effects of another transaction? The adjustment would only change the account attributes, not the chain of effects. You then need to manually (???) post adjustments for every effect that needs to change. -- NoahClements

I assume you are discussing the following type of example:

If the interest due for an account depends on the average daily balance in that account, an adjustment to the balance should also trigger an adjustment to the interest paid since that point in time.

Most systems I have seen embed these rules in code or create special tables to encode these rules for each situation that the designers considered.

I believe that the Accounts system by RalphJohnson (http://st-www.cs.uiuc.edu/users/johnson/Accounts.html) addresses this type of problem by having such dependencies defined in the posting rules. The posting rules may include a "function of time" in their formulas to take care of situations similar to the one I described above.

ShalomReich 4/15/96

I guess the type of situation I am referring to, still using the bank example, is where in processing checks for the account, it gets overdrawn. There is a $15 fee charged to the account. Later, it is discovered that there was a deposit that should have been credited to the account, but wasn't. When it is posted (back-dated), the fee needs to be reversed, but that would not be part of the normal posting rules of a deposit. The withdrawals (with an effective date after the deposit) may need to be backed out and re-applied. This would have the effect of reversing the fee because it was backed out, and when the withdrawals were re-applied, the account was seen to have a sufficient balance.

Is there something special in the framework which would eliminate the need for reprocessing, as in the above example? I hope that this is somewhat coherent. :-| -- NoahClements

A friend of mine worked for Delta doing frequent flyer mile award programs. That is an accounting system with a vengeance. People are often sending in past-earned miles late, and the rules for crediting miles and awards are constantly changing. So he put in Events, which cause amounts to change, and, to speed up calculations, put in occasional snapshots of the balance. Indeed, a newly posted, but old event could change subsequent events, like mile awards based on account balance. He eventually got to making an OO rule system to manage the shifting rules. Anyway, there is an example of events affecting other events. -- AlistairCockburn

It doesn't always make sense to replicate manual systems to computers. Adjustment transactions in many ways are replicating a manual system to a computerized system. One of the important things an accounting system does is to provide an audit trail. It is important not to delete accounting entries. This is the ink part of a manual system. However, it doesn't follow that you post the delta between what you wanted to have happen, and what was recorded. Its much better to post a reversing transaction, linked to the orignal, and then post what should have happened. Then it becomes easy to extract any view from the accounts.

The views you can extract with the right combination of date attributes on entries are as follows:

A complete audit trail, including the corrections
A view as to what the accounts were, if printed, on any date in the past.
A view as to what the accounts should have been on any date in the past.

With an adjustment, you have to decide what to aggregate. It's very messy.

-- Nick Leaton