Why lease schedules should be immutable

Every lease spreadsheet has a moment where someone types over a formula. The change is usually harmless, such as a rounding tweak or a corrected date, and three months later nobody can say which number was there before or why it changed. For a subledger that feeds audited financial statements, that is the real risk: not the arithmetic, but the missing history.

Outputs are generated, never edited

The first rule is simple to state: users change inputs, not schedule rows. If the payment changes, you record the change as a fact with an effective date, and the engine produces a new schedule. You never patch row 17.

Snapshot what you measured from

When a lease is approved, Leasecount writes a canonical snapshot of its inputs (contract facts, payment rules, the compiled cash flows, assigned books and the approved rate) and stores its SHA-256 hash. Calculations are derived from that snapshot, not from the editable lease record. If someone edits the draft tomorrow, yesterday’s calculation still points at exactly what it measured.

Supersede, don’t overwrite

A recalculation creates a new version that names the version it supersedes. Each version records its engine and policy version, input and output hashes, actor and time. The old version stays readable, so you can answer “what did we report in March, and why?” without restoring a backup.

Correct by reversal

Once a journal batch is approved, its lines are never edited. A correction is a reversal batch with provenance back to the original, followed by the corrected batch. A closed period cannot quietly keep active journals from a superseded calculation; close readiness lists them until they are resolved.

What you get

• Any figure can be traced to the snapshot, judgement and engine version that produced it.
• Reviewers compare versions with a change report instead of a diff of two spreadsheets.
• Exports carry a content hash, so you can prove which file was handed over.