Store Facts, Don't Compute Them

Definition

In financial systems, state like payment_status should be STORED at the moment of the business event, not derived at query time — the opposite of the usual engineering instinct against redundancy.

Worked Example

Computed approach:
  v1 logic: status = PAID if a withdrawal row exists
  v2 logic (bug fix): ...if a COMPLETED withdrawal exists
  -> historical reports silently change after deploy. Auditors notice.

Stored approach:
  status written as a fact when the event happened
  -> code changes can never rewrite history.

The discipline that makes it safe — write transactionally:
BEGIN;
  UPDATE cost_items SET payment_status='PAID' WHERE id=4821;
  INSERT INTO cash_transactions (...);
  INSERT INTO audit_trail (...);
COMMIT;

Interpretation & Pitfalls

Stored facts are evidence; computed values are arguments that change with the code. Pay the redundancy cost; collect auditability, history-stability, and (as a bonus) performance.

In TupicFinance

payment_status and liability_type are stored fields written atomically with their bank movements — a foundational design principle of the platform.