Fintech ledger, built on every verified stack.
Double-entry fintech ledger: chart of accounts, immutable journal entries, and debit/credit lines with integer-cent amounts.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Fintech ledger gives you
No table here has a balance column, and that absence is the design. An account's balance is a sum over journal_lines — grouped by direction, one side netted against the other — served by idx_line_account on account_id. Nothing is cached, so nothing can quietly fall out of agreement with the postings that produced it; the price is that every balance read is an aggregate, and a busy account grows a longer scan every month it stays open. accounts is the chart: a name, a currency defaulting to USD, and a type held to the five canonical classes by accounts_type_check — asset, liability, equity, revenue, expense. A sixth account class is a migration, not a config change.
journal_entries is the header, carrying a description, a creator_id into Better Auth's user, and posted_at behind idx_entry_posted. Notice what that index is not: it keys on time alone with no owner in it, so closing a period reads the whole book's window cheaply while a single owner's statement takes the other route entirely — accounts via idx_account_owner, then lines via idx_line_account. journal_lines is where the money sits. Each line points at an entry and an account, both indexed by idx_line_entry and idx_line_account, and carries a direction held to debit or credit by journal_lines_direction_check plus an amount_cents bigint. Integers, never floats — and the sign is carried by direction rather than by the number, though nothing constrains amount_cents to be positive, so that convention is yours to hold.
The invariant that defines double-entry, debits equalling credits within an entry, has no representation in this schema at all: no trigger, no deferred constraint, no CHECK spanning rows. Both sides go in one transaction and the application asserts the sum before commit, because a half-written entry is a perfectly valid row set as far as the database is concerned. Currency compounds that — it lives on accounts and not on lines, so an entry touching a USD account and a EUR account has nowhere to record a rate, and a single-currency book is the assumed case. Deletes cascade from user through accounts and entries, taking every line with them: this is a live ledger, not an archive.
Built for
idx_line_account on journal_lines.account_id, summing amount_cents grouped by direction and netting debits against credits. There is no stored balance to read instead, and none to reconcile.
idx_line_entry gathers every line for an entry_id in a single range, and journal_lines_direction_check guarantees each one is a debit or a credit, so both sides total without a lookup anywhere else.
The same idx_line_entry range, run inside the writing transaction. The database guards only the direction domain — no constraint spans the lines of an entry — so this check is application code or it does not happen.
idx_entry_posted on journal_entries.posted_at. posted_at is the only time column on the posting path; journal_lines carries none, so a period is always selected on the header and expanded through idx_line_entry.
idx_account_owner on accounts.owner_id picks the account set, then idx_line_account sums each account's lines. Ownership never appears on journal_lines, so there is no shortcut from a user straight to their postings.
Why Fintech ledger, specifically
The accounts table constrains type to the five canonical categories (asset/liability/equity/revenue/expense) via a DB CHECK — adding a new account class requires a migration, not just app code.
Debit/credit balance (sum of debits == sum of credits per entry) is enforced in application logic, not at the DB level; the schema's CHECK only guards direction values ('debit'/'credit'), so the invariant can be violated if bypassed.