Ledgers, not columns: why balances should be derived

The quickest way to model a leave balance is a column holding the remaining days. It works immediately, and it fails the first time somebody disagrees with the number.

The column cannot explain itself

When a balance lives in a single field, every change overwrites the evidence of the previous one. An employee asks why they have eleven days instead of twelve and nobody can answer without digging through logs — assuming the logs captured it at all.

In the Employee Management Portal we model it the other way round. Entitlements are credited per fiscal year, and every approval, cancellation, adjustment and unpaid deduction is written to a ledger as its own entry. The balance is the sum of those entries. It is never typed by anyone.

What that buys you

Disputes stop being arguments and become queries. Corrections stop being edits and become compensating entries with a reason attached. And historic data can be imported at go-live as opening entries rather than as invented starting numbers.

The same shape applies well beyond leave: asset custody, enforcement case state, anything where "how did we get here?" is a question somebody will eventually ask.

If your system stores an outcome without storing how it was reached, somebody will have to reconstruct it under pressure.

The costs, honestly

Derived balances mean more rows and more care around reads. You will want an index strategy, and eventually a snapshot for performance — but a snapshot you can always rebuild from the entries, never a snapshot that becomes the truth.

That is the discipline: the ledger is authoritative, everything else is a cache. Hold that line and the system stays explainable for as long as it runs.