e-arveldaja-mcp 0.31.0 → 0.32.0

package/CHANGELOG.md

@@ -2,6 +2,23 @@
 
 ## [Unreleased]
 
+## [0.32.0] - 2026-10-19
+
+### Changed
+
+- **The server and its test tools use updated maintenance releases.** Details: update dotenv to 18.0.8, Zod to 4.6.7 and Vitest to 5.0.5; retain the existing Node.js runtime requirement and other direct dependency versions.
+
+### Fixed
+
+- **Investment cash flow no longer becomes operating cash merely because a realized currency result uses another standard account.** Details: proved principal/result bundles use actual cash with consistent signed asset and result-family checks, retain acquisition fees and conventional accumulated-depreciation disposals, and hold unsupported combinations before generic fallbacks. Capital invoice slices must match account, dimension and direction. Malformed evidence preserves known cash gross amounts while retaining review status.
+- **An unregistered opening or reversal-shaped dividend draft cannot create dividend headroom.** Details: INITIAL is excluded from pending distributions; negative draft components cannot cancel valid reservations and now stop preview/create for review even with `force`. Ordinary pending distributions and registered opening equity retain their existing treatment. No accounting records are changed by these calculation fixes.
+
+- **Proved operating payments no longer require an unrelated invoice-balance audit.** Exact invoice links can classify prepayments and prior-year service settlements without a historical-capacity veto. Mixed invoice/direct operating distributions preserve their exact signed account/dimension slices; unrelated customer offsets no longer block them. Exact internal cash transfers with an external component and investment-principal/FX-result bundles are supported. Capital/mixed-invoice safeguards and unresolved result-only or FX evidence remain in place; no accounting entries are changed.
+
+- **Annual cash-flow reports separate noncash changes from actual receipts and payments.** Details: the indirect operating bridge now shows journal-level corrections for dividend declarations, loan offsets and other noncash changes, plus source-backed investing/financing reclassifications. Exact transaction-to-invoice links support capital payments; investment sales use actual cash proceeds rather than carrying value. Gross receipts/payments, separately proved FX effects, source IDs and unresolved counts remain visible. Missing or inconsistent evidence, unresolved gross movements or an indirect-versus-direct operating difference keep the report in `requires_review`; no reconciliation residual is assigned to operating cash. The declared method remains indirect. Evidence reads are selective, memoized and limited to 500 transaction details per report; no accounting data is written.
+
+- **Opening balances now come directly from e-arveldaja, with no separate local import.** Details: reporting, statement comparisons and dividend checks use API `INITIAL` journals exactly once. The local parser, store and `import_opening_balances` tool are removed; existing user files are untouched and no longer read. Draft, deleted or empty API openings are disclosed; multiple active openings stop calculation for review. No INITIAL is a normal absence. Annual starting positions include the opening balance while cash flows and year-end closing detection exclude it. Client and dimension attribution follow the original API postings. The standard/full surfaces now expose 126/146 tools; guided profiles remain 19/20. `list_journals` forwards its existing `operation_type` filter. Purchase-row fringe-benefit defaults and explicit values remain preserved; an ambiguous readback row mapping with nondefault fringe intent stops before the totals PATCH and uses the existing draft invalidation/error path.
+
 ## [0.31.0] - 2026-10-19
 
 ### Fixed

package/CLAUDE.md

@@ -1,7 +1,7 @@
 # e-arveldaja MCP Server
 
 TypeScript MCP server for the Estonian e-arveldaja (RIK e-Financials) REST API.
-127 tools by default on the compatibility-preserving `standard` profile; opt-in `guided` / `guided-sales` expose 19 / 20 tools, and `full` exposes all 147. The prompt registry holds 16 workflow prompts (guided profiles register fewer — a prompt whose required tools are all absent is not registered) and there are 15 resources across 12 modules. Supports multiple companies/accounts.
+126 tools by default on the `standard` profile; opt-in `guided` / `guided-sales` expose 19 / 20 tools, and `full` exposes all 146. The prompt registry holds 16 workflow prompts (guided profiles register fewer — a prompt whose required tools are all absent is not registered) and there are 15 resources across 12 modules. Supports multiple companies/accounts.
 
 ## Quick Start
 
@@ -77,32 +77,75 @@ serialized with an `O_EXCL` lock file at `<dir>.lock` (`withBundleLock()`).
 
 ### Opening balances (algbilanss)
 
