These principles codify the architectural truths that govern correct fiduciary financial system design. They are not preferences or best practices—they are invariants. Systems that violate these principles cannot prove fiduciary integrity.
Each principle is named for reference and citation.
The Fundamental Laws
The Fiduciary Proof Equation
Beginning Balance + Activity = Ending Balance
Statement: For any account, at any point in time, the sum of the beginning balance plus all recorded activity must equal the ending balance. If this equation fails, the records are incorrect.
Implication: This is not a reconciliation target—it is a mathematical identity. A system where this equation can fail is a system that cannot prove its own accuracy.
Application: Every account, every fund, every period must satisfy this equation. Violations are not "discrepancies to investigate"—they are proof of system failure.
The Segregation Principle
Statement: Funds are distinct legal entities, not accounting categories. Money in one fund cannot satisfy obligations of another without explicit, recorded transfer.
Implication: Fund boundaries are not organizational conveniences. They represent legal restrictions on how money may be used. A reserve fund that "borrows" from operating without transfer records has violated its fiduciary obligation.
Application: The system must enforce fund assignment at posting time. Cross-fund transactions must create transfer journal entries. No implicit commingling.
The Override Doctrine
Statement: Exceptions to system constraints must be explicit, scoped, time-limited, and auditable. Silent bypasses are architectural defects.
Implication: Every valid exception leaves a record. If a constraint was relaxed, there is an override object explaining who authorized it, why, when, and for what scope.
The five requirements: 1. Explicit: Must be consciously created 2. Scoped: Applies to specific transactions, periods, or funds—not globally 3. Time-limited: Has a defined expiration 4. Auditable: Records creator, reason, and authorization timestamp 5. Usage-logged: Each application creates a separate immutable record
Application: Systems must make silent bypasses architecturally impossible. There is no "admin mode" that disables constraints without logging.
The Ledger Authority Principle
Statement: The ledger is the authoritative system of record. Enforcement at any other layer is insufficient.
Implication: Transactions enter systems through many paths: UI, API, bulk import, integration, emergency recovery. Only the ledger layer touches all paths. Enforcement must live at the point of write, not the point of entry.
Application: Constraints validated only in the UI are bypassable. Constraints validated only in workflows are incomplete. Constraints validated at the ledger layer are authoritative.
The Immutability Principle
Statement: Posted transactions are historical facts. They cannot be edited, only corrected through reversing entries.
Implication: If a posted transaction was wrong, the correction is a new entry that reverses the original—not an edit to the original record. This preserves the complete audit trail: the original error, the correction, and the resulting state.
Application: Journal entries after posting cannot have their amounts, accounts, or dates modified. The only allowed state change is voiding, which creates a reversal. Historical reports regenerated today must match reports generated at the original time.
The Architectural Principles
The Enforcement Hierarchy
Statement: Controls exist in a hierarchy of strength. Higher levels cannot be weakened by lower levels.
The hierarchy, from strongest to weakest:
| Level | Description | Example |
|---|---|---|
| 1. Database Constraints | Cannot be violated without database modification | Foreign keys, check constraints |
| 2. Ledger Enforcement | Cannot be violated without code change | Fund scope validation |
| 3. Policy Layer | Configurable but auditable | Spending limits, approval thresholds |
| 4. Workflow Layer | Process controls | Multi-step approvals |
| 5. UI Layer | User guidance | Input validation, warnings |
Implication: A level-5 control (UI validation) cannot enforce what a level-2 mechanism (ledger enforcement) should handle. If fund segregation is important, it must be enforced at level 2, not level 5.
Application: Identify the required strength for each control and implement at the appropriate level. Never rely on weaker levels to enforce critical constraints.
The Constraint Completeness Principle
Statement: If a constraint matters, it must be enforced for all paths that could violate it.
Implication: A fund segregation check that runs for manual entries but not for imports is not a constraint—it's a suggestion. Attackers (and accidents) find the unguarded path.
Application: Enumerate all entry paths. Verify each constraint applies to each path. The matrix must be complete.
UI Entry API Entry Import Integration Recovery
Fund Scope ✓ ✓ ✓ ✓ ✓
Period Status ✓ ✓ ✓ ✓ ✓
Balance Eq. ✓ ✓ ✓ ✓ ✓
Policy Rules ✓ ✓ ✓ ✓ ✓
Any gap in this matrix is an enforcement failure waiting to happen.
The Reproducibility Principle
Statement: Given the same inputs and the same rule state, the system must produce the same output. Always.
Implication: Evaluation decisions cannot depend on current time, random values, or external state that isn't captured. If a transaction was approved, an auditor must be able to reconstruct exactly why—not approximately, exactly.
Application: - Capture rule snapshots at evaluation time - Use deterministic hashing for idempotency keys - Store evaluation traces with full context - Implement verification methods that prove reproducibility
# Idempotency key: deterministic, no timestamps
key = sha256(canonical_json({
'action': 'BILL_APPROVAL',
'amount': 5000,
'vendor_id': 'abc123',
'fund_id': 'def456',
# Note: NO timestamp included
}))
The Provenance Principle
Statement: Every ledger entry should know how it was created—which rules were applied, which accounts were used, and why.
Implication: "Why was this journal entry created this way?" should have a definitive answer stored in the system, not in someone's memory.
Application: Journal entries store: - Posting rule snapshots active at creation time - Account mapping references - Transaction source and type - User and timestamp context
Provenance data is immutable after posting.
The Operational Principles
The Period Integrity Principle
Statement: Fiscal periods are temporal boundaries with lifecycle states. Operations appropriate for one state are inappropriate for another.
The lifecycle:
OPEN → CLOSED → LOCKED
↑ │
└────┘
(reopenable)
LOCKED is permanent.
Implication: Open periods accept transactions. Closed periods accept transactions only with override. Locked periods never accept new transactions—the historical record is permanent.
Application: Implement period status as an enum with allowed transitions. Lock triggers archival of audit documentation. Override duration limits prevent indefinite closed-period access.
The Reconciliation Completeness Principle
Statement: Every balance sheet account should be reconcilable to an independent source. Accounts that cannot be reconciled cannot be verified.
Implication: Cash accounts reconcile to bank statements. Receivables reconcile to member ledgers. Payables reconcile to vendor invoices. If an account has no reconciliation source, its balance is an assertion, not a fact.
Application: Define reconciliation expectations for each account type. Track reconciliation status and age. Surface unreconciled accounts as integrity findings.
The Role-Based Discovery Principle
Statement: System-critical accounts should be located by role, not by hardcoded number.
Implication: Account 1000 might be operating cash in one organization and petty cash in another. The system should not hardcode "1000 = operating cash." Instead, it should query "which account has the OPERATING_CASH role?"
Application: Define account roles for system-critical functions. Allow organizations to map their own account numbers to roles. System operations reference roles, not numbers.
# Wrong: hardcoded account number
cash_account = Account.objects.get(account_number='1000')
# Right: role-based discovery
cash_account = Account.objects.get(
hoa_id=hoa.id,
role=AccountRole.OPERATING_CASH
)
Summary Table
| Principle | One-Line Summary |
|---|---|
| Fiduciary Proof Equation | Beginning + Activity = Ending, always |
| Segregation Principle | Funds are legal boundaries, not tags |
| Override Doctrine | Exceptions must be explicit, scoped, and logged |
| Ledger Authority | Enforcement at the point of write |
| Immutability Principle | Posted entries are facts, not drafts |
| Enforcement Hierarchy | Stronger levels cannot be bypassed by weaker |
| Constraint Completeness | All paths must respect all constraints |
| Reproducibility Principle | Same inputs + same rules = same output |
| Provenance Principle | Entries know how and why they were created |
| Period Integrity | Open → Closed → Locked, with clear rules |
| Reconciliation Completeness | Every balance needs a verification source |
| Role-Based Discovery | Find accounts by role, not number |
How CommunityPay Enforces This
- Principles implemented as database and code constraints
- Enforcement hierarchy prevents weaker layers from bypassing stronger
- Reproducibility enabled through policy snapshots and evaluation traces
- Role-based account discovery instead of hardcoded numbers