Financial functions and invariants

create_double_entry_transaction() is the controlled door for financial ledger creation. Server services validate intent before calling it; database constraints protect the stored invariant.

Balance invariant

A transaction needs at least two entries, balanced at stored precision per currency. Cross-currency exchanges can need four entries. Balancing a combined numeric sum across different currencies is invalid.

A fictional EGP 150 purchase must have offsetting EGP entries. An exchange also needs balanced entries in its other currency, using the actual outgoing and received account amounts.

Ownership and atomicity

Validate each account and semantic link in the authenticated user’s context. Perform money creation through the controlled transaction boundary so a failed call cannot leave a half-written header and entries.

Do not create a direct entry-editing path to repair an application error. Such a path can bypass financial validation, idempotency and ownership.

Changes to existing money

Corrections, reversal, restoration and settlements retain their specific domain rules and explanations. An import undo is bounded to its eligible owned units, not arbitrary history deletion.

Read invariants

Financial read models combine ledger evidence and context coherently. When coherent evidence cannot be established, report unavailable instead of mixing versions into one answer.

After a financial data change, verify zero unbalanced transactions alongside the intended owned effect. See database changes and testing.