General Ledger — please sign in
Clerk isn’t configured on this preview, so access control is running
in demo mode. Pick a user to sign in as. Set
CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY
to switch to real Clerk sign-in, MFA and password reset.
General Ledger
The books haven’t been opened yet. Create the consortium’s ledger — a standard chart of accounts, a locked prior month and an open current month — and start posting.
The core translates this document into a balanced entry — debit Accounts Receivable, credit Sales Revenue and Sales Tax Payable. You never compute a debit.
A bill debits the expense you choose and credits Accounts Payable, tagged with the vendor so per-vendor payables reconcile to the control account automatically.
Every member's capital lives in one equity account — Partner Investments — tracked per member by a balance key like partner:alice. An investment debits Cash and credits the member's equity; a capital return reverses that; yearly operation dues move capital out of the member's stake into Operation Dues revenue. The engine reconciles every key to the control account automatically.
When a member funds a loan directly they earn 8% on their contribution; the consortium keeps the rest (the 2% spread on member-funded dollars, the full interest on group-funded dollars, and the $195 admin fee) in the DHC Joint Pot. A member who leaves takes their Partner Investments balance plus their ownership share of the pot. The table below is a live projection for members still in the group — ownership counts active members only.
When a member notifies the group they want to leave, their payout is locked in at that moment: their Partner Investments balance plus their pro-rata share of the DHC Joint Pot (their share of active members' capital). The pot is reduced by exactly that share, the member is marked departed and dropped from future ownership calculations, and the payout is booked as an obligation the group still owes — it need not be paid immediately.
The core records the disbursement as a balanced entry — debit Loans Receivable, credit Cash — plus a flat $195 origination fee. The 10% interest is recognised as income as the borrower pays. You never compute a debit.
Each run posts a fresh invoice through the same Core boundary (debit A/R, credit Revenue + Tax). Auto-charge then attempts a Stripe payment and posts the cash receipt.
Manual entry — Atomic Wallet has no API. Current price (CoinGecko) and USD value are shown live.
Manual entry by weight. Current spot price and USD value are shown live (requires the metals feed).
The low-level posting primitive. Lines must net to zero or the engine refuses the write. Debits are positive, credits negative.
The engine guarantees the books are correct. The core decides what the books mean. A front-end talks to the core in the language of documents — invoices and bills; the core talks to the engine in the language of balanced entries. The engine talks to no one — it only enforces.
POST /api/documents/invoice · /bill
POST /api/journal-entries
| Account type | Normal balance | Statement | Resets at close |
|---|---|---|---|
| Asset | Debit | Balance sheet | No — permanent |
| Liability / Equity | Credit | Balance sheet | No — permanent |
| Revenue | Credit | Income statement | Yes — temporary |
| Expense | Debit | Income statement | Yes — temporary |
Liability and equity collapse into one credit-normal type at the engine level — they behave identically. The debt-vs-equity split lives in the chart, not the type system.
Everything that touches money is a balanced entry of two or more lines. The engine never lets an unbalanced entry commit.
Posted entries are never edited or deleted. A mistake is fixed by posting a reversing entry — an audit trail by construction.
Front-ends submit invoices and bills. They never compute a debit. The core decides the postings; the engine enforces the balance.
A posting’s date determines its period. A locked period refuses new entries — corrections become visible back-dated entries, never silent edits.
A line can carry a balance key — a customer, a vendor. The engine reconciles each key to its account total without learning what the key means.
The engine tracks revenue and expense; it does not close them. Closing net income into retained earnings is a core concern.
The full design notes and Prisma schema live in /docs in the repository.
The consortium lends its pooled partner capital to small businesses. A
disbursement debits Loans Receivable and credits Cash; the flat
$195 origination fee and any late fees credit Loan Fee Income; and a
payment debits Cash, crediting Loan Interest Income for the
interest portion and Loans Receivable for the rest. Each loan is tracked
as an opaque balance_key sub-ledger of Loans Receivable — the same
mechanism behind per-customer receivables and per-partner equity — so every loan
reconciles to the control account by construction. How each entry is formed is
documented in /docs/loans.md and in netlify/lib/loans.ts.
Members may also fund an individual loan directly. When a funded loan is activated, the Core posts one balanced allocation entry that shares out the loan's earnings: each contributor earns 8% on what they put in (credited to their Partner Investments key), and the remaining interest plus the $195 admin fee flow to the group-level DHC Joint Pot. When a member leaves, one balanced exit entry locks in their payout — their capital plus a pro-rata share of that pot — by moving both into an Owed to Departed Members liability and reducing the pot accordingly; the member then drops out of all future ownership calculations. All still ordinary journal entries the engine enforces.
Recurring billing (Stripe) and bank feeds (Plaid) are layered above the
engine, never around it. A due recurring schedule generates an invoice through the
same Core boundary, and an automatic payment posts a normal cash receipt — both are
ordinary balanced entries the engine enforces. Imported bank transactions are matched
against existing journal entries during reconciliation; they never rewrite them. Where
each piece of Stripe and Plaid logic lives is documented in
/docs/integrations.md.
Invite by email and assign a role. In real Clerk mode the person signs up in Clerk with this email and is linked automatically on first sign-in; in demo mode they become selectable on the sign-in screen immediately. A member must be linked to a Partner Investments balance key (e.g. partner:andy) — that key scopes everything they can see.