-e-arveldaja's REST API omits the "Algbilansi kanded" (opening-balance entries)
-section, so the MCP server is otherwise blind to opening balances. The operator
-can paste that register once via the `import_opening_balances` tool
-(`src/tools/opening-balance-import.ts`): it parses the pasted text
-(`src/opening-balance-parse.ts`), checks that debit equals credit, previews
-the result under `dry_run` (default `true`), and on `dry_run=false` persists
-it as `opening-balances.json` in the same accounting-rules bundle described
-above (`src/opening-balance-store.ts`; requires bundle mode — not available
-under `EARVELDAJA_RULES_FILE` single-file mode). Because a bundle can be shared
-by several connections (`EARVELDAJA_RULES_DIR`, or a kept-in-place project/global
-bundle), the record — like each `statement-balances.json` record — is stamped with
-the active connection fingerprint and ignored (with a warning) on another
-connection; a legacy unstamped record applies only when exactly one connection is
-configured. Both files are written atomically 0600 and reads are capped at 1 MB. At compute time the stored
-balances are folded in as one synthetic journal dated at the opening date
-(`src/opening-balance-journal.ts`), so `compute_account_balance`,
-`compute_trial_balance`, `compute_balance_sheet`, `compute_profit_and_loss`,
-`generate_annual_report_data`, and the ÄS §157 dividend legality checks in
-`prepare_dividend_package` all include it automatically. The feature is
-**optional**: with nothing stored, everything behaves exactly as before,
-except the old blind "verify in the UI" warning becomes an actionable prompt
-pointing at `import_opening_balances` (`src/opening-balance-limitations.ts`).
-The `compute_account_dimension_balances` tool (`src/tools/account-balance.ts`)
-returns a per-dimension balance breakdown for one account (e.g. the LHV/Wise/
-Lightyear dimensions of account 1020), with the folded opening balances
-attributed per dimension; its `total` reconciles to `compute_account_balance`.
+e-arveldaja's REST API exposes "Algbilansi kanded" as `operation_type=INITIAL`.
+`loadJournalsWithOpeningBalance` identifies the opening journal in the original
+API journal set, preserving IDs, dates, clients, postings and dimensions. It never
+synthesizes or prepends a second journal. All balances, statements, annual reports
+and dividend checks use that same API data. INITIAL journals are starting
+positions, never cash flows or year-end close candidates.
+
+Registration, deletion, date, client and dimension filters still apply. A draft,
+deleted or empty opening is disclosed without applying its amounts; multiple
+non-deleted INITIAL journals or malformed D/C amounts fail for manual review.
+Missing dimension attribution is disclosed without dropping account-level totals.
+If no INITIAL exists after a complete API read, there is simply no opening entry;
+this is not an API coverage failure.
+
+The local parser, store and `import_opening_balances` tool have been removed.
+Existing `opening-balances.json` user files are untouched and no longer read.
+
+### Cash-flow report
+
+The annual report retains the indirect method (`indirect-evidence-v2`). Its
+per-journal profit, depreciation and working-capital bridge removes proved
+noncash and nonoperating components exactly once. Investing and financing use
+actual cash receipts/payments, with FX shown separately. A complete result needs
+both the bridge and independently classified cash movements to agree; unresolved
+amounts remain visible with gross totals and `requires_review`, never a plug.
+
+Supplier/customer invoice chains require exact transaction item references to
+registered invoice journals and matching transaction/posting amounts, direction,
+accounts and dimensions. A homogeneous operating source proves the cash-flow
+purpose even when the invoice was booked after payment or historical invoice
+capacity is unavailable; classification does not certify the invoice's open
+balance. Invoice-capacity safeguards still apply to capital and mixed sources.
+An unrelated customer's clearing cannot veto a proved operating payment.
+Exact invoice plus direct operating-account distributions are supported when
+their signed amounts and account/dimension slices cover the registered cash
+movement completely. Realized FX within an operating payment follows that
+payment rather than becoming a separate cash revaluation.
+
+Reads are selective and bounded to 500 transaction details, including exact
+internal-cash plus external distributions. Proven internal cash legs are
+eliminated; only the external portion contributes to cash flows. Partial mixed
+capital invoices, shared VAT allocation and missing evidence remain unresolved.
+Homogeneous capital payments include VAT in gross investing cash; a proved
+investment-principal/FX-result bundle uses actual cash without a duplicate FX
+effect. Principal/result proof requires a genuine nonzero asset principal,
+compatible asset/result family and the correct signed cash direction. It
+preserves securities acquisition fees and conventional fixed-asset disposals,
+including chart-proved accumulated-depreciation reversals and zero book value.
+An increasing asset plus income does not establish sale proceeds. Rejected
+bundles cannot fall through into a generic complete classification. Unsupported
+financing-principal/FX bundles require review; ordinary operating interest and
+fees retain their category. Capital-invoice evidence must bind source, item and
+payment to the same account/dimension and signed slice; an unsupported single
+invoice with multiple settlement dimensions remains unresolved.
+
+Malformed evidence keeps review status but retains every independently valued
+cash receipt/payment and identifies unvalued cash separately. Foreign raw units
+are never substituted for EUR, and INITIAL never becomes an external movement.
+Proven received interest/dividends use the operating
+default; ambiguous result-only accounts (3820/7100/7110/8330/8335) require review
+without principal evidence or an explicit account rule. Standard 1420/1430
+receivables retain their operating default. Explicit account rules take
+precedence. Public provenance lists are capped at
+500 rows with full counts/totals; pure calculation evidence remains uncapped.
+
+The pinned standard for 2018–2026 is [RTJ 2](https://www.fin.ee/sites/default/files/documents/2020-10/RTJ%202%20N%C3%95UDED%20INFORMATSIOONI%20ESITUSVIISILE%20RAAMATUPIDAMISE%20AASTAARUANDES.pdf),
+paragraphs 37–44 (indirect corrections, gross investing/financing and cash FX).
+Opening balances are maintained in e-arveldaja. Statement-closing snapshots
+(`statement-balances.json`) retain their separate connection-scoped bundle store.
 
 ### Tool exposure (per-session token cost)
 
@@ -110,7 +153,7 @@ attributed per dimension; its `total` reconciles to `compute_account_balance`.
 surface is a fixed per-session token cost. Eight env flags control optional
 parts of the surface (see `getToolExposureConfig()` in `src/config.ts`):
 
-`EARVELDAJA_PROFILE` provides one-choice surfaces: `guided` (19 merged daily-bookkeeping tools), `guided-sales` (those 19 plus the `manage_sale_invoice` sales façade — read plus the full prepare/execute mutation lifecycle: create/update/delete/confirm/invalidate/send/recurring and inline resolve-or-create customer, 20 total), `standard` (the absent-variable compatibility default, 127), or `full` (all 147, including granular/setup tools and the workflow-state paging tool `get_workflow_page`). Guided profiles are opt-in for this release. Any explicitly present legacy exposure flag forces the normalized profile to `custom` and preserves the flag combination below. Profile and catalog fingerprint are part of plan/file-reference scope: restart and obtain a fresh preview after changing them.
+`EARVELDAJA_PROFILE` provides one-choice surfaces: `guided` (19 merged daily-bookkeeping tools), `guided-sales` (those 19 plus the `manage_sale_invoice` sales façade — read plus the full prepare/execute mutation lifecycle: create/update/delete/confirm/invalidate/send/recurring and inline resolve-or-create customer, 20 total), `standard` (the absent-variable compatibility default, 126), or `full` (all 146, including granular/setup tools and the workflow-state paging tool `get_workflow_page`). Guided profiles are opt-in for this release. Any explicitly present legacy exposure flag forces the normalized profile to `custom` and preserves the flag combination below. Profile and catalog fingerprint are part of plan/file-reference scope: restart and obtain a fresh preview after changing them.
 
 The guided surface is sized for routing clarity, not token cost (per-tool measurement shows no cost cliff at 20). The **≤ 20** figure is a target, not a hard wall: 21–24 is a deliberate-exception band (allowed only with a recorded `CHANGELOG` rationale when no existing tool can absorb the capability), and 24 is the hard backstop above which the surface must be redesigned by merging tools rather than adding. Before adding any guided tool, apply the add/don't-add criteria in [`docs/guided-tool-policy.md`](docs/guided-tool-policy.md) — prefer a new `mode` on an existing façade, a `continue_accounting_workflow` continuation, or `standard`/`full` placement (as with `get_server_status`) over growing the daily surface.
 
@@ -186,13 +229,13 @@ without changing the default:
   `DISABLE_SALES` deployment usually sets this too — but the flags are
   independent. Saves ≈1.3k tokens (7 tools).
 
-The standard surface is 127 tools; `DISABLE_LIGHTYEAR` in a custom profile drops it to 122.
+The standard surface is 126 tools; `DISABLE_LIGHTYEAR` in a custom profile drops it to 121.
 `EXPOSE_GRANULAR_TOOLS` adds the 10 granular tools, `EXPOSE_SETUP_TOOLS` the 3
-credential tools; enabling both (with `full`'s `get_workflow_page`) raises it to the full 147. The five opt-out
+credential tools; enabling both (with `full`'s `get_workflow_page`) raises it to the full 146. The five opt-out
 group flags trim the default further — `DISABLE_TAX_TOOLS` (−4),
 `DISABLE_REFERENCE_ADMIN` (−9), `DISABLE_ANNUAL_REPORT` (−3), `DISABLE_SALES`
 (−13), `DISABLE_PRODUCTS` (−7) — so a lean purchase-side-only deployment with
-every disable flag set (incl. Lightyear) lands at 86 tools. (The former
+every disable flag set (incl. Lightyear) lands at 85 tools. (The former
 `prepare_accounting_inbox` / `run_accounting_inbox_dry_runs` tools were
 exact aliases of `accounting_inbox` `mode="scan"` / `mode="dry_run"` and have
 been removed — use `accounting_inbox` with the matching `mode`.)
@@ -242,7 +285,7 @@ OpenAPI spec: `GET /openapi.yaml` on the API server. HTML docs: `/api.html`.
 - Each distribution: `{related_table, amount, related_id?, related_sub_id?}`
 - `related_table` values: `"accounts"` (book to a GL account), `"purchase_invoices"`, `"sale_invoices"`
 - Example (purchase invoice): `PATCH /transactions/{id}/register` with body `[{"related_table":"purchase_invoices","related_id":123,"amount":59.94}]`
-- Example (account with dimensions): `[{"related_table":"accounts","related_id":1360,"related_sub_id":12637323,"amount":1620.70}]`
+- Synthetic example (account with dimensions): `[{"related_table":"accounts","related_id":1360,"related_sub_id":42,"amount":100.00}]`
 - **`related_sub_id` is REQUIRED when `related_table="accounts"` and the account has dimensions.** Pass the dimension ID there. Without it, the API rejects with `"Entry cannot be made directly to the account <code> since it has dimensions"`. Common case: account 1360 "Arveldused aruandvate isikutega" with one sub-account per reporting person.
 - **Do NOT pass the dimension ID into `related_id`.** That makes the API try to interpret it as an account ID and produces confusing errors like `"Dimension ID=<truncated> not found"`.
 - The dimension ID is the integer `id` value returned by `list_account_dimensions` (NOT a sub-account code or label). `related_id` is the integer account ID, `related_sub_id` is the integer dimension ID — both are the database IDs, not the human-readable account/dimension codes.
@@ -292,7 +335,7 @@ OpenAPI spec: `GET /openapi.yaml` on the API server. HTML docs: `/api.html`.
 - **`status: "PROJECT"`** — unconfirmed/draft
 - **`status: "VOID"`** — invalidated
 - **To delete**: invalidate a confirmed transaction first, then re-read before deleting. The live API returned `PROJECT` after invalidation on 2026-10-18; do not require a `VOID` readback to recognize a successful invalidation.
-- **Native GL distribution readback**: a confirmed transaction item may carry `relation_table: "accounts"`, explicit `accounts_id` / `accounts_dimensions_id`, and a composite `relation_id` formed from those two IDs (observed live: `1020`, `12762251`, `102012762251`). Accept that native shape only by exact equality with the explicit valid IDs, the reviewed target mapping and the actual unique registration journal. Never split a composite to infer missing IDs, and never send it as the request's `related_id`; write requests still use separate account and dimension fields.
+- **Native GL distribution readback**: a confirmed transaction item may carry `relation_table: "accounts"`, explicit `accounts_id` / `accounts_dimensions_id`, and a composite `relation_id` formed from those two IDs (synthetic example: `1020`, `42`, `102042`). Accept that native shape only by exact equality with the explicit valid IDs, the reviewed target mapping and the actual unique registration journal. Never split a composite to infer missing IDs, and never send it as the request's `related_id`; write requests still use separate account and dimension fields.
 
 ### Purchase invoice creation
 - **Always pass invoice-level `gross_price` and `vat_price`** — confirm fails without them ("Gross sum and net sum with taxes differ")
@@ -301,7 +344,7 @@ OpenAPI spec: `GET /openapi.yaml` on the API server. HTML docs: `/api.html`.
 - `client_name` is required on creation (API field `client_name2`)
 - For VAT tracking on items: set `vat_rate_dropdown`, `vat_accounts_id`, `cl_vat_articles_id`, `project_no_vat_gross_price`
 - **VAT-registered items with VAT need `vat_rate_dropdown`**: `createAndSetTotals` predicts item VAT as net × rate before the create; without a rate the item VAT is 0, so an explicit `vat_price` is refused pre-create (`purchase_totals_mismatch`, nothing written)
-- Non-VAT companies have two purchase forms: folded VAT (no VAT account, rate `"-"`, invoice `vat_price: 0`, gross in `project_no_vat_gross_price`) and non-deductible VAT (VAT account and dimension equal the item's cost account and dimension, article 11, one document rate, invoice `vat_price` equal to document VAT). Read back on 2026-10-18: Seppo OÜ invoice 5208707, account 7910 / dimension 942283, net 11.92 + VAT 1.07 = gross 12.99, rate 9. The latter is EUR-only and requires the chart account's `is_vat_account === false`; never use input-VAT account 1510. The same proof checks intended rows, both create read-backs and the fresh draft/chart before registration. Unproven drafts are held, never corrected automatically; edit rows in the UI or recreate the draft. Receipt batches and auto-classification keep folding.
+- Non-VAT companies have two purchase forms: folded VAT (no VAT account, rate `"-"`, invoice `vat_price: 0`, gross in `project_no_vat_gross_price`) and non-deductible VAT (VAT account and dimension equal the item's cost account and dimension, article 11, one document rate, invoice `vat_price` equal to document VAT). Synthetic example: cost account 7910 / dimension 42, net 10.00 + VAT 0.90 = gross 10.90 at rate 9. Exact source readback evidence is retained outside the repository. The latter is EUR-only and requires the chart account's `is_vat_account === false`; never use input-VAT account 1510. The same proof checks intended rows, both create read-backs and the fresh draft/chart before registration. Unproven drafts are held, never corrected automatically; edit rows in the UI or recreate the draft. Receipt batches and auto-classification keep folding.
 - **PATCH requires `items`** — updating invoice fields without including items fails with "Products/services are missing"
 - **Accounts with dimensions**: If an expense account (e.g. 5120) has dimensions (sub-accounts), you MUST pass both `purchase_accounts_id` (the account ID) AND `purchase_accounts_dimensions_id` (the dimension ID) on each item. Passing only one fails with "Entry must be made to account's dimension." Use `list_account_dimensions` to find dimension IDs for an account.
 
@@ -601,6 +644,7 @@ API data remains raw.
 - **Dividend booking (net vs. gross)**: `prepare_dividend_package` debits **only the net dividend** to retained earnings (Jaotamata kasum; account resolved by name against the company chart, standard 2960, override with `retained_earnings_account`). The CIT is a current-period **income-tax expense** (the P&L "Tulumaks" line), booked to an 8900-series Kulud account (auto-detected via `resolveIncomeTaxExpenseAccount`, override with `income_tax_expense_account`, default 8900), NOT a second debit to retained earnings. Per Estonian GAAP / RTJ the dividend income tax (TuMS § 50) is charged against current-year profit, not equity directly. All equity/liability accounts (retained earnings, dividend payable → standard 2650, dividend income-tax payable → standard 2656, share capital → standard 2900) are **name-resolved** against the actual chart via `src/account-resolution.ts`, with the standard number as fallback.
 - **ÄS § 157 legality checks are split by clause**: the **lg 1 ceiling is NET-based** — the ENTIRE lg 1 distributable profit (retained earnings 2960 + closed prior-year result on "Aruandeaasta kasum" 2970, name-resolved + unclosed prior-year P&L; never the distribution year's own result) is distributable as net dividend, since the CIT is not part of the payout; the **lg 2 net-assets floor is GROSS-based** (net assets fall by dividend payable + tax liability) at share capital **+ non-distributable reserves** (reservkapital, name-detected in the chart, standard 2940; override with `restricted_reserve_accounts`). Live unconfirmed dividend drafts (`DIV-…` or crediting dividend payable) are subtracted from both headrooms, since the tool books drafts and balances read only confirmed journals. The tool hard-blocks violations of either clause unless `force=true` (use only alongside a legitimate action such as a capital reduction; `force` never overrides the ledger-imbalance block), and always reports `maximum_distributable.max_net_dividend` = min(lg 1 distributable profit, (net assets − floor) × den/(den+num)), both net of pending drafts. One journal per shareholder+date: an identical retry returns `duplicate`, a different amount `dividend_key_conflict`.
 - **Year-end close (RIK method, calendar year).** e-arveldaja has no native closing; RIK's guide "Äriühingu majandusaasta lõpetamiskanded e-arveldajas" prescribes two manual entries, which `prepare_year_end_close` / `execute_year_end_close` propose and book as drafts: (1) Dec 31 profit D 9000 "Arvestuslik koondtulemus" / K 2970 "Aruandeaasta kasum" (loss reversed), document `YEC-RESULT-YYYY`; (2) Jan 1 of the next year D 2970 / K 2960 (optional `reserve_capital_amount` to 2940), document `YEC-RETAINED-YYYY`. Revenue/expense accounts are NOT zeroed and 9000 is not part of the income statement: every P&L surface (`compute_profit_and_loss`, `run_accounting_report`, `generate_annual_report_data`, prepare's result) excludes it, while the balance sheet keeps it in open P&L so equity balances. Existing entries are detected structurally (date + accounts touched, any document number, drafts included); legacy `YECL-YYYY` journals (the old zero-all-P&L close, `src/year-end-closing-journal.ts`) that post to 2970 count as entry 1 — never book either twice. Entry 2 is 2970 against 2960 and/or reserve accounts only (an all-to-reserve D 2970 / K 2940 counts); it is also recognised on any date of the next year when its amount matches (operators often transfer on another day), and by its `YEC-RETAINED-YYYY` number on any date; a journal numbered `YEC-RETAINED-`/`YEC-RESULT-` of another year is never this year's, not even on this year's 31 Dec / next 1 Jan; an unnumbered transfer-shaped journal on 31 Dec of the close year is dropped as an earlier year's late transfer when it moves exactly the earlier years' 2970 residual (ambiguous if it also equals this year's result), otherwise it needs manual review. Both entries are checked for direction and amount; a mismatch is reported as `mismatch`/`partially_closed` in `blocked_entries` and blocks booking — `allow_additional_transfer` acknowledges only a smaller same-direction 1 January transfer (the remainder is booked); an off-date, ambiguous, over- or reversed transfer and a wrong entry 1 always need manual correction. The dividend §157 lg 1 unclosed-P&L sum must INCLUDE 9000 (it cancels the still-open P&L once entry 1 exists).
+- **Pending dividend drafts:** INITIAL journals are excluded from this reservation scan. Reserve each candidate's retained-earnings and net-assets reductions separately at no less than zero, before summing. Negative raw components are disclosed as `pending_dividend_draft_anomalies` and stop both preview and create with `pending_dividend_draft_requires_review`; `force` cannot bypass uncertain draft reservations. Ordinary positive reservations, registered opening equity, duplicate handling and the fresh-ledger execute check remain in place.
 - **Dividend dry run**: `prepare_dividend_package` defaults to `dry_run=true` (preview only); call again with `dry_run=false` only after the user explicitly approves the previewed journal.
 - **Dividend statutory prerequisites** are echoed as `compliance_notes` on every path: ÄS § 157 lg 1 requires an APPROVED annual report + profit-distribution decision (attach the decision via `attach_document`), and the CIT is declared on TSD annex 7 by the 10th of the month after payout (TuMS § 54).
 - **Capital gains (company)**: securities gains are ordinary income in the P&L (Lightyear sells: gain balancing to 8330/8335); there is no tax at realisation — Estonian CIT is deferred until profit is distributed (dividend / TuMS § 50)
@@ -643,5 +687,5 @@ import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js"
 const transport = new StdioClientTransport({ command: "node", args: ["dist/index.js"] });
 const client = new Client({ name: "test", version: "1.0.0" });
 await client.connect(transport);
-const { tools } = await client.listTools(); // 127 tools (standard profile)
+const { tools } = await client.listTools(); // 126 tools (standard profile)
 ```

package/README.md

@@ -2,7 +2,7 @@
 
 [![npm](https://img.shields.io/npm/v/e-arveldaja-mcp)](https://www.npmjs.com/package/e-arveldaja-mcp)
 
-MCP server for the Estonian e-arveldaja (RIK e-Financials) REST API. 127 tools on the compatibility-preserving standard profile, 16 workflow prompts, 15 resources. Works with any MCP client — Claude Code, Codex CLI, Gemini CLI, Cursor, Windsurf, Cline, and others.
+MCP server for the Estonian e-arveldaja (RIK e-Financials) REST API. 126 tools on the standard profile, 16 workflow prompts, 15 resources. Works with any MCP client — Claude Code, Codex CLI, Gemini CLI, Cursor, Windsurf, Cline, and others.
 
 > **Year-end close now follows RIK's method (0.26.0, behaviour change).** `execute_year_end_close` no longer zeroes revenue and expense accounts into 2970 (that broke e-arveldaja's own income statement). It books RIK's two entries from the guide "Äriühingu majandusaasta lõpetamiskanded e-arveldajas": D 9000 "Arvestuslik koondtulemus" / K 2970 on 31 December and D 2970 / K 2960 (optionally part to reserve capital) on 1 January. Entries you already booked by hand — under any document number, on 1 January or later in the next year, plus the old `YECL-YYYY` closes — are detected and never booked twice; a partial, reversed, duplicate or mismatched entry is reported for manual review. Also in 0.26.0: the month-end checklist evaluates overdue invoices as of today while the month is open, `attach_document` refuses to replace an existing source document unless `replace_existing: true`, Lightyear sells book the cash the statement shows, and Wise import no longer changes confirmed purchase invoices. See the [changelog](CHANGELOG.md) for full details.
 >
@@ -14,7 +14,7 @@ MCP server for the Estonian e-arveldaja (RIK e-Financials) REST API. 127 tools o
 >
 > **Guided workflow actions.** `recommend_workflow` suggests the safest accounting flow for a natural-language goal, and key workflow/batch tools return a `workflow_action_v1` envelope with `recommended_next_action`, review questions, and approval previews. `accounting_inbox` is the preferred merged entry point for workspace triage, `continue_accounting_workflow` is the preferred merged continuation tool, `receipt_batch` and `process_camt053` are the preferred mode-based import/batch entry points, and bank work has `reconcile_bank_transactions` plus `classify_bank_transactions` as mode-based entry points. Older focused tools such as `resolve_accounting_review_item`, `prepare_accounting_review_action`, `scan_receipt_folder`, `process_receipt_batch`, `parse_camt053`, `import_camt053`, `reconcile_transactions`, and `apply_transaction_classifications` are hidden from the tool list by default to keep the per-session token cost down (the merged tools route to the same internals); set `EARVELDAJA_EXPOSE_GRANULAR_TOOLS=1` to register them again. See the [changelog](CHANGELOG.md) for full details.
 >
-> **Opening balances (algbilanss).** e-arveldaja's own "Algbilansi kanded" (opening-balance) register isn't exposed by the REST API, so the server was otherwise blind to it. The new `import_opening_balances` tool lets you paste that register once — it's parsed, checked that total debit equals total credit, and previewed (`dry_run=true` by default) before you confirm with `dry_run=false`. Once stored per company, account balances, trial balance, the balance sheet, P&L, the annual report, and the dividend §157 legality checks all fold the opening balances in automatically. Entirely optional — without it everything still works, just without opening-balance amounts folded in. See the [changelog](CHANGELOG.md) for full details.
+> **Opening balances (algbilanss).** Balances and reports use the API's `INITIAL` journals automatically, with their original dates, clients and dimensions. No local import is needed. Draft, deleted or empty API openings are disclosed; multiple active openings require review. See the [changelog](CHANGELOG.md) for details.
 >
 > **Active development.** This package is under active development and has not seen extensive real-world testing yet. If you encounter a bug or unexpected behaviour, please let me know via [GitHub Issues](https://github.com/iseppo/e-arveldaja-mcp/issues) or email at indrek.seppo@gmail.com.
 
@@ -115,17 +115,15 @@ By default these rules are stored as an [Open Knowledge Format](https://github.c
 
 The bundle is also browsable as MCP resources under `earveldaja://accounting_knowledge`. When several MCP clients share one bundle directory, concurrent rule writes are serialized with a lock file so the index never drifts out of sync with the concepts.
 
-### 4. Optional: import opening balances (algbilanss)
+### 4. Opening balances (algbilanss)
 
-e-arveldaja's own "Algbilansi kanded" (opening-balance) register isn't exposed by the REST API, so the MCP server can't see it unless you paste it in once. Copy the register from the e-arveldaja UI and ask your AI assistant:
+Opening balances come directly from e-arveldaja as `operation_type=INITIAL`. Account balances, statements, annual reports and dividend checks include registered, non-deleted opening postings with their original dates, clients and dimensions. If no INITIAL exists, calculations use the remaining API journals normally. Annual cash flow excludes the opening position.
 
-> "Import these opening balances into e-arveldaja-mcp" (paste the Algbilansi kanded text)
-
-The `import_opening_balances` tool parses the pasted register, checks that total debit equals total credit, and previews the result (`dry_run=true` by default) before you confirm with `dry_run=false`. Once stored, account balances, trial balance, the balance sheet, P&L, the annual report, and the dividend §157 legality checks all fold the opening balances in automatically. This step is entirely optional — without it, everything still works, just without opening-balance amounts folded in.
+The former `import_opening_balances` tool and local opening-register support have been removed. Existing local `opening-balances.json` files are left untouched and are no longer read. Manage opening balances in e-arveldaja.
 
 ### Trimming the tool surface
 
-Choose one explicit surface with `EARVELDAJA_PROFILE`: `guided` is the opt-in 19-tool daily-bookkeeping surface; `guided-sales` adds the `manage_sale_invoice` sales façade (20 tools) — reads invoices and runs the full sale-invoice lifecycle (create/update/delete/confirm/invalidate/send/recurring, plus inline resolve-or-create customer) behind the two-call prepare/execute approval gate; `standard` is the absent-variable compatibility default (127 tools); and `full` exposes all 147 tools, including granular and configured-mode credential administration. Every non-guided surface also carries `get_server_status`, a compact read-only report of the running version, active profile, and any active point-of-use release notices.
+Choose one explicit surface with `EARVELDAJA_PROFILE`: `guided` is the opt-in 19-tool daily-bookkeeping surface; `guided-sales` adds the `manage_sale_invoice` sales façade (20 tools) — reads invoices and runs the full sale-invoice lifecycle (create/update/delete/confirm/invalidate/send/recurring, plus inline resolve-or-create customer) behind the two-call prepare/execute approval gate; `standard` is the absent-variable compatibility default (126 tools); and `full` exposes all 146 tools, including granular and configured-mode credential administration. Every non-guided surface also carries `get_server_status`, a compact read-only report of the running version, active profile, and any active point-of-use release notices.
 
 The setup choices map exactly: **Daily bookkeeping** → `guided`; **Daily bookkeeping plus sales invoices** → `guided-sales`; **Bookkeeping plus investments** → `standard` with Lightyear enabled; **Full advanced toolset** → `full`. Guided profiles are opt-in in this release, not the recommended/default daily surface. After changing profiles, restart and run fresh previews; an old proposal or plan handle is never approval under the new profile.
 
@@ -140,7 +138,7 @@ The tool list is sent into the model's context on every session, so it is a fixe
 - `EARVELDAJA_DISABLE_SALES=1` — drops the sales-invoicing side: the 11 sale-invoice tools, `create_recurring_sale_invoices`, and receivables aging (`compute_receivables_aging`). Payables aging and all purchase-invoice tools stay. Use it for purchase-side-only bookkeeping.
 - `EARVELDAJA_DISABLE_PRODUCTS=1` — drops the product-catalog tools (`list/get/create/update/deactivate/reactivate/delete_product`). Products are chiefly the sale-invoice line-item catalog (purchase items key on `cl_purchase_articles_id`, though they can also carry an optional `products_id`), so a `DISABLE_SALES` deployment usually sets this too. It only removes catalog management — creating either invoice type still works — so the flags stay independent.
 
-A lean purchase-side-only custom deployment with every disable flag set (incl. Lightyear) has 86 tools instead of the standard 127. Conversely, `EARVELDAJA_PROFILE=full` exposes the complete 147-tool catalog.
+A lean purchase-side-only custom deployment with every disable flag set (incl. Lightyear) has 85 tools instead of the standard 126. Conversely, `EARVELDAJA_PROFILE=full` exposes the complete 146-tool catalog.
 
 `EARVELDAJA_DOCUMENT_READING=1` (opt-in, off by default) lets your assistant read a single invoice itself: `process_accounting_document` gains `mode='read'` and `mode='verify'`, every value is checked against the printed text, and only the questions the server cannot settle are put to you before the draft is created. It adds no tool, so the tool counts above do not change.
 

package/dist/accounting-rules.d.ts

@@ -69,8 +69,8 @@ export declare function initAccountingRulesConnection(getter: () => AccountingRu
 /**
  * The active connection's stable identity (the same connection fingerprint the
  * plan store scopes by) plus the configured connection count. Company-specific
- * data files stored in the bundle (opening-balances.json,
- * statement-balances.json) stamp this identity, because a bundle is NOT always
+ * data files stored in the bundle (statement-balances.json) stamp this identity,
+ * because a bundle is NOT always
  * per-connection: `EARVELDAJA_RULES_DIR` and the kept-in-place project/global
  * bundle are shared by every connection of the server.
  */
@@ -129,7 +129,6 @@ export declare function hasAnyAutoBookingRuleActionField(value: Partial<Pick<Acc
 export declare function hasConcreteAutoBookingRuleBookingTarget(value: Partial<Pick<AccountingAutoBookingRule, "purchase_article_id" | "purchase_account_id">>): boolean;
 export declare function resetAccountingRulesCache(): void;
 export declare function getAccountingRulesPath(): string;
-export declare function resolveOpeningBalanceStorePath(): string | null;
 /**
  * Size-capped JSON read for bundle data files: refuse (before reading) a file
  * above MAX_JSON_INPUT_SIZE so a runaway or planted file cannot exhaust memory.

package/dist/accounting-rules.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"accounting-rules.d.ts","sourceRoot":"","sources":["../src/accounting-rules.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAOxB,QAAA,MAAM,6BAA6B;;;EAAqC,CAAC;AACzE,QAAA,MAAM,sBAAsB;;;;EAAkD,CAAC;AAC/E,QAAA,MAAM,sBAAsB;;;;EAAsC,CAAC;AAEnE,QAAA,MAAM,yBAAyB;;;;;;;;;EAS7B,CAAC;AAcH,QAAA,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;iBAQzB,CAAC;AA+BH,MAAM,MAAM,2BAA2B,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,6BAA6B,CAAC,CAAC;AACxF,MAAM,MAAM,oBAAoB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AAC1E,MAAM,MAAM,gCAAgC,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AACtF,MAAM,MAAM,yBAAyB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAI9E,MAAM,WAAW,wBAAwB;IACvC,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,CAAC,EAAE,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,CAAC;IACrD,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,8BAA8B,CAAC,EAAE,MAAM,CAAC;IACxC,oBAAoB,CAAC,EAAE,MAAM,CAAC;IAC9B,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAID,UAAU,yBAAyB;IACjC,IAAI,EAAE,MAAM,CAAC;IACb,cAAc,EAAE,MAAM,CAAC;IACvB,8EAA8E;IAC9E,eAAe,CAAC,EAAE,MAAM,CAAC;CAC1B;AAGD,QAAA,MAAM,+BAA+B,YACnC,qBAAqB,EACrB,qBAAqB,EACrB,gCAAgC,EAChC,sBAAsB,EACtB,mBAAmB,EACnB,iBAAiB,CACT,CAAC;AAoDX,wBAAgB,6BAA6B,CAC3C,MAAM,EAAE,MAAM,yBAAyB,GACtC,IAAI,CAGN;AAED;;;;;;;GAOG;AACH,wBAAgB,uBAAuB,IAAI;IAAE,cAAc,EAAE,MAAM,CAAC;IAAC,eAAe,EAAE,MAAM,CAAA;CAAE,CAG7F;AAED,MAAM,MAAM,2BAA2B,GACnC;IAAE,MAAM,EAAE,IAAI,CAAC;IAAC,OAAO,CAAC,EAAE,SAAS,CAAA;CAAE,GACrC;IAAE,MAAM,EAAE,KAAK,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAiBvC;;;;;;;;GAQG;AACH,wBAAgB,yBAAyB,CAAC,cAAc,EAAE,OAAO,EAAE,KAAK,EAAE,MAAM,GAAG,2BAA2B,CAiB7G;AAKD,wBAAgB,qCAAqC,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CAW1E;AAED,wBAAgB,mCAAmC,CAAC,KAAK,EAAE,MAAM,EAAE,cAAc,EAAE,MAAM,GAAG,MAAM,CAKjG;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,0BAA0B,CACxC,WAAW,EAAE,MAAM,EACnB,eAAe,EAAE,MAAM,EACvB,cAAc,SAAY,EAC1B,cAAc,SAAiB,GAC9B;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,GAAG,EAAE,MAAM,CAAC;IAAC,UAAU,EAAE,MAAM,CAAA;CAAE,CAiBrD;AAqDD,oFAAoF;AACpF,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAiBtD;AAsDD,wBAAgB,cAAc,CAAC,CAAC,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE,MAAM,CAAC,GAAG,CAAC,CA0D7D;AA4ID,wBAAgB,gCAAgC,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAI1E;AAeD,wBAAgB,6BAA6B,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAEnE;AAED,wBAAgB,gCAAgC,CAC9C,KAAK,EAAE,OAAO,CAAC,IAAI,CACjB,yBAAyB,EACzB,OAAO,+BAA+B,CAAC,MAAM,CAAC,CAC/C,CAAC,GACD,OAAO,CAET;AAED,wBAAgB,uCAAuC,CACrD,KAAK,EAAE,OAAO,CAAC,IAAI,CAAC,yBAAyB,EAAE,qBAAqB,GAAG,qBAAqB,CAAC,CAAC,GAC7F,OAAO,CAET;AAuOD,wBAAgB,yBAAyB,IAAI,IAAI,CAGhD;AAED,wBAAgB,sBAAsB,IAAI,MAAM,CAM/C;AAED,wBAAgB,8BAA8B,IAAI,MAAM,GAAG,IAAI,CAI9D;AAED;;;GAGG;AACH,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,CAM1E;AAED,wBAAgB,gCAAgC,IAAI,MAAM,GAAG,IAAI,CAIhE;AAqDD,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,wBAAwB,GAAG;IACvE,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,UAAU,GAAG,SAAS,CAAC;IAC/B,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB,CAgCA;AA0ED,wBAAgB,mBAAmB,CACjC,sBAAsB,EAAE,MAAM,EAC9B,QAAQ,CAAC,EAAE,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,GACnD,yBAAyB,GAAG,SAAS,CAsBvC;AAED,wBAAgB,8BAA8B,CAAC,SAAS,EAAE,MAAM,GAAG,2BAA2B,GAAG,SAAS,CAEzG;AAED,wBAAgB,uBAAuB,CAAC,SAAS,EAAE,MAAM,GAAG,oBAAoB,GAAG,SAAS,CAE3F;AAED,wBAAgB,+BAA+B,IAAI,MAAM,GAAG,SAAS,CAEpE;AAED,wBAAgB,sCAAsC,IAAI,gCAAgC,GAAG,SAAS,CAErG;AAED,wBAAgB,uCAAuC,IAAI,MAAM,GAAG,SAAS,CAE5E;AAED,wBAAgB,yCAAyC,CACvD,cAAc,EAAE,MAAM,GACrB,gCAAgC,GAAG,SAAS,CAE9C;AAED,wBAAgB,0CAA0C,CACxD,cAAc,EAAE,MAAM,GACrB,MAAM,GAAG,SAAS,CAEpB;AAiTD,wBAAgB,0BAA0B,CACxC,KAAK,EAAE,yBAAyB,EAAE,GACjC,KAAK,CAAC;IAAE,YAAY,EAAE,MAAM,CAAC;IAAC,aAAa,EAAE,MAAM,EAAE,CAAA;CAAE,CAAC,CAiB1D;AAoLD;;;;;GAKG;AACH,KAAK,eAAe,GAAG;IACrB,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,EAAE,MAAM,CAAC;IACf,cAAc,EAAE,MAAM,CAAC;IACvB,KAAK,EAAE,MAAM,EAAE,CAAC;CACjB,CAAC;AAEF,wBAAgB,0BAA0B,CAAC,UAAU,EAAE,MAAM,EAAE,GAAG,EAAE,MAAM,GAAG,eAAe,CAY3F;AAyID,eAAO,MAAM,6BAA6B,sCAAsC,CAAC;AAEjF,MAAM,WAAW,0BAA0B;IACzC,+EAA+E;IAC/E,GAAG,EAAE,MAAM,CAAC;IACZ,8CAA8C;IAC9C,GAAG,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;IACpB,IAAI,EAAE,MAAM,CAAC;CACd;AAED,MAAM,WAAW,2BAA2B;IAC1C;4DACwD;IACxD,IAAI,EAAE,QAAQ,GAAG,aAAa,GAAG,OAAO,CAAC;IACzC,qEAAqE;IACrE,IAAI,EAAE,MAAM,CAAC;IACb;gEAC4D;IAC5D,aAAa,EAAE,MAAM,CAAC;IACtB,iEAAiE;IACjE,QAAQ,EAAE,0BAA0B,EAAE,CAAC;CACxC;AAgBD,2EAA2E;AAC3E,wBAAgB,8BAA8B,IAAI,2BAA2B,CA4C5E;AAED;;;;;GAKG;AACH,wBAAgB,8BAA8B,CAAC,GAAG,EAAE,MAAM,GAAG;IAAE,GAAG,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAAG,SAAS,CA2BrG"}
+{"version":3,"file":"accounting-rules.d.ts","sourceRoot":"","sources":["../src/accounting-rules.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAOxB,QAAA,MAAM,6BAA6B;;;EAAqC,CAAC;AACzE,QAAA,MAAM,sBAAsB;;;;EAAkD,CAAC;AAC/E,QAAA,MAAM,sBAAsB;;;;EAAsC,CAAC;AAEnE,QAAA,MAAM,yBAAyB;;;;;;;;;EAS7B,CAAC;AAcH,QAAA,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;iBAQzB,CAAC;AA+BH,MAAM,MAAM,2BAA2B,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,6BAA6B,CAAC,CAAC;AACxF,MAAM,MAAM,oBAAoB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AAC1E,MAAM,MAAM,gCAAgC,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AACtF,MAAM,MAAM,yBAAyB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAI9E,MAAM,WAAW,wBAAwB;IACvC,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,CAAC,EAAE,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,CAAC;IACrD,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,8BAA8B,CAAC,EAAE,MAAM,CAAC;IACxC,oBAAoB,CAAC,EAAE,MAAM,CAAC;IAC9B,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAID,UAAU,yBAAyB;IACjC,IAAI,EAAE,MAAM,CAAC;IACb,cAAc,EAAE,MAAM,CAAC;IACvB,8EAA8E;IAC9E,eAAe,CAAC,EAAE,MAAM,CAAC;CAC1B;AAGD,QAAA,MAAM,+BAA+B,YACnC,qBAAqB,EACrB,qBAAqB,EACrB,gCAAgC,EAChC,sBAAsB,EACtB,mBAAmB,EACnB,iBAAiB,CACT,CAAC;AAoDX,wBAAgB,6BAA6B,CAC3C,MAAM,EAAE,MAAM,yBAAyB,GACtC,IAAI,CAGN;AAED;;;;;;;GAOG;AACH,wBAAgB,uBAAuB,IAAI;IAAE,cAAc,EAAE,MAAM,CAAC;IAAC,eAAe,EAAE,MAAM,CAAA;CAAE,CAG7F;AAED,MAAM,MAAM,2BAA2B,GACnC;IAAE,MAAM,EAAE,IAAI,CAAC;IAAC,OAAO,CAAC,EAAE,SAAS,CAAA;CAAE,GACrC;IAAE,MAAM,EAAE,KAAK,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAiBvC;;;;;;;;GAQG;AACH,wBAAgB,yBAAyB,CAAC,cAAc,EAAE,OAAO,EAAE,KAAK,EAAE,MAAM,GAAG,2BAA2B,CAiB7G;AAKD,wBAAgB,qCAAqC,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CAW1E;AAED,wBAAgB,mCAAmC,CAAC,KAAK,EAAE,MAAM,EAAE,cAAc,EAAE,MAAM,GAAG,MAAM,CAKjG;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,0BAA0B,CACxC,WAAW,EAAE,MAAM,EACnB,eAAe,EAAE,MAAM,EACvB,cAAc,SAAY,EAC1B,cAAc,SAAiB,GAC9B;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,GAAG,EAAE,MAAM,CAAC;IAAC,UAAU,EAAE,MAAM,CAAA;CAAE,CAiBrD;AAqDD,oFAAoF;AACpF,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAiBtD;AAsDD,wBAAgB,cAAc,CAAC,CAAC,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE,MAAM,CAAC,GAAG,CAAC,CA0D7D;AA4ID,wBAAgB,gCAAgC,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAI1E;AAeD,wBAAgB,6BAA6B,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAEnE;AAED,wBAAgB,gCAAgC,CAC9C,KAAK,EAAE,OAAO,CAAC,IAAI,CACjB,yBAAyB,EACzB,OAAO,+BAA+B,CAAC,MAAM,CAAC,CAC/C,CAAC,GACD,OAAO,CAET;AAED,wBAAgB,uCAAuC,CACrD,KAAK,EAAE,OAAO,CAAC,IAAI,CAAC,yBAAyB,EAAE,qBAAqB,GAAG,qBAAqB,CAAC,CAAC,GAC7F,OAAO,CAET;AAuOD,wBAAgB,yBAAyB,IAAI,IAAI,CAGhD;AAED,wBAAgB,sBAAsB,IAAI,MAAM,CAM/C;AAED;;;GAGG;AACH,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,CAM1E;AAED,wBAAgB,gCAAgC,IAAI,MAAM,GAAG,IAAI,CAIhE;AAqDD,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,wBAAwB,GAAG;IACvE,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,UAAU,GAAG,SAAS,CAAC;IAC/B,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB,CAgCA;AA0ED,wBAAgB,mBAAmB,CACjC,sBAAsB,EAAE,MAAM,EAC9B,QAAQ,CAAC,EAAE,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,GACnD,yBAAyB,GAAG,SAAS,CAsBvC;AAED,wBAAgB,8BAA8B,CAAC,SAAS,EAAE,MAAM,GAAG,2BAA2B,GAAG,SAAS,CAEzG;AAED,wBAAgB,uBAAuB,CAAC,SAAS,EAAE,MAAM,GAAG,oBAAoB,GAAG,SAAS,CAE3F;AAED,wBAAgB,+BAA+B,IAAI,MAAM,GAAG,SAAS,CAEpE;AAED,wBAAgB,sCAAsC,IAAI,gCAAgC,GAAG,SAAS,CAErG;AAED,wBAAgB,uCAAuC,IAAI,MAAM,GAAG,SAAS,CAE5E;AAED,wBAAgB,yCAAyC,CACvD,cAAc,EAAE,MAAM,GACrB,gCAAgC,GAAG,SAAS,CAE9C;AAED,wBAAgB,0CAA0C,CACxD,cAAc,EAAE,MAAM,GACrB,MAAM,GAAG,SAAS,CAEpB;AAiTD,wBAAgB,0BAA0B,CACxC,KAAK,EAAE,yBAAyB,EAAE,GACjC,KAAK,CAAC;IAAE,YAAY,EAAE,MAAM,CAAC;IAAC,aAAa,EAAE,MAAM,EAAE,CAAA;CAAE,CAAC,CAiB1D;AAoLD;;;;;GAKG;AACH,KAAK,eAAe,GAAG;IACrB,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,EAAE,MAAM,CAAC;IACf,cAAc,EAAE,MAAM,CAAC;IACvB,KAAK,EAAE,MAAM,EAAE,CAAC;CACjB,CAAC;AAEF,wBAAgB,0BAA0B,CAAC,UAAU,EAAE,MAAM,EAAE,GAAG,EAAE,MAAM,GAAG,eAAe,CAY3F;AAyID,eAAO,MAAM,6BAA6B,sCAAsC,CAAC;AAEjF,MAAM,WAAW,0BAA0B;IACzC,+EAA+E;IAC/E,GAAG,EAAE,MAAM,CAAC;IACZ,8CAA8C;IAC9C,GAAG,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;IACpB,IAAI,EAAE,MAAM,CAAC;CACd;AAED,MAAM,WAAW,2BAA2B;IAC1C;4DACwD;IACxD,IAAI,EAAE,QAAQ,GAAG,aAAa,GAAG,OAAO,CAAC;IACzC,qEAAqE;IACrE,IAAI,EAAE,MAAM,CAAC;IACb;gEAC4D;IAC5D,aAAa,EAAE,MAAM,CAAC;IACtB,iEAAiE;IACjE,QAAQ,EAAE,0BAA0B,EAAE,CAAC;CACxC;AAgBD,2EAA2E;AAC3E,wBAAgB,8BAA8B,IAAI,2BAA2B,CA4C5E;AAED;;;;;GAKG;AACH,wBAAgB,8BAA8B,CAAC,GAAG,EAAE,MAAM,GAAG;IAAE,GAAG,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAAG,SAAS,CA2BrG"}

package/dist/accounting-rules.js

@@ -116,8 +116,8 @@ export function initAccountingRulesConnection(getter) {
 /**
  * The active connection's stable identity (the same connection fingerprint the
  * plan store scopes by) plus the configured connection count. Company-specific
- * data files stored in the bundle (opening-balances.json,
- * statement-balances.json) stamp this identity, because a bundle is NOT always
+ * data files stored in the bundle (statement-balances.json) stamp this identity,
+ * because a bundle is NOT always
  * per-connection: `EARVELDAJA_RULES_DIR` and the kept-in-place project/global
  * bundle are shared by every connection of the server.
  */
@@ -825,12 +825,6 @@ export function getAccountingRulesPath() {
         return storage.legacyFile;
     return storage.dir;
 }
-export function resolveOpeningBalanceStorePath() {
-    const storage = resolveStorage();
-    if (storage.mode === "file")
-        return null; // single-file legacy mode has no bundle dir
-    return resolve(storage.dir, "opening-balances.json");
-}
 /**
  * Size-capped JSON read for bundle data files: refuse (before reading) a file
  * above MAX_JSON_INPUT_SIZE so a runaway or planted file cannot exhaust memory.