In business and IT exercises, there are 3 dirty words that all begin with "R":
- Reconciliation
- Retroactive
- Reversals
Reconciliation can be tedious under the best of circumstances. The best of circumstances being situations that were expressly designed, a priori, for reconciliation (e.g., balancing your checkbook). But often we find our ourselves performing reconciliations post-hoc, where there are many factors, small and large, that make it hard to reconcile.
Retroactivity is a problem because it just completely messes up baselines, timing and common-sense assumptions. It is also one of the things that makes reconciliation hard--those sneaky retro transactions can throw your compares off. [Date Warehouses may have very sophisticated timelining strategies, to allow reliable reporting of "as is" or "as of" (incorporates retroactivity) and "as was" (reproduce snapshot of the situation, as of a given date) states, from the same recordset.]
Reversals are a sophisticated and often complex form of logical delete. One reason they are challenging is just thinking of all the situations that require them. Then there is the question of what data has to accompany the reversal, in order to create the same state that would have existed had the transaction never happened--while still preserving a clear audit trail that the transaction did, in fact, happen. It is usually a quantity that is being reversed, but what related meta-data goes with it? And how do you make it clear that a given transaction is a reversal, while also trying to ensure that any computations or reports pull in all reversals? Reversals are one contributor to retroactivity.