Track in-product transactions with Formance Ledger
Learn more about how Formance Ledger can help you efficiently track in-product transactions directly in your product.
The word "ledger" covers several different, overlapping contexts, and choosing the wrong kind is expensive to unwind. Ledgers, broadly speaking, are meant to track the movement and disposition of a fungible item, usually (but not always) money, and are the master record of a company's financial transactions.
But different ledgers serve different purposes and deliver different results based on company requirements and regulations.
At Formance, we build open-source ledger infrastructure for fintech teams, and the question we hear most often is which kind of ledger a product actually needs. The answer usually involves more than one. This guide draws on that experience to map the four ledger types that show up in modern financial stacks and how they fit together.
Double-entry balance, an append-only history, and atomicity make a ledger trustworthy. Every ledger shares all three, but ledger types differ in scope, cadence, and audience.
Financial ledgers use double-entry accounting, which is when each transaction touches at least two accounts, one debited and the other credited, and total debits must equal total credits.
Debits increase assets and expenses and decrease liabilities, equity, and revenue, while credits do the opposite.
The structure balances against the accounting equation (Assets = Liabilities + Equity), so when a user deposits $100 into a wallet, the bank asset account is debited $100 and the user liability account is credited $100. Value moves between accounts, and that double-entry accounting makes a ledger auditable.
The append-only property turns a ledger into an audit trail. The record shows the current balance, what the balance was believed to be, when the belief applied, and why, which settles disputes, satisfies auditors, and surfaces fraud.
A purpose-built ledger database only accepts INSERTS, often chains entries with a cryptographic hash for integrity, and corrects mistakes with reversal entries rather than in-place UPDATES.
Balances are derived from the sum of postings, and are never stored as a single mutable number. A derived balance is always auditable because the entries that produce it are all present, while a stored balance can be silently corrupted by one bad UPDATE with nothing in the data to flag it.
Atomicity means all the debit and credit postings that make up one transaction commit together or fail together. No in-between state exists where one side of the entry lands and the other does not.
Without atomicity, a crash or a race between two concurrent writes can leave a partial update, and a partial update produces an unbalanced ledger the product cannot trust. A trustworthy ledger enforces atomicity at the database level, and not through balance updates scattered across application code.
Four types of ledgers each play a different role in tracking money. General ledgers report company-level financials to accountants and auditors, while core ledgers track in-product fund movement in real time. Cash ledgers mirror what actually cleared at the bank, whereas subledgers hold the line-by-line detail for one account area. Teams get into trouble when a single ledger is asked to do another ledger's job.
Nearly every business requires a general ledger for company-level accounting and financial reporting, typically based on an accounting standard such as GAAP (in the U.S.) and IFRS (in much of the rest of the world). The general ledger provides an auditable account of the debits and credits moving into and out of the company, with opinionated rules dictating the meaning of each entry, including depreciation and revenue recognition.
The index of accounts is the chart of accounts (CoA), which is a numbered catalog. A general ledger's CoA is shaped by GAAP or IFRS reporting requirements. A core ledger's account structure, by contrast, is shaped by product business logic, including user wallets, merchant settlement accounts and fee buckets. Both ledgers rely on the same double-entry mechanics (every debit matched by an equal credit), but they organize accounts around different goals.
Transactions reach the general ledger in two steps: recorded as journal entries in chronological order, then posted to ledger accounts organized by account type. The general ledger's rhythm is the accounting period and not the moment of the transaction.
Accountants or business operations software like QuickBooks or NetSuite produce general ledgers, and firms such as Deloitte, EY, KPMG, or PwC audit them. General ledgers feed balance sheets, profit and loss statements, and other financial reports for government agencies and investors.
Core ledgers are focused on internal operations. A core ledger provides a real-time accounting of virtual funds inside a tech product where users engage in economic transactions.
Actual money often remains in an omnibus bank account (a single pooled account holding funds on behalf of many underlying owners). At the same time, the core ledger credits and debits move between users as they transact.
A common example is a marketplace, where buyers and sellers transact through the platform independently of when real money moves through the bank. Monthly payouts to sellers (a single real money movement) may represent many sales.
Another example is a neobank, which layers financial services on top of a traditional bank. When a customer swipes a card, the core ledger authorizes based on available funds, debits the customer's account, routes fees, and credits the vendor, all without moving real money through traditional banking accounts.
A core ledger is your system of record for these kinds of virtual movements, independent of the financial reporting that goes into a general ledger. Core ledgers aren't meant to answer sophisticated financial questions and aren't opinionated about the meaning of their entries.
They are designed to answer relatively small questions at high volume: Are there enough funds in this account to initiate the desired transaction? And then did the correct amount of money flow through the transaction and end up in the correct places in the correct amounts?
Concretely, a core ledger's account tree carves the omnibus, user wallets, and fee buckets into distinct paths that the core ledger uses as its operational chart of accounts:
world : external counterparty (bank/PSP inflow and outflow)
omnibus:bank : asset, pooled bank position
users:alice:wallet : liability, Alice's claim on the pool
users:bob:wallet : liability, Bob's claim on the pool
fees:platform : revenue, platform fees collected
The core ledger expresses transactions against that tree in Numscript, Formance's domain-specific language for double-entry postings. A $10,000 deposit from Alice, with a 2% platform fee, is one atomic Numscript transaction the core ledger commits as a single write:
// Numscript: one atomic core-ledger transaction
send [USD/2 1000000] (
source = @world
destination = @omnibus:bank
)
send [USD/2 1000000] (
source = @omnibus:bank
destination = {
98/100 to @users:alice:wallet
remaining to @fees:platform
}
)
Both send statements commit atomically: the $10,000 hits omnibus:bank, the $9,800 lands in Alice's wallet, and $200 goes to the fee bucket. The account paths themselves double as subledger boundaries the cash ledger and GL later consume.
They typically handle large transaction volumes in a product, and are implemented in software and integrated directly into your product backend. This is precisely the functionality Formance Ledger offers.
Cash ledgers sit between general and core ledgers, and offer similar attributes. Like the general ledger, a cash ledger tracks actual money movements. Like the core ledger, a cash ledger assigns no meaning to those movements.
A cash ledger contains the same data as a bank statement in a different format, making it the external side of reconciliation. The core ledger expected movements are matched against cash ledger records of what actually happened on each payment rail.
A subledger holds the detailed transactions for one accounting area, with totals that roll up into the general ledger. Subledgers exist because posting every invoice or wallet movement into the general ledger would overwhelm it. The general ledger keeps the summary, while the subledger keeps the detail.
Four common subledger types:
One caveat: "subledger" is used loosely. Sometimes for a core ledger or sometimes for sub-pages of a general ledger, and sometimes for an informal record of invoices destined for the general ledger. When someone says subledger, ask what it rolls up into to get clarity.
| General ledger | Core (product) ledger | Cash ledger | Subledger | |
| Primary purpose | External financial reporting | Real-time system of record for in-product fund movement | Track actual money moving through bank accounts | Detailed record of one high-volume account area |
| Data granularity | Individual postings, commonly reviewed as period summaries | Every individual posting | One line per real money movement, bank-statement level | Every transaction within its domain |
| Posting timing | Periodic, finalized at close | Real time, atomic per transaction | As bank or PSP data arrives | Traditionally daily to monthly roll-ups, real time in fintech |
| Regulatory framework | GAAP / IFRS | Business-logic-driven, feeds regulatory reporting | None, mirrors bank records | Must tie to general ledger control accounts |
| Who produces it | Accountants, ERP software | Product backend, ledger software | Bank and payment rail data feeds | Billing, AR/AP, or wallet systems |
| What it feeds | Balance sheet, P&L, cash flow statement | The general ledger and reconciliation | Reconciliation against the core ledger | General ledger control accounts |
A working fintech stack runs all four ledgers as one loop, designed from the core ledger outward. Money moves once in the real world, and each ledger records that movement from its own vantage point. Here is a single deposit through the loop, from the first posting to the final month-end summary.
On a deposit, card swipe, or payout, the core ledger books the double-entry posting atomically (user liability up $100 and omnibus asset up $100). That posting is the operational source of truth for every downstream question about balances, fees, and payouts. Because the posting is atomic, the product can act on ledger state immediately, without waiting for the bank, the reconciliation job, or the general ledger to catch up.
The cash ledger records the same movement from the bank's perspective, capturing statement lines as they arrive through bank feeds or PSP webhooks. It carries no notion of which user the money belongs to, only that money hit the account and when. That is exactly the view finance needs to answer: "Did the money actually show up?"
Reconciliation matches each core posting against the corresponding cash line. Matches confirm operational truth and cash truth agree. Mismatches surface as breaks before close, and a break might be an ACH timing gap, an unmodeled PSP fee, fraud, or a partial write that skipped double-entry enforcement. Reconciliation is the process that tells them apart, so run it continuously to catch breaks in minutes.
Subledgers hold the detailed history for high-volume account areas (AR invoices, AP bills, user wallets), rolling up into general ledger control accounts at close. In fintech architectures, the core ledger often plays the subledger role directly, with subledger boundaries expressed as an account-tree structure rather than separate databases to keep in sync.
The general ledger sits at the end of the chain, aggregating core ledger activity into GAAP or IFRS classifications at month-end, such as fees becoming revenue, settlements becoming expenses, and deposits becoming liabilities. Detail stays upstream in the core ledger and subledgers; reporting-ready totals go downstream to the general ledger, where accountants, auditors, and investors read them.
Most fintech teams end up needing all four ledgers, but it depends on the products. Core ledgers handle transactions, cash ledgers support products that hold customer funds, subledgers support high-volume account areas, and the general ledger supports financial reporting.
A core ledger is non-negotiable for marketplaces, neobanks, wallets, lending platforms, and in-game economies. A core ledger runs in real time, enforces balances at write time, and serves as the operational source of truth for every product decision that depends on account state. Without a core ledger, application code enforces financial invariants, and each new code path becomes a new place the books can go out of balance.
A cash ledger mirrors the bank statement and reconciles continuously against the core ledger. The cash ledger lets the team confirm the money on the books matches the money at the bank. Regulators and auditors will ask for this, so it's important for financial maintenance, regulations, and security.
Subledgers are for high-volume account areas, including those with thousands of AR invoices, hundreds of thousands of user wallets, or per-merchant settlement accounts. Carve them out with control-account totals that roll up to the general ledger. Otherwise, the general ledger overwhelms with in-line-item detail it was never designed to hold, and every close turns into an archaeology project.
A general ledger already exists, likely in QuickBooks, NetSuite, or SAP. Keep it. Feed the general ledger from the core ledger at close. Do not replace the general ledger with the core ledger, and do not use the general ledger as the core ledger. The two systems answer different questions on different cadences for different audiences, and forcing one to do the other's job breaks both.
Nearly every business needs a general ledger, and that is the core service an accountant or business operations software provides. However, because of its role as a source of truth for auditing and establishing the solvency of your business, a general ledger is not suitable for recording transactions that your business might facilitate.
Thus, if your business facilitates transactions, because it is a marketplace, a neobank, an investment platform, or even a game with an in-game currency, you need a core ledger to validate and record the flows of these virtual transactions. On the other hand, if you are not in the business of facilitating transactions, you likely do not need a core ledger.