--- title: "Accounting core (GL)" description: "The general ledger layer. Specs for 18 React components: JournalEntry, JournalEntryForm, JournalEntryTable, AccountPicker and 14 more." canonical: "https://lopifi.com/docs/catalog/accounting-core" --- # Accounting core (GL) > The general ledger layer. Specs for 18 React components: JournalEntry, JournalEntryForm, JournalEntryTable, AccountPicker and 14 more. Source: https://lopifi.com/docs/catalog/accounting-core Part of: Lopifi — Planned: US GAAP books on autopilot, checked by a CPA (https://lopifi.com) --- # Accounting core (GL) The general ledger layer. Model in [`domain/accounting-model.md`](https://lopifi.com/md/docs/domain/accounting-model); schedules in [`domain/schedules-and-accruals.md`](https://lopifi.com/md/docs/domain/schedules-and-accruals). --- ## 91. `JournalEntry` > Debit and credit as **two columns**. There is no single-signed-column variant. ``` JE-2026-0841 · 30 Sep 2026 · Adjusting · Posted [Reverse] [Audit trail] Accrue September professional fees Account Dept Debit Credit 6410 · Professional fees G&A 12,000.00 2150 · Accrued liabilities 12,000.00 ───────── ───────── 12,000.00 12,000.00 ✓ balanced ⟲ Reverses 1 Oct 2026 · Evidence: Baker & Co engagement letter.pdf ``` **Layer 4:** 3 sizes (`title-md` header · `body` labels · `figure-sm` amounts), 2 weights. `tnum` + `case` on both amount columns; the columns are independently right-aligned and each hugs its own gutter. **Rules:** balance check always visible · unbalanced is a prominent error with the difference stated · source and status on the header · **no delete action on a posted entry — absent, not disabled** · reversal linked bidirectionally, both entries remain visible · evidence inline. **Motion:** none. Server-safe (no `"use client"`) — a 400-line entry renders on the server. ## 92. `JournalEntryForm` Line grid with account, dimensions, debit, credit, memo. Running balance check updates live at the bottom. Tab moves across the row, Enter adds a line, and the amount fields follow [`AmountInput`](https://lopifi.com/md/docs/catalog/payments#amountinput) rules. Reads `requiredDimensions` from the account the moment it's picked and adds those fields inline. Blocks posting into a closed period with the [cutoff explanation](https://lopifi.com/md/docs/domain/periods-and-close#3-cutoff), not a bare rejection. Opens prefilled from `defaultLines`, `defaultDate` and `defaultDescription` (a template, a reversal, a resumed draft); fewer than two lines are padded, because an entry has two sides. ## 93. `JournalEntryTable` All entries, filterable by period, source, account, dimension, actor. Gapless-numbering check surfaced as a banner when a gap exists. ## 94. `AccountPicker` Searchable by number and name, grouped by type and sub-classification. **Shows the normal balance** (`Dr`/`Cr`), because someone posting to an unfamiliar account needs to know which side increases it. Non-postable rollup accounts are visibly disabled, with the reason. Inactive accounts hidden but searchable. Virtualized; typeahead on the account number. The search field is a `combobox` pointing at the active `option` with `aria-activedescendant`; the list is windowed at a fixed row height (`hooks/use-option-keys`, shared by every picker) and the active option is kept in view. ## 95. `ChartOfAccounts` Hierarchical tree, max 5 levels, with type, normal balance, contra flag, statement mapping, and current balance per account. Bulk edit of mapping. Flags accounts with no supporting-schedule mapping, which is a finding in itself. ## 96. `AccountRegister` GL detail for one account: every entry, with a **running balance** column. It's where an accountant goes when a tie-out fails. Opening and closing balance rows both tie to the trial balance. ## 97. `DimensionPicker` Entity, department, location, class, project, customer, vendor. Entity always required and always visible. Renders only the dimensions the chosen account requires. ## 98. `AdjustingEntryForm` Templated by adjustment type — accrual, deferral, depreciation, amortization, provision, reclass, true-up. **`autoReverse` defaults to true for accruals**, with the reversal date shown inline ("Reverses 1 Oct 2026"). The scheduled reversal is visible in the next period before it posts. ## 99. `RecurringEntryTemplate` Template plus schedule. Instances are `source: "recurring"` and read-only; the template is editable and edits apply forward only. ## 100. `EntryReversalDialog` `AlertDialog` with hold-to-confirm, stating exactly what will happen: "Reverse JE-2026-0841? This creates an offsetting entry dated 30 Sep 2026. The original stays in the ledger." A reversal in a closed period is dated in the current open period, and the closed date isn't offered. --- ## 101. `ScheduleTable` > One component, configured per schedule type. Prepaids, accruals, deferred revenue, fixed assets, intangibles, leases, debt. Columns are type-specific; the shell, the totals row, and the tie-out are shared. Every row drills to the entries behind it, and they sum to the row. Fully released items are shown, then dropped. Rows that vanish silently make a schedule impossible to follow. Variants ship as presets: `prepaid` · `accrual` · `deferred-revenue` · `fixed-asset` · `intangible` · `lease` · `debt`. ## 102. `RollForward` > **The most reusable component in the accounting family.** Every schedule is this shape. ``` Opening · + Additions · − Releases · ± Adjustments · = Closing Closing vs. GL balance → Difference (must be zero or explained) ``` Asserts opening = prior closing and closing = GL. The difference is always visible; a non-zero difference becomes the main state of the screen and requires an explanation. Every movement is passed **signed** and states its sign exactly once: a release that reduces the balance is negative and renders `(552,000)` with the paren column reserved. No operator glyph sits beside the label, since a "−" next to a parenthesized figure reads as a double negative. The explanation is required whenever the closing doesn't tie to the GL or the walk doesn't foot. It's controlled, so the host can save it with the close: ```ts explanation?: string; // the saved text onExplanationChange?: (explanation: string) => void; ``` With both, the box is an editable textarea. With `explanation` alone it renders read-only, for review. With neither it is a scratch field the host never sees — don't ship that. ## 103. `AccountTieOut` The balance-sheet walk-down: GL balance vs. supporting schedule closing balance, difference, supporting evidence, reviewer, and date. **Every balance sheet account gets one.** An account with no supporting evidence renders an explicit "Unsupported" state rather than nothing. ## 104. `SchedulePreview` Every entry the period's schedules will generate — amortization, depreciation, recognition, straight-line lease expense — with totals, **before** anything posts. A close should never be surprised by its own automation. Posts as one batch with one audit record. ## 105. `RevenueWaterfall` The deferred revenue balance recognizing by future period, by performance obligation. The number every SaaS board asks for. Bars, not a table, with the table equivalent behind `DataTableToggle`. ## 106. `DepreciationSchedule` `ScheduleTable` preset. Cost, in-service date (**not** purchase date, labeled explicitly), life, method, convention, accumulated depreciation, NBV. Book and tax books in parallel with the difference shown. Disposal shows the working: `Proceeds − NBV = Gain/(Loss)`. NBV can never breach salvage — asserted. ## 107. `LeaseSchedule` ROU asset and lease liability as **parallel columns**, because they amortize on different curves and diverge. Discount rate displayed with its source. Operating vs. finance classification labeled, with the correct P&L presentation for each. Maturity analysis (undiscounted by year, reconciled to the discounted liability) as a linked view. ## 108. `AllowanceRollForward` Opening allowance → provision → write-offs → recoveries → closing, with the **methodology displayed**: "2% of current + 5% of 1–30 + 10% of 31–60 + 35% of 61–90 + 100% of 90+", each input traceable to the aging. Write-off and provision are named as distinct actions, because they have different P&L effects. Each methodology input's `rate` is in percent (`2` is 2%, `0.5` is 0.5%), never a fraction — the unit every rate in this system takes.