The working accounting application: company-scoped journals, imported bank activity, share lots, bond schedules, derived reports, and local restore points. Entity and jurisdiction selections are stored metadata, not filing or compliance determinations.
Loading Workspace...
Operating Brief
This summary identifies the active IndexedDB ecosystem, selected company, and persistence state. The ledgers, mappings, import memory, and reporting periods beneath it belong to that selected company; reports are recalculated from its approved journal entries.
An ecosystem is the durable browser record selected and saved as a unit. It contains one or more companies and the workbook knowledge used during import. Each company owns a separate configuration, chart of accounts, mappings, journals, securities ledgers, bank activity, period state, import history, and change history. The application can switch between those books, but it does not consolidate them or create elimination entries.
A restore point captures the current ecosystem, including every company in that ecosystem, in the browser's IndexedDB snapshot store. When a writable directory or the included local Python server is available, the same action can also write a dated JSON save file. Browser restore points remain tied to this browser profile and origin, so a downloaded or disk-written JSON copy is the transferable backup.
This tab edits the selected company's account definitions and currency. A new company receives its own default chart according to its entity type; changing one company's chart does not rewrite another company's existing chart. Account code, account type, normal side, statement category, cash-flow category, and posting permission are the fields the calculation and validation modules actually consult.
The selected company begins with a default chart and a mapping row for each account. Adding a custom account adds it to that company and normalizes its mapping; posted lines continue to refer to account codes, so changing descriptive metadata does not rewrite historical journal lines.
Create a new account to extend the standard COA.
| Code | Name | Type | Statement Category | Source |
|---|
Download the active ecosystem as JSON, or replace the active ecosystem by importing a JSON snapshot after
reviewing its company, account, and journal counts. Other ecosystems already stored in IndexedDB are not folded
into this single JSON file. The disk selector is available only when the workbook is served by
local_server.py; a direct file:// opening cannot call that save service.
Saved restore points from the local workbook server appear here.
âš Warning: These actions cannot be undone.
Manual entries are checked line by line, rejected when debits and credits differ by one cent or more, and posted directly as approved entries when the period is open and a change reason is supplied. Imported records, accepted bank suggestions, and stock events can instead enter the staged queue for explicit approval or rejection.
The queue retains pending, approved, and rejected states. Approval checks the balance again, refuses a locked period, copies the entry into the approved journal store, and records the decision. Approved staged entries may be reopened by the supplied Undo controls; loading a pending entry into the form creates a reviewed replacement rather than silently changing the proposed record.
No staged journal entries.
Imported bank rows remain distinct from journal entries. The matcher compares cash amount, date, transaction language, account route, and period, then either proposes an existing approved entry or prepares a new staged entry. Accepting a proposal records the link; it does not make the heuristic score an accounting determination.
No staged bank transactions.
Only entries whose status is Approved feed the general ledger and live statements. The interface can
edit an approved entry while its period remains open, and it can create equal-and-opposite reversal entries.
Those operations append before-and-after records to local change history, but that history is part of the same
editable local dataset and is not an independently secured audit log.
A bank account record contains an internal account ID, bank name, masked number, and an ordered transaction array. Debit less credit is accumulated for account and monthly summaries. Reconciliation compares each staged bank row with approved journal cash lines, and the report shows bank activity, general-ledger cash activity, variance, and transactions lacking a journal link. It is a review aid, not an automated bank-feed connection.
| Account | Date | Description | Category | Debit | Credit | Balance | Source Status | Match State |
|---|
Stock events are stored by date, period, class, holder, share quantity, price, and transaction type. Issuances create holder lots; transfers, buybacks, and treasury movements consume those lots in date order and preserve the consumed cost across the destination or treasury lot. Splits change the shares remaining while retaining total lot cost. For for-profit companies, issuance, buyback, declaration, and payment events also produce staged journal entries; transfer and split records use zero-value marker entries because they alter the ownership ledger without themselves moving cash.
| Class | Per Share | Interval | Declaration | Payout | Notes | Actions |
|---|
| Date | Period | Class | Type | Shares | Price | Total | Holder ID | Holder Name | Extra |
|---|
The workbench records issuer, buyer or counterparty, issue and maturity dates, face value, issue price, coupon terms, and effective rate. If price or yield is omitted, the preview derives the missing value for a fixed-coupon or zero-coupon instrument. It then builds one schedule row for every configured reporting period intersecting the bond term, prorates interest over a 365.25-day year, and forces the final carrying value to face value. Creating the bond presently posts issuance, accrual, coupon, and redemption entries for the entire lifecycle directly into the approved journal store, so the operator must examine that future-dated posting policy before relying upon period reports.
| Bond ID | Issue Date | Maturity | Type | Face Value | Issue Price | Yield | Counterparty ID | Counterparty Name | Actions |
|---|
The importer reads CSV, TSV, Excel, ODS, and JSON sources through FileReader and SheetJS. Dragged directories are traversed when the browser exposes directory-entry or directory-handle APIs. Rows from all accepted files enter one review session; dates, monetary fields, descriptions, counterparties, institutions, account identifiers, categories, references, and transaction types are normalized before any journal entry reaches the ledger. Vocabulary and accepted-route memory are stored with the active company, not sent to an external service.
1. Raw Collection Hold: Source filename, detected type, rows, and reference values are retained together while more files may still be added.
2. Normalization Hold: Header detection proposes field mappings; date and amount parsers canonicalize values, while text similarity and remembered aliases propose normalized names. Confidence values describe those proposals and do not certify their accounting meaning.
3. Deduplication Hold: Amount, date, description, counterparty, account, reference, and semantic evidence are combined to cluster probable repetitions, including complementary sales-journal and bank rows. Removed candidates remain visible in the session for review.
4. Relation Mapping Hold: Heuristics propose primary and offset account codes, statement categories, cash-flow buckets, and review flags. This is the point at which an operator must reject a plausible linguistic match that does not express the transaction's actual substance.
5. Journal Staging Hold: Generated entries can be sent to journal acceptance, where balance and period-lock checks run again. Committing the import stage is not the same operation as approving the resulting journal entries.
Export is blocked when the active company has no chart or periods, an unbalanced trial balance, a failed balance sheet equation, invalid bond amortization, unresolved generated-entry errors, draft or pending journal entries, pending bank review, unmapped posted accounts, or a locally detected formula problem. Passing those checks means only that the current in-browser checks passed; it is not an external review of the records or their treatment.
The live report layer reads only approved journal entries for the selected company. The
general ledger rolls prior configured periods into opening balances and isolates current-period debit and credit
activity. The income statement classifies revenue and expense accounts by account type, code, name, and statement
category; the balance sheet accumulates asset, liability, and equity accounts and adds current unclosed earnings.
Cash flow begins with journal lines posted to account 1000, then allocates each cash movement among
operating, investing, and financing buckets from its counterpart accounts. Comparative views place the latest four
quarters or four years side by side, while drill-down panels return to the journal lines beneath a selected amount.
The operative program is a browser application whose HTML loads distinct source modules for setup, normalization, validation, accounting calculations, company persistence, journal review, bank activity, stocks, bonds, imports, and reports. Its stated ambition is broader than its verified implementation. The account below concerns the implementation now in those modules, not the accounting product that later work is intended to complete.
The central distinction is between an ecosystem and a company. The root store identifies one active ecosystem
and contains a collection of companies. The current-company index determines which company-scoped arrays the
familiar store.journalEntries, store.stockLedger, store.bondLedger,
store.bankAccounts, and store.mappings accessors expose. This permits several separate
books to inhabit one ecosystem without merging their transactions. It does not presently calculate consolidated
statements, intercompany eliminations, or combined cash.
| Stored layer | Implemented fields and collections | How the application uses them |
|---|---|---|
| Ecosystem record | Version, ecosystem ID and name, current-company index, company collection, workbook knowledge, and save/load timestamps | The whole record is the unit written to the IndexedDB ecosystem store and the unit downloaded by JSON backup. |
| Company configuration | Name, fiscal-year start, entity type, currency, jurisdiction label, language, reporting frequency, and configured periods | These values select defaults and reporting windows. Currency and jurisdiction are labels; there is no tax-return generator or foreign-exchange engine behind them. |
| Posting model | Chart of accounts, account mappings, approved journals, staged journals, staged bank transactions, period status, and change history | Approved journal lines are the source for ledger and statement calculations. Staged records remain outside those calculations until approval. |
| Specialized ledgers | Stock events and dividend settings, bond instruments and counterparties, bank accounts and their transaction arrays | Each specialized module maintains its own operational detail and creates or links journal entries where its current workflow provides that connection. |
| Import state | Drafts, preview rows, import history, normalization vocabulary, accepted routing prototypes, aliases, and corrections | Later import sessions can reuse normalized names and account routes learned from entries the operator accepted. |
| Recovery state | Named snapshots in IndexedDB, a localStorage cache, and optional dated JSON files | The cache starts the interface quickly; IndexedDB is the durable browser store; JSON is the portable recovery form. |
A manual journal entry begins as a date, period, number, memo, source type, change reason, and an array of lines. Each line stores account code, debit, credit, memo, and optional restriction, function, holder, bond, and fund references. The form prevents a line from carrying both a debit and a credit and disables posting when total debits and credits differ by at least one cent. A successful manual entry is normalized, marked approved, and supplied with creation and approval timestamps.
Imported and module-generated entries may instead remain pending. The approval operation repeats the balance test, refuses to enter a locked period, copies the normalized record into the approved journal, updates a linked bank transaction when one exists, and records what was approved. Rejection leaves the proposal in its rejected state. An approved staged item can later be reopened with Undo, while a posted entry can be reversed by creating a new entry whose debits and credits exchange sides.
The import path deliberately has more intermediate state. It collects rows from all files in a session, detects headers, normalizes candidate fields, computes field confidence, reconciles related rows, clusters probable duplicates, proposes statement and account relations, and generates journal candidates. Its similarity logic compares amounts, dates, descriptions, counterparties, account identifiers, references, institutions, and vectorized transaction language. Those comparisons are useful for narrowing a review queue; they cannot determine from prose alone whether a purchase is an asset, an expense, a prepaid item, or some other treatment requiring facts absent from the source file.
The bank matcher looks for the largest cash-like line in each approved journal entry. It compares that signed cash effect with a staged bank row, then computes a score weighted 46 percent to amount similarity, 21 percent to date, 24 percent to transaction language, 6 percent to the proposed debit/credit route, and 3 percent to exact period agreement. Candidates below 72 are not offered as existing-entry matches. Strong combinations of amount, date, language, and route can raise the composite score, while weak semantic and route evidence reduce it.
Acceptance has two materially different results. Where an approved journal candidate exists, the bank row is linked to that entry without creating a second posting. Where none exists, acceptance builds a balanced cash and offset proposal and places it in the staged-journal queue. The reconciliation report then totals the selected bank account's transactions for a period, totals approved account-1000 journal activity for that period, reports their variance, and identifies unlinked bank rows. The method does not obtain balances from a financial institution, and it has no three-way reconciliation, foreign-currency remeasurement, exception aging, or dispute workflow.
The stock state is rebuilt from dated events sorted by date and record ID. Every issuance opens a lot for a particular holder and share class, carrying shares remaining, cost remaining, acquisition price, and source date. A transfer consumes the source holder's oldest lots first and creates destination lots with the same allocated cost. Buyback and treasury operations likewise consume the source lots and move the filled quantity into holder zero, the treasury profile. A split multiplies remaining shares while leaving lot cost unchanged. The resulting snapshot reports holdings and average cost by holder and issued, treasury, and outstanding shares by class.
Stock accounting is narrower than the ownership ledger. For a for-profit company, issuance separates par value and additional paid-in capital, buyback posts treasury stock against cash, and declared and paid dividends use retained earnings, dividend payable, and cash. Transfer, split, and treasury-movement records generate zero-value marker entries rather than a monetary posting. Scheduled dividend settings can generate period entries during close. The module does not establish that a chosen par value, dividend, transfer, or repurchase is authorized by corporate documents.
The bond workbench supports two instrument types: fixed coupon and zero coupon. For a fixed-coupon bond, the pricing preview discounts scheduled coupons and principal at the supplied yield; when yield is absent and issue price is present, a bounded binary search estimates the yield. For a zero-coupon bond, price and yield are related by the compounding-frequency formula. Carrying value is advanced over the company's configured reporting periods with interest prorated by days over 365.25, coupon accrual separated from actual coupon dates, and the final row adjusted to equal face value.
Bond creation currently writes the whole modeled lifecycle to the approved journal: issue proceeds and payable, periodic interest and discount or premium movement, coupon payments, and principal redemption. Entry numbers prevent the same lifecycle row from being generated twice for one bond. This is not a general debt-contract engine: there is no selectable day-count convention, floating-rate reset, call or put schedule, conversion, covenant test, modification accounting, extinguishment analysis, or evidence that future-dated entries ought to be posted before their events occur.
| View | Present calculation | Material boundary |
|---|---|---|
| General ledger | Approved lines before the selected period become opening activity; approved lines in the period become current debit and credit activity. Closing balance follows each account's normal side. | Only configured account codes are represented; a line whose code is absent from the chart is skipped by the ledger builder. |
| Trial balance | Debit-side and credit-side account balances are totaled after opening and current activity. | The view calls the result balanced when the difference is less than one cent. That arithmetic test says nothing about classification or omitted transactions. |
| Income statement | Current-period revenue and expense accounts are grouped using type, statement-category text, account codes, and account-name tests; gross profit, operating income, pretax income, tax provision, EBIT, EBITDA, and net income follow from those groups. | Classification depends upon the chart and naming conventions. It is not an extensible ruleset for every industry or reporting policy. |
| Balance sheet | Cumulative asset, liability, and equity balances are divided between current and non-current categories. Cumulative revenue less expense is added as current unclosed earnings when no close-to-retained-earnings entry has removed it. | The equation check verifies assets against liabilities plus equity; it does not validate valuation, recognition, impairment, or disclosure. |
| Cash flow | Cash movements are taken from approved lines posted to account 1000 and allocated among operating, investing, and financing categories according to counterpart-account type, code, category, and name. | The returned working-capital-change collection is presently empty. This is not the complete indirect-method reconciliation described in the project's intended end state. |
| Not-for-profit views | A not-for-profit company receives default fund and restriction records; revenue and expense reporting uses account types and functional statement-category labels for program, administration, and fundraising. | The current live activities view does not provide a complete restriction-class roll-forward, and the restriction-class export pathway remains incomplete. |
The browser database is named accounting_workbook and contains object stores for ecosystems,
snapshots, and preferences. Saves write the normalized active ecosystem to IndexedDB and maintain a localStorage
cache under acct_store_v1. Named restore points capture a full ecosystem snapshot. The optional
local_server.py binds only to 127.0.0.1:8000 and adds three endpoints for listing, loading,
and writing JSON files in the project's local saves directory. Without that local service, browser
storage and downloaded JSON remain the available persistence mechanisms. There is no account system, remote
database, synchronization between devices, server-side encryption, or automatic off-machine backup.
A period lock requires a reason and runs closure checks for unresolved staged journals, pending bank review, trial balance, account mappings, bond schedules, and other diagnostics. The save path compares a proposed state with its last committed snapshot and reverts a detected mutation of a locked period. The same interface can nevertheless unlock a period, and both the lock record and change history live inside the user's editable local state. The word immutable in a lock record therefore describes application behavior while the lock remains in force; it does not describe cryptographic immutability or custody by an independent party.
XLSX and ODS exports are assembled from the active company's current data with SheetJS. The generated workbook includes configuration, periods, chart, journal lines, period-by-period general ledger, latest-period statements, stock and bond detail, bank rows, trial balance, mappings, and a CompatibilityCheck sheet. Some closing balances, totals, comparisons, and named ranges are emitted as spreadsheet formulas; many other cells are calculated values from the browser engine. CSV export downloads every generated sheet separately and cannot retain live formulas. The export gate is valuable because it prevents a known unresolved state from being downloaded, but a gate that passes its programmed checks cannot establish that the source records, mappings, estimates, or reporting policy are correct.
The direct project specification classifies this repository for internal development and pilot use. It records useful books and performs concrete calculations, but it has not been independently validated for statutory filing, tax submission, audited statements, complete GAAP treatment, complete not-for-profit treatment, or cross-application spreadsheet fidelity. Its bank matching remains heuristic; its company books are not consolidated; period locks are reversible; browser persistence is origin- and profile-specific; the cash-flow implementation is not the intended full indirect method; and several advanced import, reconciliation, close, and NFP requirements remain unfinished. These are boundaries of the current source, not qualifications hidden behind a claim of completeness.