Double-Entry Financial Ledger for Multi-Party Creator Payout Splits

If you build financial software that stores user balances as a single mutable number in a database column (e.g. wallet.balance += 100), you are running an accounting liability waiting to fail an audit. When numbers drift due to an unhandled race condition or floating-point rounding error, you have zero paper trail explaining where the money went.

On Curved Lab, brand campaign settlements must be split across multiple stakeholders simultaneously: 70% to the creator, 15% platform management fee, 5% agency referral, and 10% held in escrow pending deliverable verification. Here is how we engineered an immutable, audit-compliant double-entry bookkeeping engine in MongoDB.

The Golden Rule: Debits Must Exactly Equal Credits

Double-entry accounting enforces a mathematical invariant: money is never created or destroyed; it only moves from one account to another. Every financial event creates a Journal Entry containing at least two Postings. The sum of all debits must equal the sum of all credits to the exact integer cent (Σ Debits === Σ Credits).

Eliminating Floating-Point Precision Drift

JavaScript numbers are 64-bit IEEE 754 floats. Executing operations like 0.1 + 0.2 yields 0.30000000000000004. In financial software processing millions of dollars, micro-cent rounding errors compound quickly, resulting in broken accounting invariants and failed balance reconciliations.

In our architecture, all monetary values are stored strictly as 64-bit BigInt integers representing smallest currency units (cents). A $100.00 payment is stored as 10000. Furthermore, percentage splits use integer basis points (where 100% = 10,000 bps) combined with the Largest Remainder Method (Hare-Niemeyer), ensuring any leftover fractional cent is deterministically allocated without losing or inventing money.

Core Reliability Guarantees

• Append-Only Immutability: Ledger postings are write-once. If a transaction must be refunded or adjusted, application code never updates or deletes historical records; instead, it appends an offsetting reversing journal entry.
• Materialized Balance Verification: While account balances are materialized for sub-millisecond querying, an hourly background auditor re-sums the entire ledger posting history to verify that every account matches its historical sum.
• Zero Audit Friction: Providing full transaction history to auditors or tax authorities requires only a simple query of the journal table, generating complete audit trails without manual reconciliation.