What is Ledfra?

Ledfra is the accounting layer for platforms that move money.

A double-entry ledger you post to over a REST API, and read in a web app.
Real-time balances for every account, exact the instant a write returns.
The statements your accountant asks for: balance sheet, profit and loss, trial balance, daily activity.
It sits beside your database, not in place of it. No migration.

The problem Ledfra solves

Almost every product starts the same way: an orders table, a payments table beside it, a balance column on the users row, and a growing pile of SQL that reconstructs the reports from all three. At the start this is not a mistake, it is the right call. The numbers match and the queries are short.

Then come refunds, partial credits, a waived fee, a disputed charge. The system does not break, it starts to resist: every new rule takes longer than the last, and every report grows another special case. Two sums that should agree drift by three cents and nobody can say which is right, because neither was ever the source of truth.

That is the point at which you have outgrown a handful of tables. Ledfra is a framework for that side of your product: a place built to hold money movement, so the complexity stops spreading through your schema and your reporting queries. It gives a team what would otherwise take a finance hire, balances you can trust, statements that reconcile to each other, and an opinion about how to structure them. You do not need an accounting background to end up with books an accountant will recognise. Our guide Why marketplace accounting becomes so hard walks through where that turn happens in detail.

In practice that rests on three things:

Correct by construction. Double-entry is enforced when you post. You literally cannot record an unbalanced transaction.
Real-time and audit-ready. Balances update as you post, and statements stay current without a close step. Entries are immutable and trace back to the event that created them.
Built to integrate. A small REST API, idempotent writes, an OpenAPI spec, and sandboxes - first transaction posted in an afternoon.

How Ledfra fits into your existing system

You already built the hard part. In most products the hardest operation is the one where a payment splits: who is owed what, which fee comes off where, what you actually keep. A platform paying its sellers, a rental service holding a deposit, an insurer settling a claim - the shape is the same every time, and it is already a set of debits and credits. You just have not been writing it down as one.

Ledfra stores that breakdown. This is not a migration or a rewrite. Your product keeps its own database. You add one call at the point where money moves.

Nothing is taken away. The derived half simply stops being yours to maintain.

Ledfra holds the derived half for you. Every record of how a payment broke down, the running balance for each customer or partner, the period totals, and the queries that assemble all of it. That is where the complexity actually lives, and it is the part that grows fastest as the product does. You can drop those tables once Ledfra is filling the same role, or leave them exactly where they are and treat Ledfra as a second opinion. Both are fine.

Your product keeps whatever it reads on the request path. Most teams keep a cached balance on their own users row and let Ledfra be the system of record behind it, reconciling the two on a schedule, the same way they already reconcile against Stripe or their bank. Ledfra does not have to sit in your critical path.

You can go further and make it authoritative, reading balances straight from the API. Plenty of teams do. But you do not have to start there, and nothing about the first integration commits you to it.

How Ledfra is organized

Four concepts. Once you know these, you know the model.

Workspace - your organization. Everything lives inside one, and an API key is bound to exactly one workspace.
Ledger - a self-contained book of accounts with its own structure and balances. A workspace can hold several, and each is either a live production ledger or a sandbox copy for safe testing.
Account - a line in the chart of accounts that money posts against, addressed by a readable slug like assets:cash or liabilities:user/123 rather than a number you have to look up. See Accounts.
Transaction - a balanced, double-entry record of money moving. Two or more entries whose debits and credits net to zero. See Transactions.

A transaction is the unit of truth. When you collect $100 on someone else's behalf and keep $10 of it, that is one transaction with three entries: cash up $100, income up $10, what you owe up $90. The ledger will not record it any other way.

Why double-entry, and why it matters to you

Double-entry has been the standard for accuracy for centuries because it is self-checking: every movement is recorded twice, and the books only balance if nothing was lost. Ledfra enforces that at the API boundary instead of hoping application code gets it right.

For a developer, you cannot ship a bug that silently loses money - an unbalanced write is rejected, not absorbed. For a product manager, new money-movement features inherit correctness instead of re-implementing it. For a CFO or controller, the numbers in the dashboard are the numbers in the ledger, with a complete audit trail behind every one.

Real financial statements, not just balances

Most ledger infrastructure stops at balances and hands the rest to you. Ledfra keeps going: a balance sheet, a profit & loss, a trial balance, and a daily activity report, all built from the same entries your code writes.

There is no export step and no reporting pipeline for you to build, so there is no “which number is right” conversation. Because Ledfra never posts period-closing entries, retained earnings on the balance sheet comes from the same entries the P&L reads, so the two statements agree by construction rather than by reconciliation. Reports are timezone-aware, so teams in New York and Tokyo each see the ledger rolled up by their own calendar day.

Correct by construction

Ledfra is a financial system first, so it is conservative by design. Money is represented with exact precision across fiat, crypto, and points, with no floating-point rounding anywhere on the wire (see Money). Records are immutable - you undo something by posting its reverse, never by editing history. Writes are idempotent, so a network retry returns the original transaction instead of double-posting.

Balancing is not the same as being correct

A ledger that balances can still be wrong. Book money you are holding for someone else as income and every debit still equals every credit - the books balance perfectly and the revenue number is a lie. Ledfra takes a position on structure, not just arithmetic: only money you keep is income. Money you hold for someone else is a liability from the moment you collect it. That rule and the rest live in How to design your ledger.

What Ledfra does not do

A ledger sells trust, so it is worth being explicit about the edges before you build on it. Ledfra does not convert currencies: one currency per ledger, one per account. There is no cash flow statement, no multi-entity consolidation, and no GAAP or IFRS compliance automation. There are no bank integrations or feeds, no webhooks, and no official client SDKs yet. The REST API is plain HTTP. Reports are read in the app rather than through the API.

Where to go next

Quickstart - build a ledger and post your first transaction, start to finish.
Transactions - debits, credits, reversals, and holding funds.
How to build a marketplace ledger - the whole model applied to a real business.

Everything else is in the sidebar. Ready to integrate? Authenticate and call the endpoints in the API reference.