100%
Immutable History
Pre
Disbursement Controls
Zero
Post-Hoc Corrections
Full
Decision Provenance
The ledger doesn't just record what happened. It governs what can happen.
CommunityPay's audit trail is not a reporting feature. It's an architectural
guarantee that non-compliant transactions cannot execute.
Traditional systems ask "did someone approve this?" CommunityPay asks
"is this transaction legally, structurally, and financially permissible right now?"
The accounting system governs payments, not the other way around.
Pre-Disbursement Evaluation
Every payment request is evaluated against fund policies
before it can proceed. Non-compliant requests are blocked,
not flagged for later review.
Fund Policy Enforcement
Expense categories, approval thresholds, transfer restrictions,
and source limitations are enforced automatically. The system
prevents violations, not just detects them.
Structural Blocking
Invalid payment states are unrepresentable in the system.
You can't bypass controls because the system architecture
doesn't allow invalid states to exist.
The Inversion: In traditional systems, payments happen and the ledger records them.
In CommunityPay, the ledger determines whether payments can happen at all.
Accounting governs money movement, not the other way around.
Every transaction, every decision, every policy evaluation is permanently
recorded. History cannot be rewritten. Auditors can verify the state of the
system at any point in time.
Append-Only Ledger
Journal entries are never modified or deleted. Corrections
are made with new entries. The complete history is preserved
forever.
Posting Provenance
Every entry includes who created it, when, why, and what
policy evaluation authorized it. The posting_rationale
field explains every decision.
Period Locking
Closed periods are locked. No backdating. No "adjustments"
to last month. Financial history is preserved exactly
as it happened.
When a payment is evaluated, the system captures the exact policy state
at that moment. Even if policies change later, the audit trail shows
exactly what rules were in effect when the decision was made.
Policy Snapshots
- Immutable capture of policy state at evaluation time
- Cryptographic integrity verification
- Survives policy updates or deletions
- Reconstructable decision context
- Auditor-verifiable policy history
Decision Records
- Complete record of every policy evaluation
- Links decisions to specific policy snapshots
- Prevents duplicate or conflicting evaluations
- Deterministic re-evaluation capability
- Full decision provenance chain
Payment Request → Load Active Policies → Capture Policy State → Evaluate Rules → Record Decision
| | | | |
v v v v v
Disbursement Fund + Date Immutable BLOCK/WARN/PASS Complete
Details Scoping Snapshot + Rationale Audit Trail
Sometimes legitimate transactions are blocked by policies. CommunityPay
provides a formal override process that maintains full audit trail
accountability while allowing authorized exceptions.
Override Request Process
Blocked transactions can be escalated through a formal
override request. Requests require justification and
go through approval workflow.
One-Time Tokens
Approved overrides generate single-use tokens with
expiration. Tokens can only be used once, preventing
reuse for future violations.
Complete Override Audit
Every override is permanently recorded: who requested,
who approved, what justification, when used.
Nothing happens without accountability.
Auditability is not narrative reconstruction. It's state verification.
Given the same inputs, CommunityPay produces the same outputs.
Auditors can verify not just what happened, but that it was correct.
What Traditional Systems Offer
- Activity logs of who did what
- Timestamp records
- Approval signatures
- Change history
- Narrative reconstruction
What CommunityPay Provides
- Deterministic re-evaluation of any decision
- Policy state at any point in time
- Mathematical proof of compliance
- Idempotent transaction verification
- State verification, not narrative
Operating funds, reserve funds, and special funds are structurally
separated at the data model level. Commingling isn't just prohibited
by policy. It's impossible by architecture.
Structural Fund Separation
Every account belongs to exactly one fund. Fund assignment
is enforced at the database level. Cross-fund posting
requires explicit transfer entries.
Usage Restrictions
Reserve funds can only be used for reserve purposes.
Operating expenses cannot be paid from reserves without
proper fund transfer with board approval.
Transfer Audit Trail
Every interfund transfer is recorded with full justification.
Emergency reserve draws require documented approval.
Complete history for auditors.
Did the right people click approve?
Is this transaction structurally permissible?
Controls depend on human compliance
Controls enforced by system architecture
Violations detected after the fact
Violations prevented before they occur
Audit trail shows what humans did
Audit trail proves system correctness
Board turnover breaks institutional memory
Rules encoded in system, survive turnover
Policy Violation Log
Complete history of every blocked transaction.
Why it was blocked, what policy triggered, resolution
status. Evidence of controls working.
Override Report
Summary of all approved overrides. Who requested,
who approved, justification provided. Board visibility
into exceptions.
Fund Balance Verification
Point-in-time fund balances with complete transaction
trail. Verify reserve adequacy. Prove fund integrity
to auditors.
Policy Change History
When policies were added, modified, or retired.
Who made changes. Complete governance evolution
documented.
Journal Entry Detail
Every entry with posting_rationale explaining why
it was created. Links to source transactions.
Full accountability chain.
Reconciliation History
Complete bank reconciliation records. What was matched,
what was outstanding, who completed it. Auditor-ready
documentation.
Governance is not a workflow. It's a system property.
CommunityPay doesn't rely on humans following procedures correctly.
The architecture itself ensures that money cannot move unless the
accounting system has determined it is permissible. Fiduciary duty
is encoded in the system, not delegated to manual controls.