Test your ledger before posting customer money
Run the four tests against the platform before any customer money is posted. Then clone Formance Ledger on GitHub and run the acceptance script in parallel to confirm the expected behavior under each test.
Fintechs, marketplaces, and digital-asset custodians increasingly hold customer funds in omnibus accounts, where a single bank account holds money for thousands of underlying customers.
In June 2023, the Nevada Financial Institutions Division (NFID) ordered Prime Trust to cease operations after regulators found the trust company owed customers $85.67 million in fiat currency but held only $2.9 million in cash reserves. The $82.76 million shortfall stemmed from historical wallet access issues and internal accounting discrepancies that management failed to surface and resolve in time.
Prime Trust ran its per-customer accounting on platforms that reported at period close rather than reconciled against the bank daily. By the time the shortfall surfaced, the bank statement couldn't identify which customer was short because the bank never saw the per-customer split.
The failure to catch per-customer drift at write time is what separates fund accounting software from a purpose-built ledger.
Fund accounting software and a purpose-built ledger differ on five scope dimensions (primary consumer, question answered, record-production timing, account organization, and operational role). The differences determine which platform can serve as a real-time system of record for omnibus-account customer money.
| Dimension | Fund accounting software | Purpose-built ledger |
| Primary consumer | Accountants, auditors, and grantors | Payment services, reconciliation jobs, and customer-facing balance APIs |
| Question answered | Was restricted money spent on its restriction, and what was each fund's balance at period end? | Which customer owns each unit of money right now, and does the sum match the bank? |
| Record produced at | Period close from imported batches | Write time that is inside the request that moved the money |
| Account organization | Chart of accounts by fund and restriction | Multi-asset account paths per customer and per status (customers:4471:pending, customers:4471:available) with precision per asset |
| Operational role | Reporting platform | System of record for money in motion |
Fund accounting software (such as Sage Intacct, Blackbaud Financial Edge NXT, MIP Fund Accounting, or Oracle NetSuite's nonprofit module) records a fund's purpose.
A purpose-built ledger records which customer owns each unit of money in the omnibus account at the current read time and whether the sum of per-customer claims matches the cash at the bank.
Both platforms use double-entry accounting, but each entry carries different data: fund accounting software carries a fund and restriction label, and a purpose-built ledger carries a customer and asset path.
Formance Ledger is the open-source, programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability. It is used as the reference implementation throughout this guide. Open source is Formance's founding philosophy because financial infrastructure teams need full code access, the right to self-host, and MIT-license portability.
A purpose-built ledger enforces five posting-time controls at write time (atomic rejection, concurrency safety, immutability, bi-temporality, and funds provenance), and fund accounting software performs none of them at the strength required for omnibus-account customer money. Idempotency is a sixth control because it depends on client-side cooperation rather than ledger enforcement.
Atomic rejection means every posting must balance, a multi-leg transaction must commit whole or not at all, and the ledger must refuse a write when the source account cannot cover the movement.
Fund accounting software performs the first check (debits must equal credits) but does not refuse a write when the source account is short or when a second leg would fail. A purpose-built ledger treats all three conditions as a single commit gate.
Numscript, Formance's purpose-built language for describing financial transactions, makes the atomicity check readable to finance and engineering.
The seller's payable funds are in @sellers:4471:payable, the queued bank payout is in @platform:banks:clients:out:pending, and platform fee income is in @platform:revenue:fees.
In this marketplace transaction, the ledger records a $187,500.00 seller payout to the pending bank payout account and captures a $1,250.00 fee:
// SELLER_PAYOUT
// Event: post a seller payout and capture the platform fee atomically
set_tx_meta("event_type", "seller_payout")
set_tx_meta("payout_id", "pyt4471")
send [USD/2 18750000] (
source = @sellers:4471:payable
destination = @platform:banks:clients:out:pending
)
send [USD/2 125000] (
source = @sellers:4471:payable
destination = @platform:revenue:fees
)
The @platform:banks:clients:out:pending account is a ledger representation of a queued bank payout and is not a representation of the bank.
Formance Ledger does not move funds because the connected provider executes the payout through Formance Connectivity.
The ledger enforces concurrency safety, so parallel writes against the same account resolve to a consistent balance rather than racing.
A purpose-built ledger serializes conflicting writes, so a card authorization and a settlement arriving at the same spendable balance within milliseconds of each other are ordered. They always produce the same final balance.
Without concurrency safety at the ledger layer, parallel writes against the same account can produce inconsistent balances, double-spends, or lost updates under production load.
Fund accounting software lacks concurrency primitives in the write path because it was built for scheduled batch imports that run serially. As a real-time posting layer, concurrent writes to the same account can produce inconsistent balances, double-spends, or lost updates.
Immutable postings never change once committed. Corrections are new postings that reverse or adjust the original, and the history keeps both. The ledger hash-chains transaction history, so each posting cryptographically links to the previous one, producing a tamper-evident log.
Fund accounting software records edits in an audit log, but the entry itself is mutable, and it lacks a cryptographic chain. Proving tamper-evidence to a regulator requires checking the audit log process rather than the ledger state.
The immutable, hash-chained log uses bi-temporality to reconstruct every balance at any past moment from the posting log alone, without consulting backups.
Bi-temporality tracks both when an event was recorded and when it became effective, so a ledger can accept a correction dated last Tuesday without rewriting what the ledger said on Wednesday.
When a bank settles a card batch late, the effective date is the settlement date, the recorded date is today, and a query that asks "what did the ledger show on this date?" for any date between settlement and today returns what the ledger actually knew on that date.
Fund accounting software commonly shows a single transaction date and period controls, so a backdated correction means reopening the period and editing in place. The "as of" view must be rebuilt manually from backups or audit logs.
Funds provenance means every unit of money inside an omnibus account carries a source tag that survives the move, so segregated and unsegregated balances in the same currency stay distinguishable.
A purpose-built ledger keeps provenance on the unit, while fund accounting software tags funds at the account level through the chart of accounts, so once money moves between accounts, the per-unit provenance is lost.
Assets Coloring, a Formance feature that tags units of the same asset with distinct provenance or ownership constraints without creating a new asset type, keeps a segregated dollar and an unrestricted dollar distinguishable in a balance.
Payments engineering teams call same-currency balances with different ownership or restriction claims the color-of-money problem.
Idempotency is enforced by the calling platform. The ledger alone cannot know whether two incoming requests represent one business intent or two.
An idempotency key per payment instruction (a stable identifier safe to retry without creating a duplicate posting) lets the platform block a duplicate submission before it becomes a second posting.
Purpose-built ledgers expose idempotency key support at the posting API, while fund accounting software built around batch imports typically does not, which forces the client to deduplicate before the import rather than at the ledger.
Retry deduplication must be handled by the client or workflow layer unless the posting interface explicitly supports idempotency, which is why idempotency sits adjacent to the five ledger-enforced controls rather than inside them.
The posting layer belongs in a purpose-built ledger whenever customers can spend the balance now, and the cost is a bounded integration effort plus open-source licensing, with no reporting-side migration.
Three signals force adoption: omnibus structure holding commingled customer funds, real-time spendable balances across multiple payment rails, and daily reconciliation driven by the business. If the balance is only reported on at period close, fund accounting software is sufficient on its own.
The subledger pattern bounds second-ledger cost because the purpose-built ledger owns transaction writes while period-end roll-ups flow into the customer's existing accounting system through the subledger-to-accounting handoff. No reporting-side migration is required.
The cost of running a second ledger decomposes into three drivers.
Across all three drivers, the subledger pattern keeps the second ledger scoped to the write path, so adoption costs land on the engineering team responsible for payments.
Any one of the three signals below forces adoption of a purpose-built ledger alongside fund accounting software.
If any of the three signals applies today or is on the twelve-month roadmap, the write path belongs in a purpose-built ledger from the start, because retrofitting a live posting layer forces reconciling two sources of truth under production load.
Run four tests against any fund accounting software or purpose-built ledger platform before posting customer money. A "no" on any single question disqualifies the fund accounting software or purpose-built ledger platform as the system of record for spendable balances.