How do you build double-entry ledgers in Laravel?

Double-entry ledger design is one of the most important architectural decisions in a fintech application. We typically build domain specific ledger tables (transactions, postings, accounts, balances) with strict invariants: every transaction is two equal and opposite postings, balances are derived from postings (never directly mutated), all writes happen inside database transactions with row level locking on involved accounts, and idempotency keys prevent double processing. The ledger is append only with corrections expressed as compensating transactions, never edits or deletes. Reconciliation jobs run continuously comparing internal ledger state to external payment provider state with discrepancy alerting. We do not use generic accounting packages for fintech ledgers because the constraints differ from accounting.