THE LEDGER
A double-entry banking ledger at the core, not a dashboard over someone else’s balances
Every balance on the platform is derived from balanced, write-once ledger entries: client payments, fees, FX, cards, crypto and manual bookings alike. There is no path in the system that moves money without booking the corresponding entries.
Banking ledger software vs a balance table in an app database
Most white-label banking products keep balances as rows in an application database, mirroring a provider’s numbers. It looks fine in a demo. It stops being fine the day you need to serve regulated activity: produce financial statements, prove client funds are safeguarded, explain to an auditor why the app and the accounts disagree.
FinLabCore is built the other way up. The ledger is not a reporting layer bolted onto the product, it is the product’s source of truth, kept on classical accounting principles. Everything else on this page follows from that decision.
A classical chart of accounts, built like a bank’s
A conventional banking chart of accounts: assets, liabilities, equity, income, expenses and off-balance-sheet items. The books map directly onto a balance sheet, a profit-and-loss statement and a trial balance, with no translation step between what the product shows and what the accountants file.
Every fee you charge maps to its own income position, so revenue is reportable by service line without manual allocation, the accounting half of the tariff engine.
Double-entry, write-once, atomic
- Double-entry throughout. Every movement of value is registered as balanced entries: a payment, a fee, an FX conversion, a card operation, a crypto transfer, a manual booking.
- Write-once. Entries are never edited in place. Corrections are posted as further entries, so history stays reconstructible, the property auditors actually test for.
- Atomic. Related entries of a multi-leg operation are written together: fully booked, or not booked at all. No half-posted states to chase.
- Duplicate-proof by construction. Resubmitting the same movement is rejected at the ledger, not caught by application code later.
- Two dates on every entry. The business date it belongs to, and the moment it was registered, so period reporting and audit questions have exact answers.
Balances are derived from entries, never stored beside them
A balance in FinLabCore is not an independent figure that could drift from the postings behind it. It is computed from the registered entries, which is why a client statement and the general ledger agree by definition, there is nothing between them to reconcile.
The ledger is the live system of record, not an end-of-day export: balances reflect entries the moment they are booked. Back-dated activity does not break this, it triggers a controlled recalculation with its own audit history.
Every entry is valued twice
Each entry carries its value in its own currency and in the reporting currency, fixed at the moment of registration. Historical reporting therefore does not shift when today’s rates move, last quarter’s numbers stay last quarter’s numbers, whatever the market does since.
Client funds as liabilities, safeguarding built into the books
Client funds are held as a liability to the customer, against bank-side positions that keep safeguarded client money separate from the institution’s own funds. That structure is the precondition for safeguarding reconciliation: proving, against counterpart records, that client money is where it must be.
For EMIs and MSBs this is not a feature, it is the licence condition. See how it plays into the EMI & MSB solution.
Daily FX revaluation, booked as gain or loss
Non-reporting-currency balances are marked to current rates every day, and the resulting gain or loss is booked, so the balance sheet shows real positions, not historical ones. Combined with dual valuation, FX exposure is a number you read off the books, not a spreadsheet exercise.
The trading side of this lives in FX & Crypto; the accounting side lives here.
Payment reconciliation by design, and the reports to prove it
Client balances, correspondent bank positions, fee income and exchange settlement are each reconcilable against their counterpart records, with dedicated reconciliation reporting.
Straight out of the platform, over any chosen period, as downloadable files: balance sheet, profit and loss, trial balance, income and expense, FX result and revaluation reporting, client and client-balance reporting, payment and FX payment reporting, agent commission reporting, correspondent-bank reporting, and fee and exchange reconciliation.
General ledger for fintech: two ways to build it
| Balance table in an app database | The FinLabCore ledger | |
|---|---|---|
| Where a balance lives | A mutable column, updated in place | Derived from balanced, write-once entries |
| Corrections | Edit or overwrite the row | New correcting entries; history reconstructible |
| Multi-leg operations | Partial updates possible on failure | Atomic, fully booked or not at all |
| Duplicates | Caught by application logic, sometimes | Rejected by the ledger, by construction |
| Statement vs general ledger | Two systems, reconciled by effort | Agree by definition |
| FX | Balances at implied or historical rates | Dual valuation and daily revaluation, gain/loss booked |
| Client money | Mixed into an omnibus view | Liabilities, separated from own funds, reconcilable |
| Financial statements | Rebuilt in spreadsheets | BS, P&L, trial balance straight from the books |
| Audit trail | Log tables, best effort | Every entry attributable, business and registration date |
Double-entry banking ledger FAQ
What exactly is in the audit trail?
Full history for payments, signatures, ledger entries, provider exchanges and administrative actions, every action attributable to a person or system. Pricing and money-routing changes are separately audited on top.
How is back-dated activity handled?
Every entry carries both its business date and its registration moment. Back-dated activity triggers a controlled recalculation of affected balances, and that recalculation has its own audit history, nothing is silently rewritten.
Does crypto really sit in the same books?
Yes. Crypto accounts, transfers and conversions are booked in the same double-entry ledger as fiat, at full precision, not in a bolted-on wallet with its own numbers. Details on Crypto accounts.
How are financial statements produced?
From the books directly: the chart of accounts maps onto the balance sheet, P&L and trial balance without a translation step, and the reporting suite generates them over any period as downloadable files.
Can operations staff post manual bookings?
Yes, manual bookings, corrections and period-end routines are part of the back office, under role-based access, with every action attributable and corrections posted as new entries.
Why does statement equals general ledger matter commercially?
Because reconciliation effort, audit findings and regulator questions all live in the gap between the two. Remove the gap and you remove the workstream, headcount scales with the business, not with transaction count.
Ask to see the books, not the slides
The fastest way to evaluate a ledger is to watch a payment, an FX conversion and a correction get booked, live. Bring your auditor.