Blog ·
Reversal is not deletion
Reversing a payment is not deleting a payment. That distinction is most of what separates a business system from a CRUD app — and 'we'll add undo later' is rarely true.
Reversing a payment is not deleting a payment. That distinction is most of what separates a business system from a CRUD app — and it took me a while to feel it rather than just know it.
When money moves, several things happen: an instalment gets settled, a balance changes, a document changes state, maybe a cheque is now committed. Undoing that isn’t removing a row: it’s a second operation that reverses each of those effects, with its own date and its own author, leaving both events visible.
Why it has to work that way
- Someone saw the first state. A report was run, a statement was sent, a decision was made. Erasing it makes the system disagree with things people already have.
- The reversal is itself a fact worth auditing. When it happened, who did it, and ideally why.
- The arithmetic has to close. If the balance is derived from movements, the reversal is the movement that brings it back — not the absence of the original.
The consequence everyone underestimates
Reversal is a first-class operation, as complex as the original and often more — because it has to handle the states the original didn’t anticipate. Reversing a payment that’s already been partly reallocated. Reversing a delivery after the goods left.
Every “undo” in a business system needs its own preconditions: what state must things be in for this to be reversible at all, and what do we do when they aren’t.
Which is why “we’ll add undo later” is rarely true. It’s not a feature on top of the operation: it’s half of the operation — and it’s the half that gets designed last and used under pressure.