Source truth: - Vision - UX Principles - ADR 0020: Initial Release Scope and Financial Workflow Taxonomy - Provider Agnostic Import Boundaries - Accounting Posting Foundation - Close Runs and Report Packs - Persisted Report Runs - Sales and Receivables Summary Facts and Posting Templates - Reviewable Accounting File Intake - Operational Summary Workflow Boundaries and Purchasing Facts - Contractor Classification and Information-Return Filing - Initial Release Single-Currency Boundary - Managed Local PostgreSQL Launch Deployment - Desktop Identity Model - First-Run Production Administrator Bootstrap - Summary Accounting - Accounting Import Run Contract - Accounting Import Candidate Contract - Chart Import Contract - Starter Chart Installation Contract - Account Role Contract - ADR 0032: QBO-First Controlled Cutover - ADR 0034: Sales Tax Accounting and Remittance Boundary - Sales Tax Accounting and Remittance Contract - Company Conversion Run Contract - Purchasing and Payables Summary Fact Contract - Banking and Finance Summary Fact Contract - Accounting Correction Contract - Close Run Contract - Reporting Contract - Roles and Permissions Contract

BP3 Initial Release Plan

This page turns the initial BP3 release decision into an implementation sequence.

BP3 is the internal name for the third BooksPlus iteration. The public initial release should be treated as BooksPlus 1.0 unless external product continuity later requires a different version label.

Planning maintenance model

This is the single maintained roadmap and slice-planning page for the BP3 initial release. Keep release sequencing, step status, the active step's slice plan, handoffs, risks, and concise completion records here.

At the start of a step or slice:

Read the governing canonical truth, contracts, accepted ADRs, repository guidance, and current implementation.
Resolve truth gaps before implementation depends on new product meaning.
Add or refine the active slice in this file with a bounded outcome, dependencies, exclusions, verification, and acceptance criteria.
Split a slice when it crosses domain ownership, can be independently verified, needs a separate truth decision, or is too large for one reviewable change.
When a slice completes, replace transient implementation detail with a concise record of the outcome, verification, and remaining handoff.

Do not create a separate overview or permanent plan page for each step or slice. A temporary separate plan is justified only when the active work cannot remain readable here; merge its durable outcome back into this page and remove it when the slice closes. Durable reference artifacts with independent use, such as starter-chart templates and exact provider projections, remain separate and link back to the governing truth.

Release objective

BP3 should ship a coherent accounting control system:

guide setup and onboarding;
preserve company, period, account, source-document, posting, audit, and authorization truth;
accept reviewable period-summary facts from ordinary business operations;
post accounting effects through one central posting path;
support correction, close, and reporting from posted ledger truth;
defer operational sales, purchasing, banking, payment, and perpetual-inventory systems.

The first release should make the accounting result explainable before it makes external operations automatic.

Current implementation baseline

Initial development passes in bp3 have completed Steps 1 through 6. These passes establish the main service boundaries, repositories, Postgres test conventions, protected-action seams, audit events, source identity, source-document references, central posting, period eligibility, summary-batch review patterns, and the Summary Transaction Desk.

The remaining release plan should treat those passes as a baseline to polish and extend, not as final production completeness. Later workflow work should reuse the existing kernel and summary-accounting patterns instead of bypassing them for speed.

Step status

Accepted ADRs 0020, 0024, and 0032 govern the Step 7 through 14 names and sequence. Step 7 is complete, including the bounded clearing and canonical-route alignment. Steps 8 through 10 are complete. Step 10 now carries its canonical Finance boundary, application chart readiness, preparation, durable posting and non-posting results, atomic open-balance controls, protected Summary orchestration, and central posting. Step 11 is complete with its canonical correction boundary, preparation, durable workflow, protected central posting, and ledger-derived review. Step 12 now has its canonical CloseRun, check, waiver, approval, finalization, reopen, evidence, report-pack, authorization, audit, replay, and hierarchy boundary; non-persistent launch-check evaluation; durable Close workflow, recovery, and company backup; and protected, recovery-safe finalization and reopen. Step 12 is complete with a read-only Close review and report-pack coordination boundary that keeps control evidence, period history, Reporting references, Source Document evidence, protected audit, and posted-ledger correction disclosure in their canonical ownership. Step 13 now has its canonical Reporting boundary for standard report definitions, live results, immutable ReportRuns, calculation, currentness, Close consumption, authorization, audit, replay, backup, and drilldown. Step 13 now has protected non-persistent preparation for its three standard reports, with canonical availability, calculations, fingerprints, source contributions, and visible blocking issues. Step 13 now also persists immutable ReportRuns with verified PostgreSQL restart, interruption recovery, company isolation, and backup/restore behavior. The Slice 3 Reporting-owned Close resolver is implemented and verified. A bounded period-history persistence repair now preserves causal state-change order through equal timestamps, repository restart, Close finalization and reopen, and company backup/restore. Step 13 is complete with protected live and captured report review, immutable snapshot drilldown, computed currentness, and explicit separation of formal report truth from current support context, Close references, protected audit, and presentation concerns. Step 14 Slice 14A is complete with accepted QBO-first controlled-cutover truth and a separate company-scoped CompanyConversionRun. Slice 14B now qualifies a versioned, non-production QBO fixture-package profile without connectivity or persistence. Slice 14C1 adds explicit fingerprinted account-mapping review and stages new chart rows through canonical chart import without committing them. Durable conversion review ownership in Slice 14C2A is durable, protected, audited, and included in exact company backup/restore. Slice 14C2B now qualifies and persists exact opening controls and protected approval. Opening application and recovery in Slice 14C2C now reuse canonical chart and opening-balance owners with durable interruption recovery. Slice 14D live QBO extraction is complete. Slice 14E now qualifies exact protected live captures into the existing controlled- cutover fact shape, fails closed on unavailable or inconsistent controls, and reuses the already-qualified recoverable conversion path. Step 14 is complete. ADR 0034 subsequently expanded the BooksPlus 1.0 boundary with bounded seller-owned sales-tax accounting and remittance control. Slices 15B0T1 through 15B0T5 have accepted and implemented the canonical contract through Close evaluation; 15B0T6 remains the desktop and functional-UAT boundary before the affected Summary surfaces can be completed. Subsequent startup-scenario user testing reopened the desktop acceptance outcome for Step 3: the application resolves company context before sign-on completes, does not expose company creation or selection, does not visibly invoke the accepted production-administrator bootstrap, and has no reviewed resolution path for a starter-chart account-code collision. Steps 4 through 14 remain complete. Step 3R1 now provides first-run company entry and visible production administrator bootstrap. Step 3R2 implementation and automated verification are complete. UAT-0001 and UAT-0002 were rerun successfully on 2026-08-03; the collision and navigation issues are resolved, and the database-backed journal entry persists after restart. Step 3 is complete. Follow-on UAT exposed a missing workspace-level return to company selection and an incomplete Ledger entry-line presentation. Step 15A1 resolved the company-selection limitation, and 15R1 passed desktop acceptance as UAT-0004. Slice 15A2 then established the canonical Setup Readiness Contract. Step 15 now turns the completed service and workflow baseline into a releasable desktop product. It begins with a complete UI exposure inventory and functional UAT, defers production user/permission friction until functional workflows are stable, and ends with installer, licensing, customer-doc, and clean-machine release qualification.

Step	Status	Current outcome or next action
1. Release truth and navigation	Complete	ADR 0020 and this release plan govern scope and sequence.
2. Accounting kernel	Complete	Central posting, periods, accounts, source evidence, security/audit, and trial balance provide the shared kernel.
2T. Business time and period cutoffs	Complete	Company owns a persisted named accounting time zone, and shared half-open FinancialPeriod cutoff resolution is reused without adding location masters, user preferences, or consolidation.
3. Setup & Onboarding	Complete	UAT-0001 and UAT-0002 are resolved; follow-on multi-company workspace acceptance passed under Step 15A1.
4. Current Period Workbench	Complete	Manual work, source and posted registers, exceptions, readiness, and drilldown are available.
5. Summary Accounting foundation	Complete	Shared batch intake, validation, evidence, preview, readiness, posting, and result-link patterns are implemented.
6. Summary Transaction Desk simplification	Complete	The selected summary batch and its next action lead current-period work; supporting registers remain available.
7. Sales and Receivables Summary	Complete	Sales-source receipts use receipts-for-deposit clearing and canonical routes preserve durable identity compatibility; the later ADR 0034 sales-tax extension is planned under 15B0T.
8. Purchasing and Payables Summary	Complete	Purchasing, payables, contractor support, protected filing, recipient statements, and linked correction submissions are implemented.
9. Inventory Summary	Complete	Standard-cost period summaries, revisions, Inventory-owned PPV, Summary orchestration, durable recovery, and company backup are implemented.
10. Banking and Finance Summary	Complete	Accepted Finance facts and results prepare, persist, reconcile, reserve, review, and post through the protected Summary and central Accounting paths.
11. Corrections	Complete	Posted corrections are prepared, persisted, protected, posted once, and reviewable as immutable ledger-derived chains with workflow support kept separate from report truth.
12. Period Close	Complete	Close evaluation, durable workflow, protected transitions, recovery, and read-only historical review preserve control evidence without becoming ledger or formal report truth.
13. Reporting	Complete	Protected live and captured review preserves immutable report truth, currentness, source drilldown, and separate support and audit context.
14. QBO controlled conversion	Complete	In the replacement scenario, exact protected QBO captures qualify into an immutable conversion import only when every required source and control fact is available and consistent. Startup scenarios do not enter this workflow.
15. Release readiness and production delivery	Active	Step 15A, UAT-0005, 15B0, and sales-tax slices 15B0T1-T5 are complete. The 15B0T6 desktop control is implemented and awaits development-mode functional UAT; UAT-0006 remains a later 15G/15K production authorization gate.

Completed-step handoffs

Steps 2 and 3 established the company, period, account-role, central-posting, source-evidence, protected-action, append-only-audit, setup-readiness, and opening-balance service foundations. Step 3 desktop startup acceptance is reopened only for the bounded remediation units below; later work must reuse the completed foundations.
Step 4 established the Current Period Workbench, manual posting, supporting registers, lightweight exception state, and source/audit drilldown without a second posting path or persisted task system.
Step 5 established Summary Accounting as workflow staging rather than ledger or report truth, with company-scoped batches, replay/conflict handling, issues, evidence, prepared previews, protected transitions, posting results, and in-memory/PostgreSQL coverage.
Step 6 made the Summary Transaction Desk the primary current-period surface, demoted sample posting controls, retained supporting registers, and carried semantic account-role readiness into Steps 7 through 10.

Launch workflow model

The four Summary workflow names below are binding under accepted ADRs 0020 and 0024.

Workflow area	Launch meaning	Explicitly deferred
Setup & Onboarding	Organize responsibilities, policy defaults, company setup, fiscal periods, chart, opening balances, permissions, and support practices; this is the complete startup-scenario entry path	Built-in support-access grant, use, and revoke workflows; permanent vendor/support access; full implementation-services practice management
Current Period Workbench	Current-period review surface for source documents, manual entries, exceptions, posting readiness, and posted activity	Treating daily cadence as its own accounting domain
Sales and Receivables Summary	Summarized revenue, sales tax, receivable creation, distinct Sales-source receipt-clearing results, and bounded seller-owned sales-tax reconciliation, return support, remittance accounting, evidence, and bank linkage	Sales orders, shipping, customer invoice operations, collections, payment execution detail, tax determination, return transmission, and tax-payment initiation
Purchasing and Payables Summary	Summarized product and service purchases, operating expenses, inventory acquisitions, prepayments, accruals, payables, contractor/vendor facts, and 1099 support	Purchase orders, receipts, vendor invoice operations, payable subledger detail, payment execution detail, BillCatcher, capital projects, and the fixed-asset lifecycle
Inventory Summary	Summarized inventory ins and outs, ending inventory, cost of goods sold, variances, and reconciliation evidence	Operational stock movement, item master, warehouse, production, and perpetual valuation detail
Banking and Finance Summary	Summarized receipt and disbursement clearing, bank and credit-card effects, reconciliation, and reviewed closing balances	Bank-feed detail, deposit composition, payment instruments, and reconciliation execution detail
Corrections	Reversal and adjustment paths that preserve posted history	Silent mutation of posted accounting records
QBO controlled cutover	Replacement-scenario transition from one existing QBO company through captured evidence, reviewed mappings, controls, approval, and protected application	Applying conversion requirements to startup scenarios; full history and recurring synchronization
Period Close	Close runs, checks, warnings, blockers, waivers, approvals, period transitions, and close evidence	Using close as ordinary transaction entry
Reporting	Formal reports, persisted report runs, close packs, and review support	Reports based on workflow staging records instead of posted ledger truth

Workflow family mapping

ADRs 0020 and 0024 govern the release workflow taxonomy and the Step 7 through 10 boundaries below. The taxonomy does not change posting rules, close rules, source-document ownership, audit behavior, reporting basis, or summary- batch state.

Launch workflow area	Family placement	Implementation impact
Setup & Onboarding	Mainly Financial Control; opening balances also belong under Correction & Conversion Controls	Keep the existing setup and onboarding slice. Do not move chart, period, permission, or posting rules into a navigation taxonomy.
Current Period Workbench	Operating and exception review surface for current-period work	Keep the workbench as the active current-period surface for source documents, manual entries, summary batches, exceptions, and posted activity.
Sales and Receivables Summary	Operating Transaction Capture / Revenue & receivables	Keep Sales-source invoice and clearing events distinct from related Inventory and Banking events. Preserve upstream tax determinations, distinguish seller-owned from facilitator-remitted tax, and require ADR 0034 contracts before adding return or remittance behavior.
Purchasing and Payables Summary	Operating Transaction Capture / General expenses and Purchasing & payables	Include product, service, inventory-input, prepaid, and contractor purchases while operational detail remains external; hold potentially capitalizable purchases.
Inventory Summary	Operating Transaction Capture / Inventory & production	Link to Sales shipments and Purchasing receipts without duplicating their source events or importing operational stock detail.
Banking and Finance Summary	Operating Transaction Capture / Cash & banking	Own bank, credit-card, clearing, and reconciliation events; related invoice references explain settlements but do not recreate invoices.
Corrections	Correction & Conversion Controls	Corrections still use reversal or adjustment behavior and must not silently mutate posted records.
Period Close	Close Processing	Close continues to own close runs, checks, waivers, approvals, close evidence coordination, and close-driven period transitions.
Reporting	Ledger and close review support	Reporting is not a transaction family; formal reports continue to derive from posted ledger truth.

Future app navigation must add explicit metadata before exposing the full family tree as executable workflow actions: family label, group label, workflow label, and implementation status (active, planned, or deferred). Existing screens should remain wired to their current workflows until a later implementation slice changes navigation.

Scope boundaries

BP3 should rely on an external operational system for:

sales orders;
customer invoices;
purchase orders;
supplier bills;
payment execution;
receipt and banking operations;
perpetual inventory operations.

BooksPlus may accept summaries, schedules, exports, and evidence from those systems. That intake must normalize into BooksPlus business language before any workflow, posting, close check, or report consumes it.

BooksPlus 1.0 includes the bounded seller-owned sales-tax control accepted by ADR 0034: source-to-ledger reconciliation, filing-summary workpapers, protected approval, external filing and payment evidence, remittance posting, and later bank linkage. BooksPlus does not calculate tax, originate invoices, transmit returns, initiate payments, or provide general compliance management. This expanded boundary remains truth-gated until its canonical contract and dependent Sales, Finance, Close, Security/Audit, and Backup contract amendments are accepted.

Payroll accounting is deferred. Purchasing and Payables Summary may still support contractor classification, contractor payment accounting, W-9/1099 fact capture, and 1099 support reports.

BillCatcher, capital projects, and the entire fixed-asset lifecycle—including fixed-asset acquisition, ledger maintenance, placed-in-service treatment, and depreciation—are deferred to a subsequent release. Potentially capitalizable purchases must remain held rather than being silently classified into an initial-release purchase component.

Built-in support-access grant, use, and revoke workflows are deferred beyond the initial release. ADR 0016 still prohibits hidden, shared, permanent, or undocumented support access, and the Roles and Permissions Contract does not create a production support role or grant. The detailed Support Access Contract remains draft until a dedicated truth and implementation sequence defines its identity, lifecycle, authorization, audit, persistence, recovery, and visible revocation behavior.

Architecture guardrails

Use these guardrails throughout BP3 development:

All ledger effects go through the central Accounting posting path.
Workflow staging records are review state, not report truth.
Formal reports derive from posted journal entries and current reporting rules.
Source Documents owns evidence identity, references, and supersession.
Close coordinates checks, waivers, approvals, and period transitions; it does not bypass Accounting.
Imports and adapters map into provider-agnostic intake contracts before domain workflows use them.
File and machine intake require source identity and idempotency expectations.
Account-role resolution is preferred over hard-coded account codes.
Consequential actions require authorization and audit evidence.
Initial-release postings use the owning company's one base or reporting currency; unsupported foreign-currency facts remain held.
The supported launch database profile is BooksPlus-managed local PostgreSQL; sensitive production data remains gated on the accepted and verified encryption, backup, restore, recovery-key, and evidence-storage design.

Early workflow slices should keep thin guardrails in place: actor and company context, protected-action seams, audit events, source identity or evidence references, period eligibility, and central posting. Richer cross-cutting features can be deferred when they would slow workflow learning, including granular permission-management UI, broad audit-log exploration UI, mailbox/document-storage workflows, connector polish, backup/export/restore workflow depth, and step-up confirmation UX polish.

Development sequence

Goal: make the release target explicit before expanding implementation.

Build:

release-scope ADR and this development plan;
workflow naming updates in derived user documentation;
open-issue cleanup for launch workflow navigation;
contributor links from the application repository to this plan.

Exit criteria:

BP3 scope and deferred operational responsibilities are visible in the wiki.
Developers can identify which workflow slice should be built next.

2. Stabilize the accounting kernel

Goal: protect the shared behavior every workflow will depend on.

Build:

company context and repository boundaries;
fiscal period generation and status control;
account maintenance, account roles, and chart import;
source-document persistence and supersession;
central posting service and posting-date eligibility;
security authorization and append-only audit events;
trial balance from posted ledger lines.

Exit criteria:

no workflow writes journal entries directly;
posting blocks ineligible periods and inactive accounts;
source evidence and audit references are preserved where implemented;
starter chart behavior uses account roles for semantic needs.

3. Build Setup & Onboarding

Goal: make the business ready to post before ordinary accounting work begins.

Build:

onboarding readiness checklist;
roles and responsibility setup;
policy baseline and policy-default review;
company identity and reporting currency review;
fiscal calendar setup and period opening;
chart install/import/review;
opening-balance entry support;
permission setup and protected-action visibility.

Setup & Onboarding consumes Step 2 chart behavior for starter chart install, staged chart import, account maintenance, and account-role review. It must not redefine chart import, account-role, or account maintenance rules outside the canonical truth and contracts.

Exit criteria:

a company can be brought from empty database to open first posting period;
opening balances post through Accounting;
setup work leaves reviewable evidence or audit history.

4. Build the Current Period Workbench

Goal: create the common surface for daily review without making cadence a domain.

Build:

source-document register;
manual journal entry preparation and posting;
posted journal-entry register;
exception queue;
period status and posting-date visibility;
drilldown from entries to source documents and audit events.

Exit criteria:

users can see what needs attention in the current open period;
manual accounting work posts through the central posting path;
posted activity is reviewable by period and source.

5. Add summary accounting foundation

Goal: let workflow families share a normalized period-summary pattern.

Build:

summary batch identity and status;
source-system identity and import metadata;
source-world event dates and BooksPlus acceptance time;
idempotency handling for file and machine intake;
validation issue records;
evidence linkage;
prepared journal-entry preview;
posting result linkage.

Exit criteria:

income, expense, and inventory accounting can use the same batch pattern;
replays with the same source identity and idempotency key are handled deliberately;
conflicting imports are held for review instead of overwritten.

6. Simplify the Current Period Workbench around the summary transaction desk

Goal: make the Current Period Workbench the active operating and exception surface for summary batches, posting readiness, source evidence, and posted activity in the current open period.

Build:

make the summary transaction desk the primary current-period posting work surface;
keep source documents, manual entries, exceptions, and posted activity as supporting registers;
surface held, conflicting, and failed summary batches as the main workbench action queue;
reduce or remove sample posting affordances and development-only posting controls that distract from launch workflow behavior;
preserve setup, chart, and account-role readiness visibility as blockers before summary posting.

Readiness gate:

chart/account readiness has been reviewed against Step 2 and Step 3 work;
starter/default chart review, staged chart import, account-role review, semantic account-role resolution, and missing-role visibility are already present for launch setup readiness;
Sales and Receivables, Purchasing and Payables, Inventory, and Banking and Finance Summary templates must declare their semantic account-role requirements and surface missing required roles before preparing or posting summary accounting previews.

Exit criteria:

the workbench centers current-period work on the summary transaction desk;
held, conflicting, and failed summary batches are visible as actionable current-period exceptions;
source documents, manual journal entries, posted journal entries, and setup readiness remain reachable without treating daily cadence as its own accounting domain;
the remaining chart/account readiness risk is carried into the four Summary workflow template areas.

7. Build Sales and Receivables Summary

Goal: account for summarized sales and receivable results while detailed sales orders, shipping, invoicing, receivables, and payment processing remain in the operational system.

Build:

Sales and Receivables Summary workflow wrapper;
revenue, receivable, sales-tax, deposit, and receipt accounting templates;
income template account-role requirements and missing-role readiness messages;
source-document and external-reference linkage;
period review and exception handling;
posting through Accounting.

Exit criteria:

a fiscal period can receive Sales and Receivables summaries and post balanced entries;
summary totals reconcile to source evidence;
required income account roles are visible before preparing or posting summary accounting previews;
sales operational records remain outside BooksPlus.

Completed Step 7 baseline

The existing bp3 implementation already provides company-scoped summary batches, source and idempotency identity, replay/conflict handling, validation issues, Source Document evidence links, immutable-account previews, onboarding and period validation, protected readiness and posting transitions, audit events, posting-result links, and central Accounting posting. Step 7 extends those boundaries; it must not create a second ledger, posting service, source-document identity model, audit model, or batch state machine.

ADR 0021 defines the accepted implementation baseline's Sales facts and role-based templates. ADR 0022 defines mixed-file import runs, transaction-level idempotency, explicit change type, and visible workflow routing. ADR 0024 keeps distinct Sales-source customer payments in Step 7, requires them to debit receipts-for-deposit clearing, and assigns later bank deposit clearing to Step 10. That clearing policy is resolved and accepted; it is not a Step 7 truth gate. A bounded implementation-alignment slice must update existing receipt preparation and canonical route names without creating duplicate posting.

Step 7 source-file strategy

Use the supplied standard Dolibarr accounting export as the first manual, reviewed, versioned file profile when its grouping, dates, source identity, account resolution, amounts, and balance can be established safely. Treat journal codes and subaccounts as source metadata, not BooksPlus accounting meaning. The import session may supply company, actor, source system, profile version, and a verified single currency.

Keep the file as raw evidence and normalize it into provider-agnostic BooksPlus contracts. Uncertain identity, change type, dates, counterparty/tax facts, or related-event meaning must become visible issues rather than inferred truth. Filtering occurs after parsing and normalization so an Income selection cannot discard Expense, Inventory, Opening Balance, Correction/Reversal, or unclassified groups.

A packaged Dolibarr adapter is deferred beyond the initial release. Preserve a future custom-extract handoff when the standard export cannot reliably supply immutable source and line identity, original/correction/reversal relationships, document dates, customer/invoice/receipt/deposit/tax facts, stable change identity, or links between revenue and related inventory facts.

Step 7 slices

Slice	Status	Outcome	Implementation and acceptance
0. Truth and contract readiness	Complete	Establish Income and mixed-file meaning before code depends on it.	ADRs 0021 and 0022 define facts, templates, identity, explicit change type, correction boundaries, and provider-agnostic routing.
1. Import-run and raw-file boundary	Complete	Accept an authorized company-scoped file without parsing or ledger effects.	`AccountingImportRun` preserves exact bytes and intake context, rejects unsafe payloads, handles exact replay, uses `accounting_import_run.stage`, emits audit outcomes, and has in-memory/PostgreSQL coverage.
2A. Profile and parser foundation	Complete	Define the versioned standard accounting-export profile and convert synthetic CSV inputs into deterministic normalized transaction groups.	The v1 profile parses strict UTF-8 and CSV structure, groups by `ID`, preserves decoded rows and raw fields, validates fixed-culture dates and decimals, checks line/group balance and redundant fields, and emits visible issues without routing or persistence effects.
2B. Representative export qualification	Complete	Qualify the parser against a reviewed, non-sensitive operational export.	The header-qualified synthetic fixture verifies 138 rows, 68 balanced groups, totals of 49,075.27 per side, duplicate/conflict evidence, reversal-like raw markers, and the probable date anomaly without assigning workflow meaning. The native export is headerless and lacks durable event/change identity, so the limitations are recorded for `bp3-doli`.
3. Workflow classification and filtering	Complete	Route mixed operational data visibly and safely.	Explicit source-type or reviewed-profile decisions produce Income, Expense, Inventory, Opening Balance, Correction/Reversal, or Unclassified outcomes. Missing, duplicate, and unknown decisions remain visible errors; selection occurs after classification and retains every unselected candidate.
4. Identity, replay, and conflict handling	Complete	Make transaction-level repeated imports deliberate.	Candidate-level identity uses explicit source object/event, idempotency, and change metadata; deterministic meaning hashes distinguish exact replay, conflict, and duplicate-meaning review within company/source scope. Corrections and reversals require resolved original relationships and remain held.
5. Income templates and role readiness	Complete	Prepare explainable Income journal candidates.	The five accepted Income facts prepare immutable-account preview lines from their role templates only after active-source, original-identity, explicit funding, amount, tax, normalized-line, external-total, and relevant role readiness checks pass.
6. Evidence and reconciliation	Complete	Explain how source totals support prepared accounting.	Import, external-event, and active Source Document context is preserved; normalized-line, candidate, and prepared totals, currencies, and exact differences remain visible without persistence, posting, or report effects.
7A. Protected Summary intake alignment	Complete	Enforce the canonical protected-action boundary before Income creates Summary Accounting review records.	Ordinary staging authorization is canonical; `summary_accounting_batch.stage` is registered and enforced before replay or mutation, with success, denial, and failure audit coverage.
7B. Income review and posting orchestration	Complete	Integrate Income review with the Summary Transaction Desk.	Distinct source-activity dates and accepted Income preparation flow into protected Summary intake; the existing desk supplies review, readiness, protected approval, central posting, audit, and result links.
8. PostgreSQL persistence and recovery	Complete	Make accepted Income work durable and company-scoped.	Accepted candidate identity links its import run to the durable Summary batch id under company-scoped database constraints; recovery, uniqueness, rollback, restart reload, durable links, and isolation are verified.
9. External-adapter handoff	Complete	Decide whether the standard export remains sufficient.	The standard export remains a manual reviewed fallback; automated Income delivery requires a later custom operational extract/adapter and a shared versioned wire/API contract.
10. Clearing and canonical-route alignment	Complete	Bring the completed Step 7 baseline into conformance with accepted clearing and workflow-taxonomy truth.	Canonical route values now preserve legacy identity tokens; starter chart v2 adds repeatable receipts-for-deposit clearing; all three Sales-owned receipt facts require an explicitly selected eligible clearing account.

Slice 10 completion record: bp3 commits dd8e709 and 9d5840e expose the seven canonical workflow-route values while retaining the three renamed legacy identity tokens used by accepted candidate meaning hashes. Starter chart v2 adds 10200 Cash for Deposit with repeatable clearing.receipts_for_deposit; reinstalling it adds the missing standard account and role idempotently. Applied receipts, customer deposits, and unapplied receipts now debit only an explicitly selected eligible clearing account; bank, cash, missing, inactive, retired, non-posting, wrong-company, wrong-role, and Banking-route inputs remain held. Focused route/identity and receipt/setup suites pass, the full non-PostgreSQL solution passes with 739 tests and 65 expected skips, and all 804 tests pass against the isolated booksplus_slice10_test database. The development booksplus database was not reset or used for test cleanup. No schema, historical posting, Step 10 settlement, or adapter behavior changed. Step 8 Slice 1 followed.

Slice 1 completion record: the accepted import boundary stores one immutable raw payload per run, computes replay identity from company, source system, profile, payload, and currency context, returns exact replay without duplicate storage, lists headers without loading payload bytes, and creates no parsed candidate, Source Document, Summary Accounting batch, preview, journal entry, or ledger effect. Focused domain, security, app, schema, and opt-in PostgreSQL verification accompanied the implementation.

Slice 2A completion record: AccountingJournalCsvProfile version 1 consumes a matching immutable import-run payload and creates in-memory review candidates only. It defines six required and five optional headers, supports quoted CSV, strict UTF-8, fixed invariant date and decimal formats, source-row preservation, deterministic ID grouping, debit/credit validation, group balance checks, and redundant Signed AMT and Source Acct consistency checks. Seven focused tests and the full non-PostgreSQL solution suite passed. No schema, bp3a, workflow routing, Source Document, Summary Accounting, preview, posting, or ledger state changed. Slice 2B subsequently qualified the profile against the reviewed representative export.

Slice 2B completion record: the reviewed synthetic export contains 138 native headerless rows in ten stable positions. The versioned test artifact prepends ID, POST DATE, SOURCE, DESCRIPTION, ACCT NO, SUBACCOUNT, DEBIT, CREDIT, Signed AMT, and JOURNAL without changing the source rows. Profile v1 parses it into 68 balanced candidates with debits and credits of 49,075.27 each. Qualification also preserves nine exact raw group pairs that differ only by ID, fourteen source references reused across three groups with conflicting raw meaning, thirteen groups whose descriptions contain the RVRSINV marker, and the electbill-20251231 source reference paired with posting date 2025-01-30. These are review evidence, not automatic identity, change-type, or workflow rules. The original headerless file hash is 05b8bb0b6a9a707a718b90086bedf85f8a86e8538e4e7764d9e9919de1ce1665; the header-qualified fixture hash is 9a765e85a626beca7fb2062bb0a78d747e65f6d1fceeb69ef86fb9233995e378.

Slice 3 completion record: AccountingImportRoutingService assigns exactly one of the six accepted workflow outcomes to every parsed candidate using only an explicit source-type decision or a cited reviewed-profile mapping. It preserves decision basis and evidence, exposes counts and blocking issues, refuses to silently choose between duplicate decisions, reports decisions for groups not in the file, and holds correction/reversal outcomes for their owning workflow. Post-classification selection returns the complete, selected, and unselected sets so an Income filter cannot discard other work. The qualified fixture remains 68 unclassified candidates without supplied routing decisions because its account codes, journals, descriptions, and subaccounts are evidence rather than workflow authority. Twelve focused routing tests and the full non-PostgreSQL solution suite verify the boundary. No persistence, workflow child records, Source Documents, Summary Accounting batches, previews, posting, or ledger state changed. Slice 4 subsequently added candidate identity and replay evaluation.

Slice 4 completion record: the canonical Accounting Import Candidate Contract defines one identity evaluation per normalized transaction group, explicit original, correction, and reversal metadata, eight review outcomes, and the accounting-import-meaning-v1 hash boundary. AccountingImportIdentityService uses company/source-scoped source object, external object/event, and idempotency identity; links exact accepted replays; holds partial or changed identity reuse; and flags equal normalized meaning under different identity without merging it. Meaning hashes include route, posting date, verified currency, change relationship, totals, and sorted normalized external account lines while excluding file, row, descriptive provider, redundant, and transaction-identity fields. Corrections and reversals require a resolved accepted original and remain held for their owning workflow. The representative fixture confirms nine duplicate-meaning pairs but remains 68 held candidates because it provides neither authoritative routing nor durable identity metadata. Twenty-six focused tests and the full non-PostgreSQL solution suite verify the boundary. No persistence, workflow child records, Source Documents, Summary Accounting batches, previews, posting, or ledger state changed. Slice 5 subsequently added Income template preparation.

Slice 5 completion record: IncomeAccountingPreparationService supports the five accepted Income facts and builds the ADR 0021 receivable, revenue, sales-tax, bank/cash, customer-deposit, and unapplied-cash templates without using provider account codes to choose BooksPlus accounts. It requires an active same-company Source Document, an explicitly routed original candidate that is ready for workflow, matching posting date and source reference, one explicit currency, and matching normalized line, candidate, and fact totals. Only roles selected by the fact template are resolved. Repeatable bank and cash roles may carry an explicit reviewed account id, while every selected account must remain assigned, company-scoped, active, non-retired, and available for routine posting. Missing tax detail, uncertain receipt funding, amount or external-line differences, unavailable roles, non-Income routes, and correction/reversal identities produce visible issues and no preview. Nine focused tests and the full non-PostgreSQL solution suite verify the boundary. No batch persistence, workflow state, period transition, posting, audit, or ledger state changed. Slice 6 subsequently added evidence and reconciliation.

Slice 6 completion record: identified candidates now carry their import-run, company, source-system, and verified-currency provenance into workflow review. Income preparation returns distinct import identity and Source Document evidence, a reusable Source Document-backed evidence link, and exact normalized-line, candidate, and prepared-template debit and credit totals and differences. Currency, company, source-line, candidate, and template mismatches remain held with visible issues while preserving reconciliation detail; valid previews remain anchored to BooksPlus account ids selected only through Income role templates. Forty focused identity and Income tests and the full non-PostgreSQL solution suite (713 passed, 62 PostgreSQL tests skipped) verify the boundary. No batch mutation, UI orchestration, persistence, posting, audit, ledger, report, or adapter behavior changed. Slice 7A subsequently aligned the protected Summary intake boundary.

Slice 7A completion record: summary-batch staging now uses the registered summary_accounting_batch.stage protected action with ordinary authorization, no reason or step-up requirement, and append-only success, denial, and failure audit outcomes. Authorization occurs before source-identity lookup, so an unauthorized request cannot obtain an exact replay or reserve or persist a batch. Existing authorized create, replay, conflict, numbering, and app composition behavior remains intact. Forty focused tests, the full non-PostgreSQL solution suite (717 passed, 62 PostgreSQL tests skipped), and a strict wiki build verify the boundary. No Income orchestration, persistence, posting, ledger, report, or adapter behavior changed. Slice 7B followed.

Slice 7B completion record: IncomeAccountingWorkflowService accepts only same-company, explicitly routed original Income candidates that are ready for workflow, reuses accepted replay references, and leaves every other candidate in import review without creating a child batch. Income facts now preserve source-activity dates separately from posting and Source Document dates. Valid preparation, evidence, issues, and immutable-account previews flow through the protected Summary intake service; the existing Summary Transaction Desk then provides account-labelled review, readiness, Approve and Post, separate protected-action audits, central Accounting posting, and durable result links. Preparation errors remain visible and non-postable, while changed meaning under reused identity becomes a held conflict. Twenty-eight focused tests and the full non-PostgreSQL solution suite (724 passed, 62 PostgreSQL tests skipped) verify the slice. The opt-in PostgreSQL suite was not run because its harness truncates the configured database and this slice changes no persistence schema. No alternate posting, operational sales, report, adapter, or new persistence path was added. Slice 8 subsequently added durable persistence and recovery.

Slice 8 implementation record: accepted candidate identity now preserves the durable owning Summary batch id separately from its human-visible SA-… reference. A company-scoped PostgreSQL link joins the immutable import run and Summary batch, enforces source-event and idempotency uniqueness, and preserves change relationships and normalized meaning. Income orchestration writes the link only for created or exact-replay batches; conflicts remain unaccepted. If link persistence is interrupted after batch creation, retry reuses that batch and completes the missing link. The additive migration applies, strict wiki verification passes, and the full opt-in PostgreSQL solution suite passes (791 passed, zero failed, zero skipped), covering constraints, rollback, restart reload, durable links, and company isolation. Slice 9 subsequently recorded the external-adapter handoff.

Slice 9 completion record: the reviewed standard accounting export remains a useful immutable manual-intake payload and reconciliation artifact, but it is not sufficient for automated Income delivery. It lacks authoritative headers and profile context, verified currency, stable source object and event/version identity, explicit change relationships, distinct Source Document and activity dates, and the normalized Income fact classifications and amounts required by ADR 0021. A later bp3-doli custom operational extract or event adapter must capture those facts from authoritative Dolibarr objects, commit them to its durable outbox before delivery, and map them through a shared versioned provider-agnostic contract into the same BooksPlus review path. The current shipment/COGS connector and local line-oriented placeholder schema are Inventory-oriented development assets, not the Income contract or evidence of live BooksPlus intake readiness. Manual and file intake remain fallback paths; adapter expansion remains future-release work after the intervening workflow contracts are stable. Strict wiki verification and all 299 bp3-doli fast tests pass; no runtime connector, schema, migration, delivery, or BooksPlus behavior changed. Step 7 Slices 0 through 10 are complete. Step 8 Slices 1A, 1B, 2A, 2B, 2C, 3, 4, 5A, 5B, 5C, 5D, 6A, 6B1, 6B2, 6B3A, 6B3B, 7A, and 7B are complete; Slice 7C is the active implementation work.

Step 7 fixture acceptance

Keep the supplied CSV as non-sensitive versioned test data and cover:

138 lines grouped into 68 balanced candidates;
two three-line sales entries with receivable, revenue, and sales tax;
customer receipts applied to receivables;
opening-balance, supplier/AP, payment, expense, inventory, and unclassified records routed without loss or ordinary Income posting;
the probable electbill-20251231 date inconsistency as a visible issue;
nine duplicate-meaning pairs and conflicting source-identity reuse;
RVRSINV rows blocked pending explicit reversal meaning and relationship;
total debits and credits of 49,075.27 each; and
no canonical reliance on redundant Signed AMT or Source Acct values.

Step 7 boundaries and verification

Do not implement operational sales, invoicing, collections, payment, banking, customer-master, or perpetual-inventory behavior.
Do not derive reports from imports, normalized records, batches, or previews.
Do not infer accounting meaning from provider account ranges, journal codes, descriptions, or reversal-looking text.
Do not post Expense, Inventory, Opening Balance, Correction, or Reversal records through ordinary Sales and Receivables Summary preparation.
Do not add automatic provider integration before the reviewed file path and normalized contracts are proven.

Run focused tests for the active slice, then the full bp3 solution. Apply database migrations and run opt-in PostgreSQL tests whenever persistence changes. The current standard commands are documented in bp3/AGENTS.md and must be used from that repository rather than copied into new slice pages.

Qualification establishes that the standard export does not itself provide a header row, profile/version metadata, verified currency, stable source object and event/version identity, explicit change type, related-original identity, or distinct source-document/activity dates. For the manual prototype, the reviewed header-qualified file can be the accepted payload when the import session supplies a verified single currency. Before automated delivery, bp3-doli must use an authoritative custom operational extract or event adapter that supplies the missing facts through the shared versioned contract; it must not reconstruct them from journal descriptions, account ranges, or an already accepted raw payload. Provider strings remain evidence only and must not be used as identity or workflow heuristics.

8. Build Purchasing and Payables Summary

Goal: account for summarized product and service purchasing, payables, and contractor facts while purchase orders, receipts, vendor invoices, payable detail, and payment execution remain in the operational system.

Accepted ADR 0024 and the canonical Purchasing fact contract complete Slice 0A. The core ordinary purchase implementation may proceed while contractor/1099 truth is developed separately. Contractor classification, sensitive evidence, tax-support exclusions, and ledger-derived reporting do not block vendor invoice, operating-expense, inventory-acquisition, control- evidence, or vendor-payment facts. BillCatcher, capital projects, and the entire fixed-asset lifecycle are deferred beyond this release.

Slice	Outcome	Status and next gate
0A. Purchasing facts, workflow ownership, templates, and account roles	Define invoice-led acquisition, operating and inventory purchases, payables, payment modes, control evidence, allocations, prepayments, accruals, settlement-stage linkage, and one-posting ownership.	Complete. ADR 0024 is accepted and the fact contract is canonical.
0B. Contractor and 1099 truth	Define Form W-9 intake, contractor/vendor classification, protected TIN storage, versioned tax-year rules, posted-payment aggregation, Form 1099-NEC preparation, recipient statements, and IRS filing.	Complete. ADR 0025 accepts the bounded payee profile, keeps unresolved classification from suppressing ledger truth, and selects the IRIS Taxpayer Portal handoff.
1A. Starter-chart and account-role upgrade	Upgrade the current standard chart to canonical v3, including prepaid-expense, disbursement-clearing, and GRNI accounts and repeatable operating-expense assignments, while preserving existing account identity and reviewed configuration.	Complete in `bp3` commit `7f36dde`. The ordered v3 role migration, idempotent existing-assignment reconciliation, in-memory/PostgreSQL repository support, and existing-company setup coverage preserve account and assignment identity.
1B. Core invoice-led purchase facts and preparation	Implement vendor-invoice payable recognition, operating-expense and inventory-acquisition components, direct-purchase and vendor-payment settlement modes, required invoice allocations, control-evidence snapshots, role resolution, capital-classification holds, and prepared previews without persistence or posting orchestration.	Complete in `bp3` commit `712f35c`. Core payable, direct-purchase, and vendor-payment facts prepare immutable-account previews or visible held results without persistence, Summary batch, posting, audit, or ledger effects.
2A. Import provenance and reconciliation	Reuse accepted-candidate provenance, active Source Document evidence, normalized-line reconciliation, route isolation, operational control totals, and receipt/invoice control evidence for core Purchasing preparation.	Complete. The non-persistent preparation boundary now requires an identity-qualified, explicitly Purchasing-routed candidate and active same-company Source Document; preserves import, identity, routing, source-event, document, and control evidence; and exposes exact normalized-line, candidate, prepared-preview, fact, and reviewed-control differences. Mismatched or unreconciled evidence is held without persistence or ledger effects.
2B. PPV/GRNI ownership and relationship truth	Establish one balanced procure-to-pay sequence in which Inventory alone posts PPV, including the adjustment of a linked GRNI balance before Purchasing settles it to Accounts Payable.	Complete. ADR 0024 and the canonical Purchasing contract remove Purchasing-owned PPV; accepted ADRs 0028 and 0029 define calculation, favorable/unfavorable templates, GRNI adjustment and settlement ordering, relationship direction, allocations, currency, resolution, and history.
2C. Typed cross-workflow evidence relationships	Implement the accepted provider-agnostic event references and relationship vocabulary needed by Purchasing review and reconciliation without authorizing posting or changing event ownership.	Complete. The non-persistent domain boundary reuses accepted-candidate identity, preserves explicit source and target direction, and reviews same-company resolution, required-versus-supporting behavior, summarized amount and quantity, company currency, exact replay, conflicting identity, and append-only supersession. Correction and reversal types were reserved pending Step 11 and are now governed by the Accounting Correction Contract.
3. Review and posting orchestration	Reuse protected Summary intake, desk readiness, preview, audit, and central posting for accepted core Purchasing facts. Match, hold, OK-to-pay, and payment-proposal states remain non-posting evidence.	Complete. Core Purchasing preparation now stages through protected Summary intake, preserves review evidence and previews, links accepted candidate and event identity to the Summary batch, and reuses shared readiness, audit, central posting, and posting-result behavior.
4. PostgreSQL persistence and recovery	Persist Purchasing facts, payment allocations, control evidence, cross-workflow links, and candidate-to-batch ownership with company isolation, replay, restart, and interrupted-write recovery.	Complete. Versioned Purchasing and relationship snapshots preserve the accepted Slice 1 through 3 aggregate behind company-scoped relational identities and constraints. Workflow write ordering and exact replay recover an interruption between Summary batch, Purchasing fact, and accepted-candidate ownership.
5A. Operating-cost and GRNI accrual recognition	Implement explicit period-end operating-cost accruals to `liability.accrued_expenses` and uninvoiced-inventory accruals to `liability.goods_received_not_invoiced`.	Complete. Explicit `accrual_recognized` facts prepare reviewed operating expense or invoice-led uninvoiced inventory against the applicable singleton liability role, with exact import and control reconciliation, persistence, Summary orchestration, and visible holds.
5B. GRNI invoice settlement	Implement `GrniSettlementAllocation` and the required posted-accrual, Inventory-owned PPV, relationship-ordering, adjusted-carrying-amount, and no-duplicate-acquisition gates.	Complete. Posted GRNI, zero or posted Inventory PPV, resolved relationship, exact reconciliation, open-balance reservation, and GRNI-to-payable-only template gates are implemented and persisted.
5C. Non-inventory prepayment truth	Define prepayment acquisition and recognition allocations, open balance, relationship direction and type, ordering, and over-recognition behavior.	Complete. ADRs 0024 and 0029 and the canonical Purchasing contract now accept stable prepaid-component references, manual recognition allocations, `recognizes_prepayment`, and atomic available-balance controls.
5D. Non-inventory prepayment acquisition and recognition	Implement prepaid-expense acquisition and separately linked manual recognition without automatic amortization or duplicate recognition.	Complete. Stable prepaid components, explicit recognition allocations, resolved relationships, exact previews, durable reservations, and posting revalidation implement the accepted Slice 5C boundary.
6A. Non-sensitive contractor/vendor support facts	Implement the accepted source-referenced payee profile, worker classification, versioned tax-rule identity, masked-TIN readiness, and reviewed payment-treatment boundary without storing full TIN or W-9 contents.	Complete. Company-scoped immutable profiles and classifications, versioned rule identity, masked-only TIN validation, active Source Document checks, protected maintenance and value-free audit, explicit payment method/network review, and PostgreSQL restart/replay are implemented. Full-TIN absence remains an explicit filing-readiness exception without suppressing payable or posted-payment truth.
6B1. Sensitive-data, recovery, evidence, and backup truth	Accept the encryption envelope, customer recovery, managed sensitive-artifact, key rotation, and coordinated encrypted backup/restore contract.	Complete. ADR 0030 is accepted; the company-data encryption and backup contracts are canonical; Source Document and contractor contracts now govern protected payload and sensitive artifact behavior.
6B2. Protected TIN and W-9 persistence	Implement company-key envelopes, encrypted taxpayer-identifier payloads, protected W-9 artifacts, narrow maintenance/view actions, value-free audit, replay, integrity, and company-isolation behavior.	Complete. AES-256-GCM data-key envelopes, customer recovery wrapping, protected initialization/unlock and TIN/W-9 maintenance/view services, opaque artifact identity, PostgreSQL persistence, restart recovery, exact replay, generic integrity failures, step-up viewing, key clearing, and value-free audit are implemented. Normal runtime retention remains explicitly blocked until 6B3.
6B3A. Authenticated backup container and protected orchestration	Implement recovery-secret wrapping, exact component manifests, schema and integrity validation, protected create/export/validate/restore coordination, value-free audit, and proof that failed validation never reaches mutation.	Complete. The versioned AES-256-GCM container uses a fresh backup key wrapped from customer recovery material, authenticates company and schema context, requires PostgreSQL, managed-evidence, and company-key components, verifies exact identities, lengths, and SHA-256 digests, and exposes replacement only after complete validation. Protected create, export, validate, and restore coordination emits value-free audit evidence.
6B3B. Company-scoped PostgreSQL capture and atomic replacement	Implement the accepted shared-schema ownership catalog and one consistent company snapshot containing database records, managed evidence, and the company key envelope; validate in isolation and replace only the target company atomically.	Complete. Exact `company-snapshot-v1` schema/catalog qualification, repeatable-read capture, shared-definition closure and reconciliation, separated protected-evidence and company-key components, authenticated restore context, exclusive maintenance, staged validation, atomic target-company replacement, append-only audit merge, reviewed assignment activation, and production PostgreSQL composition are implemented and verified.
7A. Information-return payer profile and protected payer TIN	Persist one reviewed, source-evidenced company payer profile and its separately protected full TIN, with effective selection, authorization, audit, recovery, and ordinary-read isolation.	Complete. Reviewed effective profiles, distinct payer identity/actions, envelope-protected TIN access, value-free audit, replay and company isolation, PostgreSQL persistence, and exact backup/recovery are implemented and verified.
7B. Posted-payment support runs and reconciliation	Aggregate posted contractor-payment truth into versioned, explainable support runs and lines that reconcile to ledger and linked Purchasing facts.	Complete. Protected generation now covers every posted original in-year vendor payment exactly once, applies explicit reviewed treatment and the selected versioned threshold, persists immutable support lines, and reconciles ledger, Purchasing, candidate, disposition, exclusion, and exception totals.
7C. Form 1099-NEC draft preparation and readiness	Prepare masked ordinary-review drafts from a selected completed support run, exact rule version, reviewed payer/payee profiles, and protected filing readiness.	Complete. Stable-payee aggregation, effective reviewed profile selection, exact support-line reconciliation, masked ordinary snapshots, protected-TIN references, visible readiness holds, replay, PostgreSQL persistence, and backup recovery are implemented and verified.
7D. Filing approval, IRIS Taxpayer Portal handoff, and filing results	Protect approval and submission, preserve one provider-agnostic filing identity and exact payload evidence, and record portal acknowledgments without changing ledger truth.	Complete. Protected approval assembles one encrypted versioned keyed-entry handoff, export remains distinct from portal-submission confirmation, and normalized results retain protected acknowledgment evidence without ledger effects.
7E. Recipient statements and correction orchestration	Produce reconciled masked recipient statements, preserve delivery evidence, and orchestrate corrections as linked filings rather than replacement originals.	Complete. Each approved original or correction filing has one protected, exactly reconciled recipient-statement identity with masked ordinary review, separately evidenced delivery, and append-only correction-chain ownership.
8. External-adapter handoff	Freeze the provider-agnostic REST fact and evidence contract needed by Dolibarr and the provider-agnostic information-return submission contract needed by the selected IRS transport.	Deferred beyond the initial release. Provider-specific implementation is not part of Step 14 QBO conversion or Step 15 release readiness.

Slice 2B completion record: ADR 0028 accepts company-wide versioned standard cost, company-local half-open period cutoffs, prospective cost revisions, controlled late movements, and Inventory-owned PPV. ADR 0029 accepts provider-agnostic event references and typed, same-company, append-oriented relationships. ADR 0024 and the Purchasing contract now require Inventory to adjust linked GRNI for nonzero PPV before Purchasing settles the adjusted balance to Accounts Payable. Favorable, unfavorable, zero, partial, single-currency, unresolved-link, and correction-deferral behavior is explicit. This truth-only slice changed no application, persistence, adapter, UI, audit, posting, or ledger implementation.

Slice 2C completion record: bp3 now provides a non-persistent AccountingEvents domain boundary for the accepted event reference and all versioned relationship types in ADR 0029. Review enforces complete same-company identity, explicit Inventory-support direction, target resolution, required-versus-supporting blocking, exact summarized amount and quantity, company currency, exact replay, conflicting relationship identity, duplicate active meaning, and append-only supersession. The accepted GRNI/PPV support-adjust-settle directions are representable without changing event ownership or authorizing posting. Thirty focused relationship tests, 144 focused and adjacent domain tests, and the full solution suite (809 passed, 66 PostgreSQL-gated skipped) verify the slice. No persistence changed, so PostgreSQL execution was unnecessary. Summary orchestration, relationship persistence, GRNI and PPV templates, corrections, reversals, UI, audit mutation, adapters, posting, and ledger effects remain excluded.

Slice 3 completion record: the PurchasingAndPayablesWorkflowService stages the three supported core Purchasing facts through protected Summary Accounting intake after identity-qualified preparation. It preserves source-activity dates, validation issues, Source Document and control-evidence links, prepared previews, target period, import replay/conflict behavior, and the accepted candidate-to-batch identity. Results expose the accepted provider-agnostic event reference needed by later cross-workflow review, and the application composition root exposes the Purchasing preparation and workflow services. Preparation errors remain visible in staged review without a posting preview. Match, hold, OK-to-pay, and payment-proposal evidence does not block an otherwise valid payable. Existing Summary readiness, audit, desk, central posting, and posting-result services remain the only orchestration and ledger path. Eight focused workflow tests, 130 focused and adjacent domain tests, and the full solution suite (817 passed, 66 PostgreSQL-gated skipped) verify the slice. No schema or persistence implementation changed, so PostgreSQL execution was unnecessary. Purchasing persistence and recovery, GRNI/PPV templates, prepayments, accruals, corrections, UI changes, adapters, and new ledger behavior remain excluded.

Slice 4 completion record: bp3 now persists the complete accepted core Purchasing aggregate, including fact and source identity, imported external lines, allocations, control and Source Document evidence, reconciliation, account-role readiness, preparation status, and accepted Summary-batch ownership. Versioned PostgreSQL snapshots sit behind company-scoped Summary batch, Source Document, import-run, source-event, and idempotency constraints. Typed accounting-event relationships persist accepted source ownership, unresolved or accepted target identity, type and version, evidence, resolution attribution, summarized amount or quantity, and supersession. Database constraints preserve company isolation, resolution-state coherence, and one active summarized relationship meaning. The workflow writes the Summary batch, idempotent Purchasing snapshot, and accepted-candidate link in recoverable order; retry after an interrupted Purchasing write returns the existing batch and completes ownership without duplication. In-memory recovery and relationship tests, schema tests, and a PostgreSQL restart and exact-replay test cover the new boundary. The full solution suite passed with PostgreSQL enabled against an isolated test database (890 passed, zero failed, zero skipped). GRNI and PPV templates, prepayments, accruals, corrections, reversals, provider behavior, UI changes, and new posting or ledger effects remain excluded. No unresolved truth gate remains for Slice 4.

Slice 5A completion record: the canonical Purchasing contract now accepts accrual_recognized as the stable stage for purchasing_accrual_summary. PurchasingPreparationService prepares a reviewed operating-cost accrual as debit expense.operating, credit liability.accrued_expenses, and an invoice-led uninvoiced-inventory accrual as debit inventory.general, credit liability.goods_received_not_invoiced. One accrual cannot mix operating and inventory classification. Wrong stages, missing or ineligible selected roles, nonpositive or unreconciled components, non-invoice-led inventory accruals, settlement or payment fields, unsupported currency, and invalid import or Source Document provenance remain visibly held. The existing protected Summary workflow, accepted-event identity, versioned Purchasing snapshot, and central posting path are reused without a new posting authority. Focused Purchasing tests and a PostgreSQL accrual-stage restart and exact-replay test verify the boundary; the full PostgreSQL-enabled solution suite passed (898 passed, zero failed, zero skipped). No migration was required because Slice 4 had already reserved the accepted accrual fact and stage values. GRNI invoice settlement, Inventory-owned PPV implementation, operating-accrual settlement, prepayment acquisition or recognition, corrections, reversals, provider behavior, and UI changes remain excluded.

Slice 5B completion record: GrniSettlementAllocation preserves the posted GRNI share, invoice inventory-acquisition amount, adjusted carrying amount, company currency, optional accepted Inventory PPV event, typed relationship identities, and reconciliation evidence. Preparation resolves the durable posted uninvoiced-inventory accrual, validates favorable, unfavorable, or zero PPV and its required posted ordering and resolved support/adjustment chain, rejects components that would duplicate acquisition or PPV, and prepares only debit liability.goods_received_not_invoiced and credit payable.trade. Sequential and concurrent allocations cannot exceed the original accrual: ready allocations reserve their share in a company-scoped relational table, and PostgreSQL serializes competing reservations on the accrual record. Held facts remain visible without reserving GRNI. The workflow creates the resolved settles_accrual relationship only after its accepted invoice identity exists and exact replay neither duplicates nor changes it. Focused Purchasing tests passed (62 passed; four PostgreSQL-gated skipped), and the full solution passed against a migrated isolated PostgreSQL database (906 passed, zero failed, zero skipped). Inventory PPV calculation or posting, operating-accrual settlement, corrections, reversals, UI, and adapter behavior remain excluded. No unresolved Slice 5B truth gate remains.

Slice 5C completion record: accepted truth now distinguishes a posted non-inventory prepayment acquisition from its later original purchasing_prepayment_recognition_summary at prepayment_recognized. Prepaid-expense acquisition components carry stable within-event references; recognition allocations identify the posted acquisition component, original amount, reviewed operating-expense destination, recognized company-currency amount, and reconciliation evidence. recognizes_prepayment points from the later recognition event to the acquisition, with amounts reconciled by endpoint. Posted recognition consumes open balance, ready_to_post allocations reserve available balance atomically, and staged, held, or abandoned batches do not. Partial and many-to-many recognition is accepted, but overlapping or excessive allocations remain blocked. Recognition stays manual: schedules, inferred service periods, automatic amortization, recurring entries, returns, refunds, corrections, reversals, and cross-classification remain excluded or deferred. This truth-only slice changes no application, persistence, adapter, UI, audit, posting, or ledger implementation. No unresolved Slice 5C truth gate remains.

Slice 5D completion record: payable and direct-purchase facts can now acquire reviewed non-inventory prepayments through stable prepaid-component references. A later original purchasing_prepayment_recognition_summary preserves explicit component and expense-destination allocations, validates its posted same-company acquisition and exact company-currency reconciliation, creates the resolved recognizes_prepayment relationship, and prepares only debit expense.operating and credit asset.prepaid_expenses. In-memory and PostgreSQL persistence retain the allocation and relationship evidence. Protected Summary readiness atomically reserves available component balance; competing ready batches cannot over-recognize it, and posting revalidates the posted acquisition, resolved relationship, and reservation. Staged and held batches do not reserve balance. Focused Purchasing, relationship, schema, restart, exact-replay, and concurrency tests verify the boundary, and the full solution suite passes. Recognition remains manual; amortization schedules, inferred service periods, generated recurring entries, refunds, corrections, reversals, cross-classification, UI, and provider-specific behavior remain excluded. No unresolved Slice 5D truth gate remains.

Slice 6A completion record: bp3 now preserves a company-scoped, source-system-qualified PayeeTaxProfile without introducing a general Party or operational vendor master. Party role, worker relationship, supplier category, and information-return treatment remain separate. Effective-dated worker classification requires reviewed conclusions and active same-company Source Document references. Versioned information-return rule identity preserves jurisdiction, tax year, form, category, threshold operator, authoritative source, and review attribution rather than hard-coding a universal threshold. Payment treatment requires posted Purchasing-fact and journal-entry references plus explicit payment method and network evidence; ACH cannot establish a settlement-entity exclusion. Protected profile maintenance emits audit evidence without taxpayer values. In-memory and PostgreSQL repositories preserve exact replay, company isolation, successor references, and restart recovery through versioned snapshots. Eleven focused domain and schema tests and one PostgreSQL restart/replay test cover the boundary; the full PostgreSQL-enabled solution suite passed (928 passed, zero failed, zero skipped). The model has no full-TIN or W-9-content field, rejects unmasked TIN display, and always reports protected_full_tin_storage_unavailable as a filing-readiness exception. Payable recognition and externally issued payment accounting remain independent of contractor readiness. Full-TIN maintenance/view/export, sensitive W-9 artifact storage, payer profiles, protected backups and recovery keys, support aggregation, draft returns, recipient statements, IRIS handoff, UI, and provider adapters remain excluded behind Slice 6B. The unresolved truth gate is the accepted and verified sensitive-field, evidence-storage, backup, and recovery-key design.

Slice 6B1 completion record: accepted ADR 0030 resolves the launch sensitive-data gate with per-payload AES-256-GCM data keys, company key envelopes, customer-held recovery material, authenticated company/object context, opaque managed evidence, key-versioned rotation behavior, and a coordinated authenticated backup container. The company-data encryption and backup contracts are now canonical. Source Document and contractor contracts assign sensitive W-9 identity, encrypted artifact metadata, full-TIN payload identity, narrow authorization, value-free audit, replay, integrity, and company isolation without moving evidence ownership into Purchasing.

Slice 6B2 completion record: bp3 implements random company keys wrapped from a 256-bit customer recovery secret using the accepted PBKDF2-HMAC-SHA-256 parameters. Each full TIN or W-9 artifact uses a fresh AES-256-GCM data key, payload nonce, data-key wrapping nonce, authenticated company/object/purpose context, keyed replay digest, key and envelope version, and generic integrity failure. Ordinary payee snapshots retain only masked TIN state. Protected initialization and unlock, TIN/W-9 maintenance, full-value view, and artifact view emit value-free audit events; full-value reads require reason and step-up confirmation. Sensitive values are returned through disposable clearing wrappers, company keys clear on lock and application shutdown, W-9 storage identities are generated and opaque, and exact replay cannot change plaintext or artifact meaning. Company-scoped PostgreSQL constraints preserve key, payload, profile, and Source Document ownership. Focused encryption, recovery, authorization, audit, TIN, W-9, schema, replay, tamper, locked-state, and runtime-gate tests plus PostgreSQL restart recovery verify the boundary. The full PostgreSQL-enabled solution suite passed (940 passed, zero failed, zero skipped). Normal application composition uses BlockProtectedDataRetentionGate, so ADR 0027 continues to block production full-TIN and W-9 retention until Slice 6B3B verifies company-scoped PostgreSQL capture and atomic replacement. Key rotation execution, operating-system credential-store caching, the production PostgreSQL snapshot/replacement provider, payer profiles, filing orchestration, UI, sensitive exports, and provider adapters remain excluded.

Slice 6B3A completion record: bp3 implements a versioned authenticated encrypted backup container and provider-independent protected orchestration. The container binds company, backup, format, timestamp, and application-schema identity; wraps a fresh backup key from the customer recovery secret; and verifies the exact PostgreSQL, managed-evidence, and company-key component manifest before returning clearing snapshot buffers. Create, export, validate, and restore actions emit value-free audit evidence, and restore cannot call the replacement provider after authorization, company, schema, recovery-key, container, manifest, component-length, or digest failure. Nine focused tests, seventy-eight adjacent security and protected-contractor tests, and the full non-PostgreSQL solution suite passed (875 passed, 74 PostgreSQL tests skipped). Accepted ADR 0031 and the canonical company-snapshot-v1 catalog resolve shared-schema ownership, shared-definition reconciliation, stable identity, quiescing, append-only audit merge, evidence projection, schema compatibility, and atomic company replacement. No production PostgreSQL snapshot provider is composed, and BlockProtectedDataRetentionGate remains in force until Slice 6B3B is implemented and verified.

Slice 6B3B completion record: bp3 implements the accepted company-snapshot-v1 provider for the exact current PostgreSQL schema and migration catalog. Capture uses a repeatable-read company lock and projects direct, child-owned, immutable shared, protected W-9 evidence, and company-key records into one coordinated authenticated snapshot. Restore verifies the container recovery secret and company key envelope, rejects cross-company or incomplete shared-reference content before mutation, reconciles compatible shared definitions, preserves current actor-role assignments unless a separately authorized review changes them, and uses exclusive maintenance, staged application, atomic replacement, and append-only audit merge. PostgreSQL application composition now exposes protected backup orchestration and enables protected TIN/W-9 retention only after the live schema and migration catalog pass exact capability verification; in-memory composition remains blocked. Focused container, authorization, composition, protected-data, and isolated PostgreSQL capture/restore tests pass. The full PostgreSQL-enabled solution suite passed against the dedicated booksplus_slice_6b3b_test database (951 passed, zero failed, zero skipped). Key rotation execution, operating-system credential-store caching, payer profiles, filing orchestration, UI, sensitive exports, and provider adapters remain excluded.

Slice 7A completion record: bp3 persists reviewed, source-evidenced information-return payer profiles with explicit effective dating and supersession, visible missing or ambiguous selection, and ordinary reads that contain only the masked TIN. Distinct protected payer-profile actions retain and reveal the full TIN through the accepted company envelope, reason, step-up, company, ownership, replay, recovery, and value-free audit controls. In-memory and PostgreSQL repositories, production composition, and company-snapshot-v2 capture and atomic restore preserve payer profiles and protected TIN links without weakening the exact runtime schema/catalog gate. Focused Slice 7A tests and the full PostgreSQL-enabled solution suite passed against the dedicated booksplus_slice_7a_test database (962 passed, zero failed, zero skipped). Posted-payment aggregation, support runs, tax thresholds, draft forms, filing, statements, corrections, adapters, UI, and ledger mutation remain excluded.

Slice 7B completion record: bp3 generates a protected, immutable InformationReturnSupportRun only after every successfully posted original vendor-payment fact in the company, tax year, and as-of boundary maps exactly once to reviewed payee, treatment, method, network, and rule evidence. Support lines preserve Purchasing, Summary batch, journal entry, effective profile and classification, allocation, masked identity, rule citation, and included, excluded, or exception disposition. Ledger, Purchasing-fact, candidate, line, and disposition totals reconcile exactly; thresholds use the selected rule-set value and operator rather than a code constant. Exact replay, conflict, distinct rerun, authorization, value-free audit, in-memory and PostgreSQL persistence, and company-snapshot-v3 shared-rule and company restore behavior are implemented. The full PostgreSQL-enabled solution suite passed against booksplus_slice_7b_test (974 passed, zero failed, zero skipped). Draft forms, support-run approval meaning, filing, recipient statements, corrections, adapters, UI, and ledger mutation remain excluded.

Slice 7C completion record: bp3 prepares one company-scoped Form 1099-NEC draft for a stable source payee from a selected completed support run and its exact rule version. payee_tax_year thresholds aggregate across effective profile versions; filing-date selection supplies one reviewed payer and payee profile. Ordinary drafts persist only masked identifiers and protected-payload references, reconcile their amount to every included support line, and retain visible classification, profile, W-9, TIN, support-exception, and currency readiness issues without approving or filing a return. Protected preparation, value-free audit, replay/conflict behavior, in-memory and PostgreSQL persistence, and company-snapshot-v4 existing- and absent-company recovery are implemented. The full PostgreSQL-enabled solution suite passed against booksplus_slice_7c_test (983 passed, zero failed, zero skipped). Filing approval, untruncated filing-data assembly, IRIS payloads and acknowledgments, recipient statements, corrections, adapters, UI, and ledger mutation remain excluded.

Slice 7D completion record: bp3 protects one original filing identity per ready draft and revalidates exact payer/payee protected-TIN ownership before assembling the irs_iris_taxpayer_portal_keyed version 1 handoff. Ordinary filing reads retain only transport identity, payload SHA-256, protected references, actors, times, and normalized state. Reason-and-step-up approval and handoff export remain distinct from user confirmation of portal submission; accepted, accepted-with-errors, rejected, and correction-required results retain raw acknowledgment or error evidence only in the company envelope. Replay, conflict, ordering, company isolation, locked-key and integrity behavior, value-free audit, in-memory and PostgreSQL persistence, and company-snapshot-v5 existing- and absent-company recovery are implemented. The full PostgreSQL-enabled solution suite passed against booksplus_slice_7d_test (989 passed, zero failed, zero skipped). IRS CSV template generation, direct A2A, recipient statements, corrections, UI, provider adapters, and ledger mutation remain excluded.

Slice 7E completion record: accepted contractor truth now fixes append-only correction chains, eligible predecessor states, reviewed Source Document evidence, exact changed-meaning identity, and separately protected recipient statements and delivery outcomes. bp3 implements protected linked correction approval and the existing handoff/result lifecycle; ordinary statement reads retain masked recipient identity while protected export supplies the untruncated payer TIN and exact approved-filing reconciliation. Delivered correction statements supersede but never delete prior statements. In-memory and PostgreSQL repositories, production composition, migration 202607290011, and company-snapshot-v6 existing- and absent-company recovery are implemented. The full PostgreSQL-enabled solution suite passed against booksplus_slice_7e_test (997 passed, zero failed, zero skipped). PDF or IRS form rendering, delivery transport, direct IRIS A2A, UI, provider adapters, and ledger mutation remain excluded.

Slice 1A completion record: starter chart v3 adds the accepted prepaid-expense, payment-disbursements-clearing, and GRNI accounts and upgrades expense.operating assignments to repeatable without replacing durable account or assignment identity. Starter-chart reinstall reconciles existing role cardinality idempotently, and focused chart, migration, setup, app, and PostgreSQL repository coverage verifies the upgrade.

Slice 1B completion record: the dedicated Purchasing and Payables domain boundary models the three core fact and source-event-stage combinations, reviewed components, capital classification, settlement modes, allocations, and control evidence. It resolves only template-selected immutable account ids and produces balanced prepared previews or visible held results. Twenty-three focused Purchasing tests and the full opt-in solution suite (830 passed, zero failed, zero skipped) verify the combined Slice 1A/1B baseline. Prepayments, accruals, GRNI and PPV posting, import reconciliation, persistence, Summary orchestration, corrections, UI, and adapter behavior remain excluded.

Slice 2A completion record: core Purchasing preparation now accepts the existing AccountingImportIdentifiedCandidate only when company, source system, verified currency, explicit Purchasing route, ready identity, original change type, source group, posting date, source reference, source-event identity, and active same-company Source Document agree. Its result preserves import-run, routing, identity, Source Document, supporting-control, match, hold, approval, payment-proposal, and allocation evidence while using only the reviewed Purchasing fact and account-role templates to prepare lines. Exact normalized-line, candidate, prepared-preview, fact, and operational-control totals and differences are visible; any mismatch holds the preview. Thirty- eight focused Purchasing tests, 101 adjacent Income/import/Source Document/account-resolution tests, and the full solution suite (779 passed, 66 PostgreSQL-gated skipped) verify the slice. No persistence changed, so PostgreSQL execution was unnecessary. Typed cross-workflow relationships, PPV/GRNI posting, Summary orchestration, persistence, corrections, reversals, UI, audit mutation, provider adapters, posting, and ledger effects remain excluded.

Slice 0A accepts invoice-led acquisition as the initial ordinary policy. Purchase orders, receipts, matching, holds, OK-to-pay approval, payment proposals, and direct-payment bank matches are non-posting control evidence. A valid payable does not wait for payment approval. Vendor payment issuance may credit the selected bank directly or use disbursement clearing according to policy; the same payment may not use both. It does not define W-9 or taxpayer- identification meaning, 1099 thresholds or forms, BillCatcher, capital projects, fixed assets, depreciation, payroll, or payment execution.

Slice 0B is accepted. Step 8 uses a source-referenced payee tax profile rather than a general Party master. Unresolved worker classification remains a visible compliance exception and blocks contractor and information-return readiness, but it does not block valid payable recognition or recording an externally issued payment. Launch filing uses a reviewed IRIS Taxpayer Portal handoff; direct A2A remains deferred. Secure full-TIN storage and Form 1099-NEC filing remain initial-release requirements. Thresholds, comparison operators, deadlines, form revisions, and exceptions are versioned tax-year rules rather than hard-coded product constants.

Build:

Purchasing and Payables Summary workflow wrapper;
product and service purchase components classified to operating expense, inventory acquisition, or non-inventory prepayment;
invoice, purchase-order, receipt, matching, hold, approval, payment, and allocation references sufficient to reconcile summarized postings to operational control totals;
payable, direct-purchase, direct-bank or clearing vendor-payment, prepayment-recognition, and accrual templates only as accepted truth permits;
cross-workflow source-event links that cannot trigger duplicate posting;
purchase template account-role requirements and readiness messages;
contractor/vendor classification, W-9/1099 facts, and support reporting under separately accepted truth;
provider-agnostic REST intake handoff; and
posting through Accounting.

Exit criteria:

a fiscal period can receive Purchasing and Payables summaries and post balanced entries for accepted product and service purchase classifications;
Purchasing, Inventory, and Finance events remain linked and reconcile without posting one source accounting event twice;
ordinary inventory acquisitions are invoice-led; receipt evidence does not create a second acquisition posting;
one vendor payment can allocate to several invoices and allocations reconcile to the payment total;
direct-bank payments and disbursement-clearing payments use mutually exclusive templates, and a later direct-bank statement match is non-posting;
match, hold, OK-to-pay, and payment-proposal status can be reviewed without controlling payable recognition or creating a journal entry;
contractor payment support reports are traceable to posted accounting and source facts;
direct purchases preserve evidence and do not duplicate a Finance posting;
identified or potentially capitalizable purchases remain held;
the observed INV purchase-price variance is not accepted as ordinary acquisition until its relationship to the related AC invoice is explained and reconciled;
a BQ journal code does not by itself move an externally issued vendor-payment event from Purchasing to Finance or authorize a duplicate settlement posting;
required purchasing, payable, asset, expense, and clearing roles are visible before preparing or posting affected previews; and
operational purchasing, BillCatcher, payment execution, payroll calculation, capital projects, the fixed-asset lifecycle, depreciation, and payroll payment execution remain outside the initial release.

9. Build Inventory Summary

Goal: account for summarized inventory ins, outs, ending value, and cost while item, stock-movement, warehouse, production, and perpetual valuation detail remain in the operational system.

Accepted ADR 0028 governs the initial standard-cost direction. It keeps product standard-cost maintenance, movement extension, close-period snapshots, and PPV calculation in the operational system while BooksPlus validates, reconciles, reviews, and posts accepted period summaries.

Slice	Outcome	Status and next gate
0A. Inventory period-summary contract	Translate accepted ADR 0028 into one canonical provider-agnostic fact, preparation, reconciliation, account-role, cutoff, evidence, relationship, and held-result contract.	Complete. The canonical Inventory contract fixes aggregate manifest-backed facts, identity and route gates, exact operational and ledger reconciliation, ordinary templates, predecessor continuity, relationship handling, and held behavior.
1. Standard-cost period summary preparation	Validate one non-persistent company-period summary, beginning and ending snapshots, valued movements, cutoff interval, standard-cost versions, currency, and exact reconciliation.	Complete. The `InventoryAccounting` domain prepares only original, explicitly routed, identity-qualified period facts; preserves manifest, Source Document, import-run, operational-run, and relationship-proposal evidence; resolves canonical roles; and requires exact source-line, candidate, operational-control, rollforward, initial-boundary, and ledger-control reconciliation before returning a preview.
2A. Standard-cost revision adjustments	Prepare distinct prospective on-hand revaluation events without rewriting finalized history.	Complete. The non-persistent Inventory boundary validates original, explicitly routed `inventory_standard_cost_revision_adjustment` facts; preserves effective-boundary, reviewed actor/reason, on-hand manifest, prior/new cost-version, import, and Source Document evidence; prepares the accepted positive or negative role template; and preserves an exactly reconciled zero result without journal lines.
2B. Inventory-owned PPV and GRNI adjustment	Prepare favorable, unfavorable, and zero PPV results with accepted Purchasing evidence, allocations, relationship ordering, and exact GRNI reconciliation.	Complete. The non-persistent Inventory PPV boundary validates accepted Purchasing acquisition evidence, exact allocation calculations, optional posted-GRNI adjustment, relationship proposals, ordering, canonical roles, and source/candidate/control reconciliation; zero variance remains reconciliation-only.
3. Summary review and posting orchestration	Reuse protected Summary intake, preview, readiness, central posting, audit, and result-link behavior for accepted Inventory facts.	Complete. All three Inventory preparation boundaries stage through protected Summary intake, accepted-candidate ownership, shared review and posting. Required relationships resolve before accepted linkage and are revalidated at readiness and posting; zero PPV remains reconciliation-only without a false event or batch.
4. PostgreSQL persistence and recovery	Persist Inventory facts, snapshots, allocations, preparation and reconciliation evidence, replay, supersession, relationship recovery, and company backup behavior.	Complete. Versioned Inventory aggregates, queryable valuation snapshots and PPV allocations, reconciliation-only zero PPV, exact replay/conflict handling, lifecycle relationship recovery, PostgreSQL composition, and company backup replacement are implemented.

Slice 0A completion record: accepted ADR 0028 and the canonical Inventory contract now define three distinct Inventory-owned fact types while limiting the next implementation to aggregate, manifest-backed inventory_period_summary preparation. The contract fixes explicit Inventory-route and original-identity gates, company-period cutoff and initial boundary rules, predecessor snapshot continuity, standard-cost rollforward, source/candidate/operational/ledger reconciliation, immutable role-selected COGS and adjustment templates, cross-workflow proposal and resolution timing, and visible holds. It preserves product and movement detail in operational evidence, prohibits duplicate Purchasing acquisition, fallback-clearing, and provider-selected meaning, and leaves cost revision, PPV/GRNI, orchestration, persistence, correction, foreign-currency, production, UI, and adapter work to later slices. bp3 already supplies import identity, Inventory routing, relationship vocabulary, account resolution, Source Documents, period control, ledger reporting, and Summary patterns but contains no Inventory preparation domain yet. This truth-only slice changed no application, persistence, migration, adapter, audit, posting, or ledger behavior.

Slice 1 completion record: bp3 now contains non-persistent InventoryPeriodSummaryFact preparation with standard-cost snapshot and movement manifests, exact FinancialPeriod and half-open cutoff validation, explicit initial-boundary or adjacent-predecessor evidence, Inventory-only route and original identity gates, active same-company Source Documents, stable Sales-consumption and Purchasing-valuation relationship proposals, role-selected COGS and ordinary adjustment templates, deduplicated inventory control accounts, and exact normalized-line, candidate, operational-control, valuation-rollforward, and ledger reconciliation. Provider codes, names, descriptions, and journal-like text cannot select workflow or accounting meaning. Nonzero cost revisions, PPV, unsupported movement categories, conflicting runs, corrections, and unreconciled inputs remain held. Focused Inventory tests and the complete solution suite pass; no persistence, migration, application workflow, Summary batch, audit, posting, ledger, adapter, or UI behavior changed.

Slice 2A completion record: bp3 now prepares prospective standard-cost revision adjustments as a fact type distinct from period summaries and PPV. Preparation requires the explicit Inventory route, original source identity, company currency, active same-company Source Documents, an open or reopened target FinancialPeriod, a source-time-zone effective boundary, reviewed actor and reason, completed exception-free on-hand manifest, distinct ordered prior and new cost versions, exact unit agreement, and an explicit accepted-history review. A revision that predates the latest accepted Inventory boundary, identifies affected accepted snapshots, conflicts with an accepted revision, uses a closed or planned period, requires unsupported rounding, or fails any source-line, candidate, calculation, or operational-control reconciliation is held visibly. Positive and negative results use only inventory.general and expense.inventory_adjustment; zero results preserve evidence and reconciliation without account resolution or journal lines. Provider text and codes cannot select meaning. Focused revision tests, related regressions, and the complete solution suite pass; no persistence, migration, application workflow, Summary batch, audit, posting, ledger, adapter, or UI behavior changed.

Slice 2B completion record: bp3 now prepares non-persistent Inventory-owned PPV from original, explicitly routed, identity-qualified candidates and active same-company evidence. Stable allocations retain accepted Purchasing acquisition and component meaning, receipt identity, quantity and explicit conversion evidence, purchase amount and unit price, standard-cost version and unit cost, signed variance, and optional posted GRNI. Preparation requires exact allocation, normalized-line, candidate, preview, operational-control, and GRNI carrying reconciliation; prevents allocation overlap; validates supports_purchase_price_variance and adjusts_accrual proposal directions and company-currency amounts; and holds a dependent GRNI settlement until nonzero PPV is posted. Canonical favorable and unfavorable templates use only PPV with Inventory or GRNI roles. Zero variance preserves reconciliation without a PPV event, relationship proposal, account resolution, or journal lines. Twelve focused tests, 330 adjacent regression tests, and the complete solution suite pass. No persistence, migration, application composition, Summary workflow, audit mutation, posting, ledger, adapter, or UI behavior changed.

Slice 3 completion record: bp3 now stages Inventory period summaries, standard-cost revision adjustments, and nonzero PPV through the existing protected Summary Accounting intake and accepted-candidate ownership boundary. Canonical Inventory type, stage, period, source dates, evidence, blocking issues, and immutable-account previews flow into the shared desk. Valid Inventory support and PPV/GRNI proposals resolve through the accepted relationship repository before the candidate link is finalized; interrupted relationship writes recover through exact Summary intake replay. The Inventory lifecycle guard revalidates relationship type, direction, resolution, and posted-GRNI ordering both at mark_ready and immediately before central posting. Existing protected staging, readiness, posting, period, onboarding, audit, posting-result, and ledger controls remain the only posting path. A zero PPV result remains reconciliation-only and creates no PPV event, Summary batch, relationship, audit event, journal entry, or ledger effect. Twelve focused workflow tests, 153 adjacent domain regressions, seven application-composition tests, and the complete solution suite pass. No Inventory aggregate schema, migration, backup catalog, provider adapter, or UI behavior changed.

Slice 4 completion record: bp3 now persists versioned company-scoped Inventory period, standard-cost revision, and nonzero PPV aggregates beneath their Summary batches, including complete preparation, evidence, reconciliation, accepted-event ownership, required relationship identities, queryable valuation snapshots, and queryable PPV allocations. Exact replay recovers identical meaning; conflicting source, idempotency, fact, or company-period original identity cannot overwrite accepted state. The lifecycle guard now requires the durable aggregate and an exact recovered relationship set at readiness and posting. Zero PPV is durably retained as a reconciliation-only result without a Summary batch, accepted accounting event, relationship, audit mutation, or journal. PostgreSQL application composition, schema version bp3-schema-202607290012, and exact company-snapshot-v7 capture and atomic replacement include all four new Inventory relations. Backup qualification also corrected generated FinancialPeriod-range restoration. Focused Inventory, schema, restart, and backup tests pass, and the complete isolated-PostgreSQL solution run passed 1,075 tests with zero failures or skips. Active correction or reversal supersession remains governed by the later Corrections step; this slice preserves conflicting originals without inventing replacement meaning.

Build:

Inventory Summary workflow wrapper;
cost of goods sold and inventory adjustment templates;
inventory template account-role requirements and missing-role readiness messages;
valuation basis and as-of-period metadata;
reconciliation against inventory control accounts;
links to related Sales shipment and Purchasing receipt or acquisition events that cannot create duplicate posting requests;
provider-agnostic REST intake handoff;
variance review and posting through Accounting.

Exit criteria:

inventory valuation can be compared to ledger balances;
variances are visible and explainable;
required inventory, cost, variance, and clearing account roles are visible before preparing or posting summary accounting previews;
source events owned by Sales or Purchasing are not reposted by Inventory; and
operational item, stock, and warehouse records remain outside BooksPlus.

10. Build Banking and Finance Summary

Goal: account for summarized receipts, disbursements, bank and credit-card activity, clearing, and reconciliation while detailed payment instruments, bank feeds, deposit composition, and reconciliation execution remain in the operational system.

Slice	Outcome	Status and next gate
0A. Banking and Finance summary contract	Define one canonical provider-agnostic fact, stage, route, settlement-versus-clearing, statement-match, relationship, reconciliation, account-role, evidence, and held-result boundary.	Complete. Accepted truth fixes Finance ownership, eleven fact/result and stage pairs, direct-versus-clearing isolation, posting templates, allocation directions and open-balance controls, non-posting statement matches, exact account reconciliation, held behavior, and starter-chart v4 Finance roles.
1A. Starter-chart v4 and Finance role readiness	Upgrade the application starter chart from v3 to v4 and resolve the accepted card-liability, finance-charge, and interest roles through existing company-scoped account-role behavior.	Complete. The 27-account chart adds `20700`, `42000`, and `61000` with their accepted roles, preserves v3 upgrade identity and replay, and exposes the roles through ordinary company-scoped resolution and setup review.
1B. Clearing and direct bank/cash preparation	Add the non-persistent Finance boundary for receipt/disbursement clearing and supported direct receipts, direct operating disbursements, and transfers.	Complete. Explicit Finance route, identity, evidence, account selection, clearing/application direction, allocation, and exact reconciliation gates produce a preview or visible held result without persistence or ledger effects.
2. Card, charge, and interest preparation	Add non-persistent credit-card charge/payment, finance-charge, and interest preparation with exact reconciliation and held results.	Complete. Four exact fact/stage pairs extend the shared preparation boundary with explicit card, bank, operating-expense, finance-charge, and interest account selections.
3. Statement match and account reconciliation	Persist non-posting statement-match and account-reconciliation results with exact ledger comparison and evidence.	Complete. Explicitly typed, original Finance results persist only after exact same-company statement-to-posted-event or source-to-ledger reconciliation; held proposals remain unpersisted.
4. Durable Finance persistence and company backup	Complete PostgreSQL fact/result persistence, atomic open-balance controls, recovery, schema/catalog gating, and company backup coverage.	Complete. The nine posting fact/stage pairs and relationship-backed allocations persist with exact replay, atomic reservation, restart recovery, and `company-snapshot-v9` replacement.
5. Summary orchestration and posting	Integrate accepted posting facts with Summary review, central posting, relationship results, and recovery-safe replay.	Complete. Finance now stages, recovers, reserves, revalidates, and posts through the shared protected Summary and central Accounting lifecycle.

Slice 0A completion record: canonical Finance truth now distinguishes later clearing settlements from Finance-owned direct activity, prevents statement matches from reposting direct-bank events, fixes relationship direction and open-balance ownership, and defines exact source-to-ledger reconciliation without balancing or suspense entries. ADRs 0024 and 0029 were amended; ADR 0023 and the Account Role Contract now govern starter-chart v4 card, finance- charge, and interest roles. Verification was documentation consistency and link/state review; no bp3 or bp3-doli implementation changed.

Slice 1A completion record: bp3 now installs booksplus.standard v4 with Credit Card Payable, Interest Income, and Finance Charges and their repeatable, singleton, and repeatable role cardinalities. When the governed installer is rerun, an existing v3 company gains only the three stable logical accounts; exact replay creates nothing, account and role identity remain company-scoped, and setup/onboarding reports all 27 accounts. Focused domain and application tests passed, followed by dotnet test BooksPlus.sln with 993 passed and 84 opt-in PostgreSQL tests skipped. No schema, migration, bp3-doli, Finance fact, or posting change was required.

Slice 1B completion record: bp3 now prepares five non-persistent Finance fact/stage pairs for receipt and disbursement clearing, direct receipts, direct operating disbursements, and account transfers. Explicit company, source, Finance route, original identity, currency, posting date, reference, Source Document, account-role, component, and allocation gates hold invalid inputs. Clearing points from the later Finance settlement to accepted posted Sales or Purchasing activity; direct trade-receivable applications point to accepted posted Sales invoices. Normalized lines, candidate totals, components or allocations, prepared debits and credits, and the reviewed operational control total reconcile exactly with visible differences. Provider journal codes, descriptions, account codes, and names do not select the workflow, template, disposition, or account. Focused verification passed 67 Finance-preparation and relationship-review tests. No persistence, migration, Summary orchestration, posting, ledger, adapter, or bp3-doli change was introduced; authoritative atomic open-balance reservation remains in Slice 4.

Slice 2 completion record: bp3 now prepares Finance-owned credit-card charges, credit-card payments, bank finance charges, and interest receipts through the existing non-persistent import, identity, Source Document, account-role, evidence, and exact-reconciliation boundary. Card charges debit only reviewed operating-expense or finance-charge components and credit the selected card liability; card payments debit an explicitly selected card liability and credit a distinct selected bank account. Bank charges use expense.finance_charges, while interest receipts use revenue.interest. Card fees remain card-charge components rather than using the bank-charge template. Unsupported dispositions, missing or wrong role selections, route or identity failures, provider-inferred meaning, and unreconciled inputs remain held without a preview. Focused verification passed 42 Finance preparation tests; dotnet test BooksPlus.sln passed 1,038 tests with 84 opt-in PostgreSQL tests skipped. No persistence, migration, relationship, Summary orchestration, posting, ledger, adapter, or bp3-doli change was introduced.

Slice 3 completion record: canonical Finance truth now fixes matched and reconciled as the only durable accepted result statuses and names outstanding_item and timing_item as explanatory reconciliation-line types; the explicit signed debit-positive amount controls direction. bp3 validates explicit Finance result fact/stage, original routed identity, company currency, active Source Document evidence, reviewed account roles, posted target events, inclusive local dates with half-open timezone cutoffs, manifest identity, line evidence, exception count, and exact statement or ledger differences. Only accepted results reach in-memory or PostgreSQL repositories; source and idempotency ownership provide exact replay or visible conflict across result kinds. Migration 202607300000 adds the two company-scoped result relations and reconciliation-line children. company-snapshot-v8 captures and atomically restores them, and the backup row projection now avoids collision with the existing account.source column. Focused tests and isolated PostgreSQL restart, replay, company-isolation, capture, and replacement verification pass; the full PostgreSQL-enabled solution suite passed against bp3_step10_slice3_test_20260730 (1,127 passed, zero failed, zero skipped). Finance posting-fact persistence, atomic open-balance consumption, Summary orchestration, posting, adapters, and UI remain excluded for Slices 4 and 5.

Slice 4 completion record: bp3 now persists all nine accepted Finance posting fact/stage pairs beneath company-scoped Summary batches while keeping Slice 3 statement-match and account-reconciliation results separate. Versioned snapshots retain exact accepted-candidate, Source Document, preparation, evidence, reconciliation, external-line, component, and relationship-backed allocation meaning with exact replay, visible conflict, and company isolation. Ready allocation sets reserve posted same-company open balance atomically, revalidate durable journal, relationship, account, component, currency, and previously consumed amounts before posting, and remain capacity-consuming after successful posting; held and released sets do not reserve. PostgreSQL schema bp3-schema-202607300001 and company-snapshot-v9 capture and atomically replace both new Finance relations in dependency order. The full PostgreSQL-enabled solution suite passed against bp3_step10_slice4_test_20260730 (1,135 passed, zero failed, zero skipped). Summary orchestration, journal creation, posting, adapters, and UI remain in Slice 5. No unresolved Slice 4 truth gate remains.

Slice 5 completion record: bp3 now stages all accepted Finance posting facts through protected Summary intake while preserving the prepared preview, evidence, exact reconciliation, accepted candidate, durable Finance aggregate, and resolved Finance-owned allocation relationships. Exact intake replay returns the same batch; an accepted replay can reconstruct interrupted Finance persistence after candidate or relationship durability without creating another Summary batch. The Finance lifecycle guard is composed into both readiness and posting, so ready allocations reserve posted open balance, posting revalidates their exact relationship and capacity, successful central Accounting posting retains the consumed capacity, and a posted batch cannot post again. Held preparation remains visible and non-postable. In-memory and PostgreSQL application composition expose the same workflow boundary. Focused workflow, posting, replay-recovery, allocation, composition, and isolated PostgreSQL dependency tests pass; the full PostgreSQL-enabled solution suite passed against bp3_step10_slice5_test_20260730 (1,142 passed, zero failed, zero skipped). No migration or backup-catalog change was required. Provider adapters and UI remain deferred, and no unresolved Step 10 truth gate remains.

Build:

Banking and Finance Summary workflow wrapper;
customer-receipt, vendor-disbursement, bank-deposit, bank-withdrawal, credit-card, transfer, and clearing-stage facts under accepted truth;
explicit direct-settlement versus clearing-stage templates;
non-posting statement matches for vendor payments already posted directly to bank by Purchasing, without recreating the payable settlement;
links to related Sales invoices, Purchasing vendor invoices, and payment processing events where those references explain the source or reason;
rules that a related invoice reference does not recreate or reroute an invoice event;
reconciliation from summarized cleared and outstanding activity to reviewed bank, card, and cash closing balances;
account-role requirements and readiness messages for bank, cash, credit-card, receipt-clearing, and disbursement-clearing accounts;
provider-agnostic REST intake handoff; and
review and posting through Accounting.

Exit criteria:

a fiscal period can receive Banking and Finance summaries and post accepted settlement and clearing stages as balanced entries;
distinct receipt, deposit, clearing, and bank/card settlement events remain linked without duplicate posting, and direct-bank vendor-payment matches do not repost the Purchasing event;
finance-source invoice text is preserved as payment reason/evidence and is not treated as an invoice fact;
summarized activity reconciles to reviewed closing bank, card, clearing, and cash balances; and
operational payment execution, bank-feed detail, and reconciliation detail remain outside BooksPlus.

11. Build Corrections

Goal: provide safe correction paths before close becomes authoritative.

Slice	Outcome	Status and next gate
0A. Correction and reversal truth and contracts	Define correction kinds, targets, chains, full-reversal derivation, adjustment rules, evidence, periods, posting modes, protected actions, import handoff, relationships, replay, and ledger-derived history.	Complete. The canonical Accounting Correction Contract and focused truth amendments establish one distinct protected Accounting workflow without changing application code.
1. Correction preparation and import handoff	Add a non-persistent preparation boundary for manual or identity-qualified full reversals and adjustments with exact target, evidence, account, period, relationship, meaning-hash, reconciliation, and held-result validation.	Complete. Full reversals derive only from immutable target identities and lines; adjustments require explicit eligible account ids. Both preserve exact controls, visible held issues, period/evidence review, import provenance, and relationship handoff without mutation.
2. Durable correction workflow and recovery	Persist correction identity, status, preview, evidence, issues, accepted-candidate ownership, relationships, replay/conflict, interruption recovery, and company backup behavior.	Complete. Company-scoped in-memory and PostgreSQL repositories preserve staged, held, ready, and abandoned correction state; lifecycle authorization and audit, repository-derived target history, accepted import ownership and relationships, replay/conflict recovery, application composition, and company backup are implemented without posting or ledger effects.
3. Protected correction posting modes	Integrate correction readiness with central `reversal` and `adjustment` posting modes, historical reversal accounts, correction period policy, step-up authorization, audit, journal numbering, and recovery-safe posting.	Complete. Ready corrections are revalidated and posted once through central Accounting with durable correction identity, protected authorization, audit, period and account policy, and interrupted-write recovery.
4. Correction register and drilldown	Show ledger-derived target, result, root original, complete chain, evidence, period, actor, audit, line effects, and held workflow history without treating workflow support state as report truth.	Complete. Read-only application review derives posted history and net account effects from journal entries while presenting non-posted workflow records as explicitly separate support evidence.

Slice 0A completion record: the canonical Accounting Correction Contract defines full-entry reversal and balanced adjustment as distinct correction kinds against one immutable same-company posted journal entry. Reversals derive one-to-one lines from the target and may use its exact historical accounts; adjustments use current active direct-posting accounts. Corrections require an active Source Document, reason, company currency, exact reconciliation, and a new posting date. Open and reopened periods allow correction modes, soft-closed periods require the dedicated protected correction path, and hard-closed periods require a separate reopen. The distinct Accounting workflow does not use Summary batches; imported changes retain candidate identity and may activate corrects or reverses only when both accepted-event endpoints exist. Protected staging, readiness, abandonment, reversal, and adjustment actions, exact replay/conflict behavior, and ledger-derived history are fixed. Documentation consistency and strict-site verification passed. No bp3, bp3-doli, persistence, posting, ledger, audit, or UI behavior changed, and no Slice 0A truth gate remains. Slice 1 followed.

Slice 1 completion record: bp3 now exposes a non-persistent Corrections preparation service for manual or identity-qualified full reversals and adjustments. It resolves the exact same-company posted target, active correction evidence, company currency, posting period, and account identities; derives full reversals one-for-one from immutable target lines, including historical inactive accounts; requires explicit active direct-posting account ids for adjustments; and returns exact target, candidate, reviewed, and prepared reconciliation differences with a deterministic accounting-correction-meaning-v1 hash. Imported preparation preserves run, source-group, source identity, idempotency, accepted-original, and relationship handoff while provider codes, names, journals, and descriptions cannot select correction meaning. The shared relationship reviewer now validates accepted corrects and reverses direction, change type, version, resolution, original target, and posted-target evidence. Missing, mismatched, cross-company, superseded, ineligible-period, unsupported-account, already-reversed, unbalanced, and unreconciled inputs remain held with structured issues. Focused correction and relationship tests passed (51 passed), and dotnet test BooksPlus.sln passed (1,072 passed, zero failed, 87 opt-in PostgreSQL tests skipped). No persistence, migration, protected mutation, posting, ledger, audit, application workflow, adapter, or UI behavior changed; PostgreSQL verification was unnecessary. No Slice 1 truth gate remains. Slice 2 must make target posting mode and already-reversed state repository-derived rather than trusting the current non-persistent review input. Slice 2 is the sole implementation handoff.

Slice 2 completion record: bp3 now persists one company-scoped Corrections workflow record containing correction identity, target, evidence, sanitized preparation input, preview, reconciliation, issues, status, accepted event and relationship handoff, audit references, timestamps, and optimistic version. Stage, mark-ready, and reasoned abandonment use the accepted protected actions and emit succeeded, denied, or failed audit evidence; mark-ready re-prepares from durable input and repository-derived target correction history. Manual and imported exact replay return the same record, conflicting meaning remains visible without overwrite, and replay repairs accepted-candidate, relationship, and audit writes interrupted after record persistence. The accepted-import boundary now has mutually exclusive company-scoped Summary batch and Correction owner keys, and imported corrections use canonical accounting_correction with reversal_accepted or adjustment_accepted. Migration 202607300002, schema bp3-schema-202607300002, and company-snapshot-v10 preserve correction state through restart and atomic company backup replacement. Focused correction, authorization, composition, migration, accepted-import, and PostgreSQL tests pass. The full standard suite passed with 1,090 tests and 88 expected PostgreSQL-gated skips; the PostgreSQL-enabled suite passed all 1,178 tests. No journal entry, posting, ledger, reporting, UI, or provider-adapter behavior changed, and no Slice 2 truth gate remains. Slice 3 is the sole implementation handoff.

Slice 3 completion record: central Accounting now accepts distinct protected reversal and adjustment posting modes only from a ready durable correction record that is re-prepared against current repository truth. Posted correction entries preserve the workflow id, immutable target entry, reason, active evidence, posting mode, and reversal-line target identities; full reversals exchange every target line exactly and may reuse only its exact historical accounts, while adjustments retain routine account eligibility. Open, reopened, and protected soft-closed periods permit correction posting; hard-closed and otherwise ineligible periods remain blocked. Dedicated step-up authorization and succeeded, denied, and failed audit evidence target the corrected entry. Company-scoped uniqueness, exact replay, and repair of an interrupted result-to-audit/workflow link prevent duplicate correction entries. Migration 202607300003, schema bp3-schema-202607300003, and company-snapshot-v11 preserve correction posting identity and reversal-line history through restart and atomic company backup replacement. Focused correction tests passed, the full standard suite passed with 1,097 tests and 88 expected PostgreSQL-gated skips, and the PostgreSQL-enabled suite passed all 1,185 tests against a fresh isolated database. No truth, adapter, UI, or reporting behavior changed, and no Slice 3 truth gate remains. Slice 4 is the sole implementation handoff.

Slice 4 completion record: AccountingCorrectionReviewWorkflow provides a company-scoped, read-only correction register and drilldown boundary. Posted correction rows are selected solely from immutable journal entries and derive the direct target, root original, complete posted chain, target correction status, evidence, posting period, actor, protected posting audit, result-line effects, and chain net effect by stable account identity. Routine entries remain formal ledger context rather than being mislabeled as corrections. Staged, held, ready, and abandoned correction records appear in a separate workflow-support collection with structured issues and an explicit non-ledger/non-report-truth label; posted workflow details may support drilldown but cannot redefine the ledger chain. Missing support leaves posted history reviewable, company isolation is enforced by repository scope, and register or drilldown loading performs no accounting, workflow, evidence, or audit mutation. Four focused application tests and the full standard solution suite passed (1,101 passed, zero failed, 88 expected PostgreSQL-gated skips). PostgreSQL verification was unnecessary because no schema, persistence, query, backup, or migration behavior changed. No canonical truth, provider adapter, formal report, or UI behavior changed, and no Step 11 truth gate remains. Step 12 Slice 0A followed.

Corrections may reuse manual journal-entry preparation and central posting infrastructure, but they must carry correction-specific meaning. A correction workflow is not just a generic journal entry screen with different labels.

Exit criteria:

posted accounting records are corrected without silent mutation;
corrections respect period status and protected-action rules;
close and reports can show corrected history clearly.

12. Build Period Close

Goal: replace direct period toggles with a reviewable close process.

Slice	Outcome	Status and next gate
0A. Close-run truth and contracts	Define close-run identity, modes, check snapshots, severity, waivers, approvals, staleness, finalization, period transitions, reopen, evidence, report-pack references, authorization, audit, replay, and visible blocked outcomes.	Complete. The canonical Close Run Contract fixes the provider-agnostic launch boundary and the related period, evidence, security, trial-balance, and implementation contracts.
1. Close preparation and check evaluation	Evaluate a period into a non-persistent review snapshot using the launch check catalog, period hierarchy, evidence/report inputs, correction disclosure, freshness inputs, and visible blockers.	Complete. The Close preparation boundary produces nine explainable launch-check previews and a deterministic versioned evaluation fingerprint without durable Close identity or mutation.
2. Durable close workflow and recovery	Persist numbered close runs, immutable check snapshots, evidence and report packs, waivers, approval identity, freshness state, replay, company isolation, recovery, and backup behavior without changing period state.	Complete. Company-scoped `CL-` runs preserve exact Slice 1 evaluations, protected decisions, current-run and derived freshness behavior, restart recovery, and company backup without period mutation.
3. Protected finalization and reopen	Integrate current eligible runs with protected soft/hard-close approval and finalization plus top-down reopen, append-only period history, authorization, step-up, audit, concurrency, and recovery-safe mutation.	Complete. Protected Close commands atomically finalize current eligible runs or reopen the current closed state with durable identity, exact replay, append-only state history, and succeeded audit evidence.
4. Close review and report-pack coordination	Show close and reopen history, checks, waivers, approvals, evidence, transitions, staleness, later corrections, and report-run references without making Close own ledger, report rendering, or evidence storage.	Complete. A read-only application register and drilldown coordinate durable Close control evidence with owning period, Reporting, Source Document, audit, and posted-ledger references.

Slice 0A completion record: the canonical Close Run Contract defines company-scoped CL- run references; soft- and hard-close modes; immutable check snapshots; the launch check catalog; non-waivable and policy-waivable blockers; deterministic freshness; supersession; reasoned audited waivers; distinct exact-run hard-close approval; protected finalization; top-down reopen; report-pack and Source Document references; authorization, step-up, audit, idempotency, concurrency, and interrupted-write recovery. It fixes bottom-up close readiness for months, quarters, and years under the period-driven calendar without inventing a nested month-under-quarter tree. The Financial Period Contract now requires CloseRun or CloseReopen identity on new close/reopen state changes, the Trial Balance Contract is canonical for ledger-derived balance checking, and focused Close amendments align evidence, roles, audit, kernel, developer, user, and navigation guidance. Current bp3 direct fiscal-month soft-close, hard-close, and reopen actions remain implementation evidence and must not be treated as Close authority; Slice 3 will route or replace them after preparation and durable workflow slices exist. Strict documentation verification passed. No bp3, bp3-doli, database, posting, period, audit, or UI behavior changed, no proposed ADR is required, and no Slice 0A truth gate remains. Slice 1 followed.

Slice 1 completion record: bp3 now exposes a non-persistent Close preparation boundary for soft- and hard-close review. It evaluates all nine launch checks from company-scoped financial-period state and hierarchy, posted-ledger trial balance and correction relationships, Summary and Corrections workflow state, active Source Documents, and versioned reconciliation and persisted-report-run snapshots supplied through a read-only resolver boundary. Month, quarter, and year constituent rules, non-waivable and policy-waivable blockers, informational later-correction disclosure, stable source references, and missing, cross-company, stale, inexact, nonterminal, unbalanced, superseded, and mismatched inputs remain visible. The versioned close-evaluation-v1 fingerprint covers the canonical freshness inputs while excluding display labels, actor identity, timestamps, provider text, and UI state. Application composition exposes the service with an unavailable-reference default that holds unresolved Reporting or reconciliation inputs instead of inventing external truth. Six focused Close tests passed; the relevant period, Reporting, Source Document, Summary, and Corrections suites passed (291 passed, zero failed, 36 expected PostgreSQL-gated skips); and the full standard solution suite passed (1,107 passed, zero failed, 88 expected PostgreSQL-gated skips). No migration, CloseRun number, durable check or pack, waiver, approval, authorization, audit, period-state, posting, ledger, UI, provider, or bp3-doli behavior changed, so PostgreSQL verification was unnecessary. No truth gate remains. Slice 2 is the sole next handoff.

Slice 2 completion record: bp3 now persists company-scoped, numbered CL- CloseRuns with immutable launch-check snapshots and exact evaluation fingerprints. Each run captures its evaluated period state, normalized request identity, report-run references, active Source Document references when valid, submitted evidence identities when held, and one immutable report pack. Protected evaluation, waivable blocker waiver and revocation, distinct hard-close approval, and abandonment preserve reason, actor, machine, correlation, succeeded, denied, and failed audit evidence. Exact replay returns accepted state, conflicting identity reuse is rejected, newer evaluations supersede unfinalized runs, approval history is invalidated without deletion, and later decisions require the latest run and a fresh recomputed Slice 1 fingerprint. In-memory and PostgreSQL repositories, optimistic versions, company constraints, database uniqueness, restart recovery, application composition, and company-snapshot-v12 capture and atomic restore preserve the complete durable graph. The focused Close suite passed, and the full PostgreSQL-enabled solution suite passed against the isolated bp3_close_slice2_test database (1,201 passed, zero failed, zero skipped). No period state, posting, ledger, report rendering, evidence content, UI, adapter, or bp3-doli behavior changed, and no truth gate remains. Protected finalization and top-down reopen in Slice 3 is the sole next handoff.

Slice 3 completion record: bp3 now finalizes a current fresh soft-close run or an exactly approved hard-close run through distinct protected actions and one atomic transition boundary. Finalization durably links the CloseRun, append-only financial-period state change, and succeeded audit event; exact replay returns the accepted result, conflicting command reuse is rejected, concurrent attempts cannot create duplicate transitions, and denied, failed, stale, ineligible, or superseded attempts leave period state unchanged. Hard close requires reason capture and step-up; soft close requires its protected permission and reason. A durable CloseReopen command reopens only the current closed state established by the latest finalized same-company run, preserves optional active same-company Source Document evidence, requires reason and step-up, and enforces containing-period-first hierarchy without cascade. Low-level and setup-screen close/reopen mutations are blocked behind the protected workflow. PostgreSQL migration 202607300005 and company-snapshot-v13 preserve finalization, reopen, linked state history, replay, restart recovery, and atomic company backup replacement. The full standard solution suite passed (1,118 passed, zero failed, 89 expected PostgreSQL-gated skips); the full migration chain applied cleanly to an isolated fresh database; and the complete PostgreSQL-enabled solution suite passed there (1,207 passed, zero failed, zero skipped). No ledger posting, report rendering, evidence content, provider, adapter, or bp3-doli behavior changed, and no truth gate remains. Close review and report-pack coordination in Slice 4 is the sole next handoff.

Slice 4 completion record: CloseReviewWorkflow now provides company-scoped, read-only Close run, reopen, and adverse-attempt registers plus CloseRun drilldown. It shows recognizable CL- and period references; mode, status, policy, evaluation, current eligibility freshness, and terminal history; original immutable check outcomes and effective waiver disposition; waiver, approval, finalization, abandonment, supersession, reopen, and protected audit attribution; report-pack and Reporting-owned report-run references; Source Document-owned evidence identity and current status; append-only period state changes; and later corrections derived only from posted journal-entry relationships. Finalized snapshots remain historical rather than being reclassified by later eligibility changes, and period-scoped denied or failed attempts are visibly distinguished when they are not durably linked to one CloseRun. Close records remain labeled control evidence rather than ledger or formal report truth. Four focused application tests passed; the relevant Close, financial-period, correction-review, and drilldown suites passed (72 passed, zero failed, one expected PostgreSQL-gated skip); and the full standard solution suite passed (1,122 passed, zero failed, 89 expected PostgreSQL-gated skips). No schema, persistence, backup, migration, accounting, period, Source Document, audit, report execution, rendering, UI, provider, adapter, or bp3-doli behavior changed, so PostgreSQL verification was unnecessary. No truth gate remains. Step 13 Slice 0A follows.

Build:

close runs;
close-check snapshots;
blocker, warning, and informational outcomes;
waiver policy and waiver audit trail;
petty-cash SOP reconciliation evidence and unresolved-exception treatment under accepted direct-purchase truth;
approval and finalization steps;
soft close and hard close period transitions;
close report packs and evidence references.

Exit criteria:

a period cannot hard close with unresolved blockers unless policy permits an explicit waiver;
approval is tied to the facts reviewed;
close evidence remains reviewable after the period changes state.

13. Build Reporting

Goal: make period results reviewable from posted ledger truth.

Slice	Outcome	Status and next gate
0A. Reporting truth and contracts	Define standard report identity and definitions, ledger-derived line and grouping meaning, parameters, execution, persisted runs and snapshots, corrections, currencies, presentation ownership, Close consumption, authorization, audit, replay, and visible unavailable outcomes.	Complete. Canonical Reporting truth and its contract now govern the three launch definitions, live and captured results, calculations, immutable `RR-` snapshots, fingerprints, currentness, security, recovery, Close resolution, and drilldown.
1. Standard report preparation	Prepare explainable trial balance, balance sheet, and income statement results from posted ledger truth under the accepted report definitions without persistence or rendering ownership leakage.	Complete. Reporting now prepares the three launch definitions through one protected, non-persistent result boundary with exact account-type calculations, company-currency enforcement, issues, source contributions, fingerprints, attribution, and audited execution.
2. Persisted report runs and recovery	Persist immutable company-scoped report execution identity, parameters, attribution, summaries, snapshot payloads, replay, recovery, and company backup.	Complete. Migration `202607300006` and the PostgreSQL-enabled solution suite verify ReportRun restart and replay, interruption rollback, company isolation, schema conformance, and company backup/restore with no skipped tests.
3. Close report-run integration	Resolve persisted Reporting snapshots through the Close reference boundary and preserve exact report-run identity and freshness without moving report execution into Close.	Complete. Reporting owns exact durable resolution and currentness recomputation; Close consumes only validated references, and the full PostgreSQL-enabled gate passes after the bounded period-history repair.
4. Reporting review and presentation coordination	Expose live and captured report review and drilldown while keeping rendering separate from report truth and workflow support records out of formal results.	Complete. Protected review coordinates all three live reports and immutable captured runs, with currentness, formal source drilldown, and current support, Close, and audit context kept explicitly separate.

Slice 0A completion record: canonical Reporting truth now fixes trial_balance, balance_sheet, and income_statement under standard-financial-reports-v1; inclusive parameters; account-type classification; company-currency and exact-precision rules; correction treatment; cumulative unclosed earnings; live availability, issues, source contributions, and fingerprints; immutable company-scoped RR- runs and snapshots; computed currentness; protected report.view and report_run.capture; audit, replay, concurrency, recovery, backup, Close resolver, and drilldown behavior. ADR 0009, the trial-balance, Account, Correction, Close, Security, kernel, and company contracts, and derived developer and user guidance now align with that boundary. The stale backup contract was corrected to the implemented company-snapshot-v13 and bp3-schema-202607300005 baseline; Reporting persistence must advance both. The existing trial-balance implementation remains evidence only: Slice 1 must add the canonical result envelope, issues, fingerprints, source contributions, company-currency enforcement, protected execution, and the two missing statements, and must not silently omit malformed cross-company account references. Documentation verification passed with the strict MkDocs command recorded below. No application, persistence, provider, adapter, or bp3-doli behavior changed, and no truth gate remains. Slice 1 follows.

Slice 1 completion record: bp3 now provides StandardReportPreparationService and canonical live result models for trial_balance, balance_sheet, and income_statement. The service derives formal values only from same-company posted journal-entry lines and immutable account identity; validates exact parameters, optional period identity, company currency, journal and line identity, account scope, and statement equations; preserves current account labels, attribution, normalized parameters, corrections by their own posting dates, source contributions, and deterministic ledger-input fingerprints; and returns available zero reports or visible unavailable issues without partial formal lines. Account type alone selects statement sections, cumulative unclosed earnings remains a derived balance-sheet line, and provider-like definition codes, account codes, names, normal balances, and descriptions cannot select report meaning. report.view and report_run.capture are registered without reason or step-up requirements; live execution enforces report.view and records succeeded, denied, or failed audit evidence. The existing trial-balance application seam now uses this protected Reporting boundary. Fourteen focused Reporting tests and three application workflow tests passed; the relevant Reporting, Security, setup, application, and Close-preparation suites passed (119 passed, zero failed, 12 expected PostgreSQL-gated skips); and the full standard solution suite passed (1,136 passed, zero failed, 89 expected PostgreSQL-gated skips). No schema, persistence, ReportRun, snapshot, Close resolver, backup, rendering, provider, adapter, or bp3-doli behavior changed, so PostgreSQL verification was unnecessary. No truth gate remains. Slice 2 follows.

Slice 2 implementation record: bp3 now captures only available canonical report results as immutable, company-scoped RR- ReportRuns. One atomic repository write preserves command and request identities, company numbering, normalized parameters, definition and fingerprint schema versions, generation and capture attribution, the exact result payload, normalized report lines and source contributions, and the linked succeeded report_run.capture audit event. Exact replay returns the accepted run without another number or succeeded audit; changed identity meaning conflicts visibly; denied, unavailable, failed, and interrupted attempts leave no partial run or consumed number. In-memory and PostgreSQL repositories, application composition, and migration 202607300006 implement the boundary. The canonical company backup catalog advances to company-snapshot-v14 / bp3-schema-202607300006 and classifies the complete Reporting aggregate for atomic replacement. Focused Reporting and schema tests and the standard solution suite passed. The repository migration runner applied migration 202607300006 to the approved local bp3a development database. A restart test assertion was corrected to compare the complete reloaded snapshot payload structurally rather than compare collection instances. Both focused PostgreSQL ReportRun tests passed, then the full PostgreSQL-enabled solution suite passed 1,233 tests with zero failures or skips, covering restart and exact replay, interruption rollback, company isolation, schema conformance, and company backup/restore. No Close resolution, rendering, UI, provider, adapter, posting, or ledger behavior changed, and no truth gate remains. Slice 3 is the sole next handoff.

Slice 3 implementation record: bp3 now composes a Reporting-owned ReportRunCloseResolver for both in-memory and PostgreSQL application paths while preserving explicit test injection. It resolves only exact same-company durable ReportRun ids, returns canonical definition and version, optional period identity, normalized parameters, company currency, persisted status, snapshot fingerprint, and computed currentness, and reuses the internal standard-report calculation boundary without another report.view authorization or audit event. Currentness is recomputed from current posted ledger truth and compared with the captured ledger-input fingerprint without mutating the run. Close continues to persist only ReportRun ids and now blocks missing or mismatched company, definition, version, parameter schema, period, inclusive boundaries, currency, captured status, fingerprint, or currentness. Focused Reporting, Close, and application-composition tests passed, including the exact PostgreSQL repository-restart resolver test and the absence of a second report.view audit event.

Deterministic period-history gate-repair completion record: canonical Financial Period persistence now assigns a positive contiguous sequence_number within each period and treats it, rather than attribution time or UUID identity, as the causal state-change order. Migration 202607300007 backfills only a unique valid status chain and aborts on missing, ambiguous, invalid, or status-mismatched legacy history; PostgreSQL constraints preserve positive period-local uniqueness. Ordinary period persistence and protected Close finalization and reopen allocate and read the same sequence under the period lock. Company backup advances to company-snapshot-v15 / bp3-schema-202607300007 and preserves the sequence through atomic replacement. Equal-time reverse-UUID, sequence-gap, concurrent-save, restart, Close replay, and before/after backup tests cover the defect. Migration 202607300007 applied cleanly to the approved isolated local development target. The repaired standard solution suite passed 1,149 tests with zero failures and 94 expected PostgreSQL-gated skips; the full PostgreSQL-enabled solution suite executed and passed all 1,243 tests with zero failures or skips. The Slice 3 gate is resolved, no Reporting calculation, posting, provider, adapter, rendering, UI, or bp3-doli behavior changed, and Slice 4 is the exactly one Next slice.

Slice 4 completion record: bp3 now provides a protected, company-scoped ReportRun register and captured-run review boundary plus an application coordination workflow for all three standard live reports. Captured review returns the exact immutable snapshot, captured account labels and formal source contributions, computed currentness, and capture and review audit evidence. Line drilldown keeps current account and journal support, Close references, and protected audit context explicitly outside the formal captured result; account label changes and later postings therefore remain visible without rewriting the snapshot. Missing and cross-company identities disclose no report metadata, denials create value-free denied audit evidence, and malformed live requests produce visible blockers rather than partial results. The workflow reuses the canonical Reporting preparation, repository, currentness, authorization, and audit boundaries; no report calculation or rendering authority moved into the application layer or Close. Forty-seven focused Reporting, review-workflow, Close, and composition tests passed, as did all four focused PostgreSQL ReportRun tests. The full standard solution suite passed 1,161 tests with zero failures and 95 expected PostgreSQL-gated skips; the full PostgreSQL-enabled suite passed all 1,256 tests with zero failures or skips. No schema, migration, backup, posting, ledger, UI rendering, export, provider, adapter, or bp3-doli behavior changed. No truth gate remains. Step 13 is complete and Step 14 is the sole next step.

Build:

trial balance polish;
balance sheet;
income statement;
persisted report runs;
close-pack report capture;
later exception and support reports, including 1099 support reports, as operational artifacts rather than launch formal statements.

Exit criteria:

formal reports derive from posted ledger lines;
captured reports preserve parameters, actor, generated time, and snapshot payload;
close can reference report runs without owning report rendering.

14. Build replacement-scenario QBO controlled conversion; defer external automation

Goal: in the replacement scenario, give a company a controlled QBO cutover into BooksPlus-supported accounting state without creating a second ingestion, reconciliation, or posting engine. Startup-scenario companies complete ordinary Setup & Onboarding and do not enter Step 14.

ADR 0032 and the canonical Company Conversion Run Contract govern Step 14. The accepted boundary distinguishes one controlled company cutover from still-deferred broad migration entries and external automation.

Verified implementation baseline

bp3 already provides AccountingImportRun and immutable payload intake through AccountingImportIntakeService; AccountingJournalCsvProfile version 1 parsing; AccountingImportRoutingService; AccountingImportIdentityService; durable accepted-candidate links; in-memory and PostgreSQL repositories; protected accounting_import_run.stage; append-only audit; and exact file and candidate replay, conflict, duplicate-meaning, correction, and company-scope controls. The four Summary workflow owners, Accounting Correction workflow, ChartImportService, OpeningBalanceSetupReviewService, period eligibility, PostingService, Source Documents, and company backup already provide the downstream accounting and recovery seams.

That baseline now also provides the versioned non-production QBO fixture profile, two exact representative fixture packages, fingerprinted explicit account-mapping review, canonical chart-import staging for reviewed new accounts, a durable CompanyConversionRun, exact conversion controls, and protected approval, chart application, and opening-balance posting with interruption-safe recovery. It now also provides protected exact-realm token handoff, read-only QBO API extraction, durable encrypted checkpoints, and an immutable live-capture import manifest plus fail-closed translation into the existing controlled-cutover facts. It does not provide general customer/vendor/item masters, receivable or payable subledgers, fixed-asset records, historical-conversion workflow, a client-secret-bearing OAuth broker or hosted callback. The existing CSV profile remains a qualified accounting-journal profile, not a generic interchange engine or evidence that arbitrary QBO objects are supported.

Slices

Slice	Outcome	Status and gate
14A. Conversion truth and architecture	Authorize QBO-first controlled cutover, bound supported accounting state and evidence, and settle ownership, reconciliation, approval, recovery, transport, and deferrals.	Complete. ADR 0032 and the Company Conversion Run Contract establish a separate company-scoped aggregate, one successful initial application per company, durable attempts and recovery, and reuse of existing BooksPlus authorities.
14B. QBO profile and fixtures	Qualify a versioned QBO conversion profile against representative non-sensitive exports or captured API fixtures without live connectivity.	Complete. Version 1 parses the exact representative fixture package into raw-preserving account mapping proposals, trial-balance control facts, and explicit compatibility issues without persistence or mutation.
14C1. Chart and mapping foundation	Stage and review QBO-to-BooksPlus account mappings and chart changes through existing chart maintenance.	Complete. Explicit decisions produce a deterministic mapping fingerprint, bind existing account ids or staged new-account rows, preserve exclusions, and block unresolved or ambiguous meaning without chart commit or posting.
14C2A. Durable conversion review aggregate	Persist `CompanyConversionRun`, source links, mapping selection, protected stage/mapped transitions, replay, audit, and company backup.	Complete. Durable review ownership, causal history, company-scoped constraints, restart, exact replay, protected audit, and exact company backup/restore are verified.
14C2B. Opening controls and approval	Qualify applicable source control schedules, persist reconciliation and dispositions, and bind protected approval.	Complete. Profile version 2, deterministic exact controls, durable blocked or reconciled results, and exact-fingerprint approval are verified through PostgreSQL restart and company backup/restore.
14C2C. Opening application and recovery	Apply an approved chart/opening position through existing owners with durable step/result identities and interruption-safe resume.	Complete. Protected application persists `applying`, exact chart-account results and exact opening posting identities before `applied`; interrupted work resumes without code- or amount-based inference.
14D. Live QBO connector	Feed the qualified path through secure, restartable, explicitly company-selected QBO extraction.	Complete. Protected exact-realm connections, read-only live requests, encrypted response checkpoints, restartable resume, and immutable import-manifest handoff are implemented. Client-secret callback, refresh, and revocation remain a narrow broker boundary.
14E. Conversion qualification	Demonstrate a recoverable controlled cutover with complete reconciliation and evidence.	Complete. Exact manifest and protected-response qualification, deterministic intake replay, visible unavailable-control blocking, company isolation, audit, and the previously qualified retry, interruption, conflict, rejection/correction, duplicate-posting, period, and backup/restore paths pass together.

Slice 14A completion record: ADR 0032 is accepted and ADR 0020 now distinguishes QBO controlled cutover from deferred broad migration entries and external automation. The canonical CompanyConversionRun is a separate company-scoped aggregate that links immutable import runs and coordinates existing BooksPlus authorities. Multiple durable attempts are permitted, but only one initial controlled cutover may be applied per company. Its lifecycle preserves staged, mapped, reconciled, approved, applying, applied, failed, abandoned, and superseded meaning; approved inputs are fingerprinted; interrupted application resumes idempotently; and persistence must join the company backup catalog in the same implementation slice. No application, provider, schema, migration, or bp3-doli behavior changed. Strict documentation verification passed. Slice 14B is the sole next handoff.

Slice 14B completion record

bp3 now owns QboControlledCutoverFixtureProfile version 1 and an exact, representative, non-sensitive, documentation-derived US sandbox-shaped fixture set. The baseline package selects one QBO realm and preserves exact bytes, SHA-256, compatibility identity, source context, company/settings facts, four account facts, one balanced opening trial balance, and explicit object-state evidence. Slice 14C1 adds a second checksum-locked chart-complete fixture with the missing equity account fact while retaining the baseline fixture to prove that incomplete trial-balance account coverage blocks mapping. Normalization produces only non-posting account mapping proposals and a provider-agnostic trial-balance control fact. Stable account identities use QBO object id and source version; control identity includes cutover date, basis, and payload hash.

The Draft QBO Controlled-Cutover Fixture Profile records the exact fixture identity, provider support matrix, source fields, company-selection checks, date and amount interpretation, identity rules, known unavailable facts, and compatibility limits. Inactive, changed, voided, deleted, merged, malformed, duplicate, conflicting, unsupported-currency, and ambiguous facts remain explicit issues rather than inferred accounting truth. The profile has no network, repository, workflow, chart, Source Document, period, audit, or ledger dependency. Focused profile tests passed all 12 tests; 57 adjacent import, intake, identity, and routing tests passed; and the full standard solution passed 1,173 tests with 95 expected PostgreSQL-gated skips. No PostgreSQL-enabled gate was required because Slice 14B adds no persistence. Strict wiki verification passed. Slice 14C1 is the sole next handoff.

Slice 14C1 completion record

QboChartMappingReviewService now reviews one explicit decision for every qualified QBO account. A decision binds the source identity to one exact active same-company BooksPlus account id, stages one explicitly coded and classified active account, or excludes a non-balance-bearing source account with a reason. Names, numbers, and QBO types never select or classify a BooksPlus target.

Fingerprint schema qbo-chart-mapping-v1 deterministically binds company, import run, payload hash, realm, source profile, mapping version, source identities and raw-object hashes, and normalized decisions. Decision ordering does not affect the fingerprint. Exact replay reuses the existing staged ChartImportBatch; changed reviewed meaning under the same staged version is a conflict. Missing source facts or decisions, duplicate or unknown decisions, inactive source or target accounts, cross-company targets, duplicate targets or codes, balance-bearing exclusions, source-profile blockers, and chart-import errors prevent completion.

Only canonical chart-import rows are persisted. The service does not commit the chart, create accounts, write history or audit, accept a conversion mapping selection, create Source Documents, or post. The future CompanyConversionRun must preserve the selected version, fingerprint, decisions, dispositions, chart result identities, and backup state before conversion approval.

All 7 focused mapping tests passed; 41 adjacent QBO profile, chart import, chart maintenance, and application-composition tests passed; and the focused mapping plus PostgreSQL chart-import gate passed all 9 tests without skips. The full standard solution passed 1,180 tests with 95 expected PostgreSQL-gated skips. The full PostgreSQL-enabled solution passed all 1,275 tests without failures or skips. No schema, migration, backup, account, audit, Source Document, period, journal, ledger, provider, network, or bp3-doli behavior changed. Strict wiki verification passed. Slice 14C2 is the sole next handoff.

Slice 14C2A completion record

Outcome: establish durable, company-scoped conversion review ownership before opening controls, approval, or application depend on it.

Included:

create the separate CompanyConversionRun aggregate in draft and preserve its complete canonical lifecycle vocabulary for later transitions;
protect and audit stage and mark_mapped, with actor/company resolution, stable command identity, exact replay, changed-meaning conflict, and optimistic concurrency;
validate and persist same-company immutable AccountingImportRun links with explicit payload roles;
preserve one explicit mapping-set id, version, fingerprint, every reviewed mapping decision/disposition, and its staged chart-import reference where applicable;
add in-memory and PostgreSQL repositories, database constraints, causal status history, company isolation, restart behavior, and the one-applied-run constraint required before later application exists; and
update the company backup catalog, schema version, capture/restore ordering, conformance tests, and aggregate round-trip coverage in the same persistence slice.

Excluded:

new QBO object or control-schedule fields, reconciliation, material- difference policy, approval fingerprints, or conversion adjustments;
chart commit, account creation, Source Document creation, opening-balance posting, application steps, applying or applied transitions;
live connectivity, OAuth, provider credentials, or recurring sync; and
Dolibarr, IRIS, professional-interchange, tax-product, and support-access work.

bp3 now owns the separate CompanyConversionRun aggregate and its complete canonical status vocabulary. This slice implements draft creation and the protected stage and mark_mapped transitions only. Staging reloads and revalidates the exact immutable QBO payload, then binds all four canonical payload roles. Mapping acceptance requires a complete same-company review, exact existing-account versions, and exact durable staged chart rows. Stable command identities provide exact replay and changed-meaning conflict without mutating durable state; status history is causal and optimistic concurrency is enforced.

PostgreSQL persists the aggregate snapshot plus relational import links, mapping decisions, and status changes. Foreign keys enforce company ownership across imports, accounts, and chart batches; one partial unique index reserves the one-applied-run invariant for later application. All canonical conversion protected-action names are registered, while only the transitions owned here are executable. Application composition selects in-memory or PostgreSQL repositories consistently.

Company backup advances to company-snapshot-v16 / bp3-schema-202608010000. Its catalog, projections, insertion order, replacement cleanup, and exact restore include the complete conversion graph. Migration 202608010000 applied cleanly. Focused lifecycle tests passed all 3 tests; focused PostgreSQL conversion and backup tests passed all 7 tests; the full standard solution passed 1,184 tests with 97 expected PostgreSQL-gated skips; and the full PostgreSQL-enabled solution passed all 1,281 tests without failures or skips. Strict wiki verification passed. No chart commit, account creation, reconciliation, approval, posting, provider connectivity, or bp3-doli behavior changed.

Slice 14C2B completion record

The qualified QBO fixture profile advances to version 2 and compatibility identity qbo-fixture-package-v2. Both exact fixtures now declare receivables, payables, inventory, bank, credit-card, sales-tax, payroll- liability, and retained-earnings/prior-income applicability. Applicable schedules preserve normal balance, exact control amount, record count, trial-balance account ids, and evidence references. Non-applicable schedules require a reason and cannot claim amounts or accounts. The applicable bank control includes checks, deposits, payments, and transfers explicitly.

Control result version conversion-control-v1 deterministically binds the exact source payload, durable mapping fingerprint, cutover date and currency, trial-balance equality, balance-sheet equality, all eight schedules, outstanding instruments, evidence, and mapping/source disposition counts and amounts. Exact equality is required; no materiality threshold was invented. Blocked results remain durable and reviewable in mapped; only matched or explicitly non-applicable controls reach reconciled.

Approval version conversion-approval-v1 requires a distinct protected authorization decision and visible confirmation of the exact approval fingerprint and selected source company. The fingerprint binds company, source links and hashes, profile and cutover parameters, mapping, control result and dispositions, and approving actor. Exact command replay returns the durable result; changed confirmation is rejected without mutation and emits value-free audit evidence.

PostgreSQL migration 202608010001 persists control results, checks, approval, and deferred audit relationships. Company backup advances to company-snapshot-v17 / bp3-schema-202608010001; exact replacement and absent-company recovery preserve a fully approved conversion graph. Focused profile, mapping, workflow, persistence, and backup gates pass. The full standard solution passed 1,187 tests with 97 expected PostgreSQL-gated skips; the full PostgreSQL-enabled solution passed all 1,284 tests without failures or skips. Strict wiki verification passed. No chart commit, account creation, Source Document creation, posting, provider connectivity, or bp3-doli behavior changed.

The handoff into Slice 14C2C required exact chart and opening-balance result identities and prohibited completion inference from account codes, descriptive text, amount equality, or provider state.

Slice 14C2C completion record

Application version conversion-application-v1 binds the immutable approval, applying actor, stable request identity, and two ordered application steps. The protected command enters durable applying before mutation and requires visible confirmation of the exact approval fingerprint and source company. Denied or invalid confirmation remains value-free and does not mutate the run.

The chart step invokes canonical chart import under the applying actor's distinct chart_of_accounts.change authority. Chart batches now preserve the commit actor. Result links bind every approved staged mapping and chart row to the exact created account id and version. Interrupted commit recovery requires batch-correlated account history and never treats an account-code match as proof of completion.

The opening step resolves the exact qualified trial balance through approved existing accounts and persisted chart results, then calls OpeningBalanceSetupReviewService. Setup readiness, company currency, cutover date, eligible-period control, Source Document creation, protected central posting, and downstream audit remain authoritative. A stable run-derived source identity allows interruption after posting to recover only the exact journal, lines, Source Document, evidence, actor, and audit result without a duplicate posting.

PostgreSQL migration 202608010002 adds durable application, step, and applied- account records with company-scoped result foreign keys and commit attribution. Company backup advances to company-snapshot-v18 / bp3-schema-202608010002 and preserves interrupted applying state through replacement and absent-company recovery. The full standard solution passed 1,188 tests with 97 expected PostgreSQL-gated skips; the full PostgreSQL- enabled solution passed all 1,285 tests without failures or skips. Strict wiki verification passed. No provider connectivity, operational subledger, historical reconstruction, or bp3-doli behavior changed.

Slice 14D completion record

The canonical QBO Conversion Connector Contract now separates the desktop's read-only capture from a narrow authorization broker that owns every client-secret-bearing callback, code exchange, refresh, and revocation. BooksPlus protects exact-realm token bundles with the company data key, requires an explicit BooksPlus-company and QBO-realm match, and registers separate protected connection, credential-replacement, extraction, and disconnect actions with value-free audit.

QboHttpApiClient issues realm-scoped sandbox or production reads for CompanyInfo, deterministically paged Accounts, TrialBalance, BalanceSheet, AgedReceivables, AgedPayables, InventoryValuationSummary, and SalesTaxLiability. QboConnectorService persists each exact response as a protected payload before advancing. Resume starts after the last checkpoint; transient failure retains in_progress, authentication failure requires a new exact-realm credential handoff, and stable request identities reject changed meaning. A complete secret-free qbo-live-api-capture-v1 manifest enters only the canonical AccountingImportIntakeService; no provider response, mapping, chart, Source Document, journal, or ledger authority moved into the connector.

PostgreSQL migration 202608010003 adds company-scoped connections, extractions, and checkpoints bound to protected payload and import identities. Company backup advances to company-snapshot-v19 / bp3-schema-202608010003 and preserves interrupted checkpoint recovery and encrypted credentials through replacement and absent-company restore. The full standard solution passed 1,197 tests with 98 expected PostgreSQL-gated skips; the full PostgreSQL-enabled solution passed all 1,295 tests without failures or skips. Strict wiki verification passed. No callback or broker deployment, recurring synchronization, QBO write, live-response conversion qualification, Dolibarr, IRIS A2A, or bp3-doli behavior changed.

Slice 14E completion record

QboLiveCaptureQualificationService authorizes a distinct qbo_conversion_extraction.qualify action and resolves only a completed, same-company extraction. It verifies the immutable manifest, deterministic operation/page sequence, protected response company and owner binding, authenticated recovery, request identity, length, and SHA-256 before parsing. Raw provider responses remain protected and ordinary audit remains value-free.

A successful translation stages one deterministic qbo-live-qualified-package-v1 through canonical Accounting Import intake as qbo-controlled-cutover-live version 1. The existing controlled-cutover parser now accepts that source profile without weakening or renaming the representative fixture profile. Company, account, trial-balance, and eight control-schedule facts therefore enter the same mapping, reconciliation, approval, application, Source Document, period-control, posting, recovery, and backup/restore path already qualified in Slices 14C and 14D.

Qualification stages nothing when report context, totals, account identities, or trial-balance comparisons are missing or inconsistent. Complete Account capture plus a consistent zero report may establish explicit non- applicability. Applicable bank accounts remain visibly blocked because the version 1 live capture does not supply the required outstanding checks, deposits, payments, and transfers; the translator never infers those facts.

Focused QBO and conversion regression passed 39 tests. The full standard solution passed 1,201 tests with 98 expected PostgreSQL-gated skips; the full PostgreSQL-enabled solution passed all 1,299 tests without failures or skips. Strict wiki verification passed. No schema or backup version changed because qualification creates no parallel aggregate: company backup version company-snapshot-v19 already preserves the protected capture, immutable Accounting Import payloads, conversion run, application results, audit, Source Documents, and journal evidence. No broker deployment, QBO write, recurring synchronization, broader migration, Dolibarr, IRIS A2A, provider payload mapping, or bp3-doli behavior changed.

Step 14 is complete. Any further initial-release scope begins in Step 15 rather than extending the conversion aggregate.

The former external-adapter Step 14 mixed several unlike outcomes. They are now classified explicitly:

QBO controlled cutover is the completed Step 14 scope.
Duplicate, replay, conflict, correction, and reversal handling are already implemented in the provider-agnostic intake and Accounting Correction owners. Step 15 must expose and qualify the relevant review paths; it must not create a second duplicate or correction engine.
Dolibarr REST capture for the four Summary workflows, production provider payload/profile mapping, durable outbox delivery and evidence expansion, and direct IRIS A2A transmission, acknowledgments, rejection handling, and corrections are deferred beyond the initial release under ADR 0020.
The existing bp3-doli shipment/COGS connector, durable-outbox plumbing, and local placeholder contract remain development evidence only. They do not make the deferred four-workflow adapter scope production-ready.

Deferred professional interchange

Professional workpaper packages, a least-privilege read-only professional role, and proposed adjustment batches remain visible follow-on workstreams, separate from Step 14 conversion delivery. Workpapers may later use an integrity-protected package with reviewed tabular, rendered, and structured artifacts. Professional access requires its own permission and security truth. Proposed adjustments may reuse import and correction review only after a truth-and-code fit review and must post solely through protected Accounting. Native QuickBooks Accountant's Copy or company-file generation and direct tax-software integration remain deferred. Professional access must not be implemented through the separately deferred support-access workflow.

There is no remaining Step 14 implementation handoff.

Kernel follow-up: business time and period cutoffs

Accepted ADR 0033 and the canonical Business Time Contract generalize the former Inventory-only local-midnight rule without making a user's current location or fixed UTC offset accounting authority.

Slice	Outcome and included work	Truth gate and exclusions	Verification and acceptance	Status
2T1. Canonical business-time boundary	Define exact instants, named zones, company-local business dates, half-open FinancialPeriod cutoffs, presentation separation, future operational-location ownership, and consolidation compatibility. Align company, period, kernel, Inventory, Finance, Close, Reporting, UX, user, and developer guidance.	Governed by ADR 0033 and the Business Time Contract. Does not define location masters, user preferences, group calendars, currency translation, eliminations, or provider inference.	Strict wiki verification finds no fixed-offset accounting authority, no Close timestamp mislabeled as a close date, and no derived rule conflicting with binding truth.	Complete
2T2. Company zone and shared cutoff implementation	Persist one validated named accounting time-zone id on Company; collect a visible setup value; add one shared resolver for inclusive dates to `[start, endExclusive)` UTC instants; reuse it in Inventory and Finance cutoff validation; preserve backup and migration behavior.	Company zone controls FinancialPeriod boundaries. Source zones remain evidence and must agree or hold. User/host zone affects only the visible setup default. Excludes user preference persistence, operational locations, consolidation, broad timestamp reformatting, and retroactive accounting changes.	Domain tests cover valid and invalid named zones, UTC, DST-dependent offsets, half-open inclusion, invalid or ambiguous boundaries, and Company mapping. Application tests cover explicit company setup. PostgreSQL tests cover migration, restart, and backup/restore preservation. Full standard and PostgreSQL-enabled gates pass, or exact unavailable limitations remain recorded.	Complete

Slice 2T2 completion record: bp3 Company identity now validates and persists one normalized named accounting time-zone id. New startup-company entry shows the system named zone as an editable value rather than storing a fixed offset. Shared BusinessTime resolution converts inclusive company-local dates to a half-open UTC interval, rejects unavailable, invalid, nonexistent, or ambiguous boundaries, and preserves exclusive-end membership. Inventory and Finance now reuse that resolver and hold a source cutoff zone that would override the company accounting zone. Migration 202608020001 backfills existing launch data to UTC, adds the required company column, and advances company backup to company-snapshot-v21 / bp3-schema-202608020001; restart and replacement restore preserve a non-UTC zone. The full standard suite passed 1,229 tests with 101 expected PostgreSQL-gated skips, and the full PostgreSQL-enabled suite passed all 1,330 tests without failures or skips. Operational-location records, per-user display preferences, consolidation, currency translation, broad timestamp reformatting, and retroactive cutoff changes remain deferred under ADR 0033. Startup-scenario desktop UAT retest is again the next release acceptance action.

Step 3 startup-scenario UAT remediation

Startup-scenario desktop testing originally exposed missing company entry and bootstrap plus an unrecoverable starter-chart collision path. Work units 3R1 through 3R3 implemented the bounded repairs. On 2026-08-03, the user reran UAT-0001 and UAT-0002; both findings are resolved, and the database-backed journal entry persists after restart. Step 3 is complete. The broader end-to-end new-company startup path remains Step 15A0 release-readiness acceptance.

Work unit	Outcome and included work	Truth gate and exclusions	Verification and acceptance	Status
3R1. First-run company entry and administrator bootstrap	After resolving the desktop operating-system actor, allow the user to create a company with an application-generated stable identity or select an existing company available to that actor. Establish company context only after that choice, then construct company-scoped workflows. For a new production company, visibly confirm and invoke the existing minimum production-administrator bootstrap before protected setup continues. Route a startup-scenario company into ordinary Setup & Onboarding without a source-system connection or `CompanyConversionRun`.	Governed by the Company Identity and Context Contract, ADR 0011, and ADR 0019. Preserve attributable creation, company-scoped authorization and audit, idempotent/conflict-visible bootstrap, development/test-only seed boundaries, and separate permission-readiness acknowledgement. Excludes broad user administration, final role templates, support access, and QBO conversion UI.	Application and domain tests cover create, select, cancel, invalid or retired company, actor/company isolation, production versus development/test boundaries, bootstrap replay and conflicting authority, and construction of workflows only after context resolution. PostgreSQL tests prove restart durability and company isolation. A production-mode desktop user can create and enter a new startup company without an externally supplied company id, hidden grant, or conversion run.	Complete
3R2. Starter-chart collision review and readiness repair	Preflight starter-chart installation, present every existing-code collision for review, apply only an explicitly accepted canonical resolution, and keep chart and account-role readiness visibly incomplete or blocked until installation or an allowed reviewed-chart alternative is complete. Preserve stable account identity, company scope, account history, authorization, audit, and repeatable installation.	Governed by the amended ADR 0023 and canonical Starter Chart Installation Contract. Account origin and reviewed starter-chart adoption are distinct; compatibility uses explicit semantic properties, and adoption preserves source and history. Excludes QBO mapping, Dolibarr crosswalk adoption, silent renumbering, deletion, and database reset as a workflow.	Domain, application, and PostgreSQL tests cover no-collision installation; compatible and incompatible collisions under the accepted truth; cancel and retry; partial or interrupted work; exact replay and changed-meaning conflict; company isolation; history and audit; and readiness invalidation. UAT-0001 closed through the desktop UI with no database intervention on 2026-08-03.	Complete
3R3. Ledger freshness and concise source presentation	Treat Ledger navigation as an explicit reload, refresh its posted-entry register after successful manual or Summary posting, and remove the redundant `Source ID` display column when `Source Document` already presents that human-facing identifier.	Presentation-only repair governed by the existing Journal Entry and Source Document contracts. Canonical source type, source id, durable Source Document identity, posting, authorization, audit, persistence, and drilldown remain unchanged. It does not add a separate Refresh button.	Regression coverage proves navigation always reloads, successful manual and Summary paths refresh, the obsolete one-time guard is absent, and the Ledger register no longer renders a duplicate `Source ID` column while retaining Source and Source Document. UAT-0002 passed on 2026-08-03, including database-backed persistence after restart.	Complete

Work unit 3R1 completion record

The desktop now resolves the operating-system actor before company context and shows an entry surface for selecting an actor-assigned company or creating a startup company with an application-generated stable id. Production creation persists the company without a conversion run, survives interruption as a creator-owned pending-bootstrap option, and requires visible confirmation before the existing ProductionAdminBootstrapService establishes its minimum ordinary role, permissions, assignment, and value-free audit evidence. Cancellation retains the company for exact bootstrap resume. Development/test mode remains limited to its explicit seeded identity and company.

Company-scoped onboarding, workbench, fiscal-calendar, ledger, and reporting workflows are constructed only after authorized selection or successful bootstrap. Optional company configuration is preselection only and no longer a production first-run prerequisite. Bootstrap authority remains distinct from permission-readiness acknowledgement and does not grant accounting, posting, close, restore, export, conversion, or support-access authority.

Focused company-entry, context, state, and UI tests passed 25 tests with one expected PostgreSQL-gated skip. The full standard solution passed 1,211 tests with 99 expected PostgreSQL-gated skips. The full PostgreSQL-enabled solution passed all 1,310 tests without failures or skips against an isolated database; the ordinary user-test database was not reset or used by the test suite. Derived user and developer guidance now matches the entry flow.

Work unit 3R1 is complete. The 3R2 truth gate is cleared by the amended ADR 0023 and canonical Starter Chart Installation Contract. The later desktop UAT closure is recorded with 3R2 and 3R3 below.

Work unit 3R2 implementation handoff

The application now persists complete company-scoped collision reviews, compares explicit account and role properties, and exposes Adopt Compatible, Keep Existing Chart, and Cancel Review actions in Setup & Onboarding. Reviewed adoption preserves account id, source, presentation, and history while assigning immutable standard identity. Pending reviews block chart and role readiness; completed resolutions make older acknowledgements stale. Exact replay, changed meaning, interruption recovery, authorization, audit, company isolation, PostgreSQL restart, and company backup/restore are covered.

The final full standard solution passed 1,219 tests with 101 expected PostgreSQL-gated skips. Before the final non-persistence boundary test was added, the full PostgreSQL-enabled solution passed all 1,319 tests without failures or skips against an isolated disposable database; the affected PostgreSQL adoption, readiness, and backup/restore tests also passed after the final persistence changes. The ordinary development and user-test database was not reset or used by the test suite.

UAT-0001 passed desktop retest on 2026-08-03. The reported company-selection, permission-readiness, and collision-resolution issues no longer reproduce. Work unit 3R2 and the reopened Step 3 remediation are complete. The broader new-company startup path continues separately under Step 15A0.

Work unit 3R3 completion record

Ledger no longer caches its first loaded row set for the lifetime of the desktop window. Each Ledger navigation reloads posted entries, and successful manual, Summary approve-and-post, and Summary post paths refresh the same register immediately. The Ledger presentation also removes the duplicate Source ID column while retaining Source and Source Document. Canonical source fields remain stored and available to supporting registers and drilldown. The patch does not alter ledger persistence, central posting, authorization, audit, or journal-entry identity, and it adds no separate Refresh button.

The focused Ledger/manual-posting regression selection passed 20 tests; after the related column change, the focused Ledger selection passed 16 tests. The full application test project passed 219 tests with three expected PostgreSQL-gated skips. UAT-0002 passed desktop retest on 2026-08-03: the new entry appeared without restarting BooksPlus and remained present in the database after restart. Work unit 3R3 is complete.

Step 15 release readiness and production delivery

Goal: turn the completed domain and application-service baseline into a supported BooksPlus 1.0 desktop release without reopening deferred external automation.

Step 15 is intentionally ordered so broad functional UAT can continue with a controlled test actor before final production roles and permissions add setup friction. Production security remains a release gate and is not weakened or skipped; it is sequenced after the workflows it must protect are visible and stable.

Verified presentation and delivery baseline

Repository inspection on 2026-08-03 establishes this starting point:

Area	Current evidence	Release gap
Setup & Onboarding	First-run company entry, administrator bootstrap, setup actions, permissions acknowledgement, production-mode company reselection, and readiness-driven Guided Setup are present. UAT-0001 through UAT-0005 are resolved. The desktop covers all three governed chart paths, required-role resolution, both opening-balance dispositions, and the 15A7 completion summary and revalidated Enter Current Period handoff. Setup remains available and later invalidation withholds the handoff without deleting prior evidence. The startup guide is aligned to those surfaces. Production UAT exposed UAT-0006: bootstrap does not authorize fiscal-calendar draft creation and no production permission-administration UI exists.	Step 15A functional acceptance is complete. Resolve production protected-action provisioning in 15G and rerun the complete production path in 15K.
Ledger review	Ledger navigation reloads persisted posted entries and UAT-0002 confirms database persistence. Slice 15R1 groups each posted entry under a heading and renders its ordered lines with stacked account code/name, description, debit, and credit. Production-mode UAT-0004 passed on 2026-08-03, including debit-first display and the Details drilldown. The operating guide is aligned through 15U3.	No remaining 15R1 release gap. Period and company currency remain entry-heading fields while persisted line currency remains unchanged.
File intake, Summary workflows, and 1099 support	Provider-agnostic file intake, all four domain Summary services, contractor support, filing handoff, recipient statements, and correction orchestration are implemented behind application services. The generic Summary Transaction Desk is visible.	The desktop window does not wire the domain-specific intake, Sales, Purchasing/1099, Inventory, or Finance workflows. Inventory all active workflow surfaces and add bounded UI slices without moving accounting meaning into presentation code.
Duplicate and correction handling	Provider-agnostic intake owns replay, conflict, and duplicate review; `AccountingCorrectionWorkflowService` and `AccountingCorrectionReviewWorkflow` own protected adjustment/reversal preparation, posting, and review.	The correction review workflow and duplicate/conflict decisions are not wired into desktop navigation. Do not duplicate their domain logic in UI code.
Close	Canonical Close preparation, durable runs, waivers, approval, protected soft/hard finalization, reopen, and `CloseReviewWorkflow` are implemented and tested.	The desktop still shows legacy fiscal-calendar Soft Close, Hard Close, and Reopen buttons. Replace those controls with the canonical CloseRun path and expose review/history.
Reporting	Trial balance is visible. Canonical trial balance, balance sheet, income statement, immutable ReportRuns, currentness, and `ReportingReviewWorkflow` are implemented. The live trial-balance guide is aligned through 15U3.	Balance sheet, income statement, capture, persisted-run review, and drilldown are not wired into desktop navigation; trial balance still needs UAT.
Adjusting and closing entries	Protected adjustment posting exists through Corrections; ordinary manual journal entry is visible.	Present adjusting entries through the Correction workflow. Canonical truth defers automated closing entries; do not imply a generator exists. UAT should prove that required manual entries post through Accounting before Close is re-evaluated.
QBO controlled cutover	The qualified fixture and live-capture paths, mapping, controls, approval, application, recovery, and backup behavior are implemented behind application services.	No supported desktop conversion surface or replacement-scenario UAT path is visible. Live credential-broker deployment remains a narrow operational boundary to qualify.
Production users and permissions	OS identity, internal actors, minimum production-administrator bootstrap, protected-action registry, policy checks, audit, and development/test isolation exist.	Full production user administration, final role templates/matrix, identity mapping changes, disable/retire, assignment review, and administrator-recovery behavior remain deferred in binding security truth.
Deployment and customer delivery	Managed-local PostgreSQL, migrations, encryption, company backup/restore services, and high-level sysadmin pages exist.	There is no qualified customer installer/updater, database-service lifecycle, license/copy-protection design, customer-doc build, or clean-machine release qualification.

Step 15A Setup & Onboarding slices

The first release-readiness area needs more than a single UAT checkbox. Code inspection confirms that company creation/bootstrap, readiness calculation, starter-chart collision resolution, opening-balance posting, chart import, role assignment, and permission review services exist, but several supported paths are not available through the desktop. The slices below keep company context, readiness meaning, chart work, account roles, opening posting, and acceptance independently reviewable.

Slice	Outcome and user value	Governing truth, dependencies, and exclusions	Verification and acceptance	Status
15A0. Close current UAT and qualify the new-company path	Preserve the resolved UAT-0001, UAT-0002, and UAT-0003 evidence, then complete one new-company startup path through the first successful posting.	Uses the current Company, bootstrap, starter-chart, period, setup-readiness, and posting behavior. Do not reset the user-test database, substitute QBO conversion, or treat automated tests as desktop acceptance.	UAT-0001 proves collision review, adoption/retain/cancel, chart and role readiness, and a recoverable next action. UAT-0002 proves Ledger freshness and database persistence. UAT-0003 proves production company creation, return, reselection, and state isolation. Production-mode desktop UAT completed the remaining fiscal setup, chart/roles, permissions review, opening-balance disposition, and first-posting path on 2026-08-03.	Complete
15A1. Company-context exit, reselection, and isolation	Add a visible Return to Company Selection action after entry. Let an authorized actor leave the current workspace, select another available company, or create a new startup company without deleting or changing the first company. Reconstruct every company-scoped workflow and reload all visible state for the new context.	Governed by the Company Identity and Context Contract, ADR 0011, ADR 0019, and UX principles. Reuse the existing authorized company list and bootstrap flow. Excludes cross-company copy, company deletion/retirement, final user administration, and persistence of unfinished form input. Warn before discarding unsaved presentation input.	Desktop and application tests cover existing-company entry, return, startup creation, pending-bootstrap cancel/resume, repeated switching, retired/unassigned rejection, cleared registers/forms/drilldown, and absence of prior-company rows or commands. PostgreSQL coverage proves no company mutation or authorization crossover. Production-mode desktop UAT closed UAT-0003 on 2026-08-03.	Complete
15A2. Canonical Setup readiness contract	Define one canonical Setup & Onboarding contract for readiness-item identity, objective versus acknowledged completion, review subject and evidence, staleness/invalidation, blocked behavior, ordering, completion, and later re-entry. Resolve the current gap where responsibilities and policy-baseline acknowledgements have no canonical reviewed-content boundary.	Truth gate: this slice belongs in `bp3-wiki` before UI or domain changes depend on new setup meaning. It composes existing Company, Financial Period, Starter Chart, Account Role, Security, opening-posting, and audit owners. It does not settle final production role templates, support access, QBO conversion, or implementation-services practice management.	The canonical Setup Readiness Contract provides one durable source for all ten readiness items, exact reviewed subjects, currentness and invalidation, blocked recovery, completion, and re-entry. Strict wiki verification passes with no conflict against ADR 0020 or the composed contracts.	Complete
15A3. Guided setup state and permission-review surface	Make the readiness-driven next action the primary guided action; show prerequisite, blocker/warning, reviewed subject, evidence, and recovery action before accepting acknowledgement. Record responsibilities and policy subjects through the initial-release external-reference model. Expose the existing permission review of roles, company assignments, protected-action coverage, reason/step-up flags, and development/test-only data.	Depends on 15A2. Uses versioned external evidence for responsibility and policy subjects and `PermissionSetupReviewService` for the permission subject; BooksPlus does not author or approve the referenced business documents. Does not create or edit production actors, roles, permissions, or assignments. Bootstrap authority and permission-readiness acknowledgement remain distinct. Final production security administration stays in 15G.	Tests cover every readiness transition, stale acknowledgement, denied action, missing protected-action coverage, production versus development/test labeling, navigation reload, and business-language recovery guidance. A user cannot mark a review complete without seeing the governed subject.	Complete
15A4. Chart acquisition and review surface	Present the supported chart paths—starter-chart install, reviewed existing chart, and staged CSV chart import—through one onboarding choice. Show account code/name/type/status/source, import issues and preview, complete collision review, and the exact chart result before acknowledgement.	Depends on 15A2 and uses the Chart Import, Starter Chart Installation, Account, and chart-maintenance authorities. No silent renumbering, deletion, source rewriting, direct database repair, QBO mapping, or Dolibarr crosswalk adoption.	Tests cover starter install/replay, valid and blocked import, existing-chart selection, compatible/incompatible collisions, cancel/retry, changed-meaning conflict, audit, restart, and company isolation. Chart review acknowledgement is unavailable until the selected path has a reviewable result and no pending collision.	Complete
15A5. Account-role resolution and review surface	Show every required launch role, current same-company assignment, eligibility/status, singleton conflicts, and affected workflow readiness. Allow authorized assignment through the existing role service, then capture review only when every required role is valid.	Depends on 15A4. Governed by the Account Role and Account contracts. Role assignment never changes account identity or classifies accounts from number/name alone. Excludes optional future workflow roles and final security role templates.	Tests cover complete starter assignments, retained/imported charts with missing roles, eligible assignment, inactive/wrong-company/non-posting/duplicate rejection, stale review after change, audit, restart, and a clear next action for every blocker.	Complete
15A5C. Controlled-conversion Setup review pause	Enforce exact chart invalidation for every material account change. After a conversion durably applies its chart step, leave the run `applying` and return a blocked recovery result until the exact chart and required roles are reviewed through ordinary Setup; exact resume then posts opening balances once.	Governed by ADR 0035, the Setup Readiness Contract, and the Company Conversion Run Contract. Do not manufacture acknowledgements, bypass opening prerequisites, recommit the chart, add a lifecycle status, or expose QBO conversion in desktop navigation.	Tests prove chart and dependent-role staleness, blocked audit and recovery guidance, no premature opening entry, same-command resume, exact replay, restart, company isolation, single chart commit, and single opening posting.	Complete
15A6. Opening-balance entry and disposition surface	From the onboarding next action, let the user either prepare/review/post balanced opening entries through the existing protected opening-balance service or explicitly mark opening balances not required. Show source evidence, posting date/period, lines, preview, result, duplicate/retry conflict, and correction guidance.	Depends on an open first period and valid chart/roles. Uses central Accounting and existing opening-balance review ownership. No hidden balance edits, direct ledger writes, silent replacement, QBO conversion, or special correction path. A posted error is corrected through Accounting Corrections. Ordinary opening posting retains ADR 0015's no-idempotency-key boundary; the desktop must not claim exact replay.	Application and domain tests cover balanced post, imbalance, inactive/wrong-company account, currency/period/evidence/authorization failures, changed-draft re-review, duplicate/retry conflict without a second entry, interrupted-result inspection, readiness completion, and durable result identifiers. Existing central PostgreSQL posting and company-backup coverage governs restart, company isolation, journal/source/audit links, and backup/restore; 15A6 adds no persistence model.	Complete
15A7. Onboarding completion handoff and regression UAT	When every governed readiness item is complete, present a concise setup summary and explicit Enter Current Period action while keeping Setup available for later review. Preserve completed evidence and show any later invalidation rather than silently retaining Complete.	Depends on 15A1 through 15A6. Completion does not grant permissions, post another entry, close a period, start conversion, or hide unresolved blockers. Derived company-setup guidance must match the final desktop flow. Production authorization is separately gated by UAT-0006, 15G, and 15K.	End-to-end tests cover new company with no opening balances, new company with posted opening balances, retained/imported chart paths, interruption/resume, post-completion re-entry, invalidation, and first current-period posting. Development-mode desktop UAT-0005 passed on 2026-08-13 without database intervention; it is not production authorization evidence.	Complete

15A0 progress record: on 2026-08-03, the original UAT-0001 collision and permission-readiness defects and UAT-0002 Ledger-refresh defect passed desktop retest; the posted journal entry remained in the database after restart. The same acceptance cycle exposed UAT-0003: after entering the default company, the user cannot return to company selection to create or enter another company. Slice 15A1 resolved that limitation and passed production-mode desktop retest. The remaining 15A0 production path then passed through fiscal setup, chart/role readiness, permissions review, opening-balance disposition, and first successful posting on 2026-08-03. Slice 15A0 is complete.

15A1 implementation record: the desktop workspace now exposes an explicitly confirmed Return to Company Selection action. Confirmation replaces the bound presentation state, clears direct company-scoped inputs and selections, and reloads the authorized company list without changing saved company data. Every entry constructs fresh company-scoped workflows and reloads Setup. Focused verification passed 27 tests with two expected PostgreSQL-gated skips; four targeted tests passed against an isolated PostgreSQL database; and the full solution passed 1,234 tests with 102 expected PostgreSQL-gated skips. UAT-0003 passed production-mode desktop retest on 2026-08-03: production startup-company creation and bootstrap, workspace entry, confirmed return, and subsequent company creation or authorized reselection all succeeded without a database reset. Slice 15A1 is complete.

Slices 15A0 through 15A7, corrective slice 15A5C, 15R1, and 15U1 through 15U3 are complete. Development-mode UAT-0005 passed on 2026-08-13 and closes Step 15A functional acceptance. UAT-0006 separately preserves production authorization as a release gate owned by 15G and 15K.

15A3 implementation record: the desktop Setup surface now replaces the grid of independent acknowledgement buttons with one readiness-ordered primary action. It displays the first governed subject, prerequisite, warning or stale reason, acknowledgement evidence, and recovery action before the user can continue. Responsibility review records five named assignments plus a versioned external evidence reference; policy review records a versioned business-approved external reference and displays its required coverage. Unassigned responsibilities cannot be acknowledged. Setup acknowledgements now preserve the subject type, reference, version, deterministic fingerprint, business-facing fields, assembly time, and governing references through the new 202608130000_add_setup_review_subjects.sql migration. Reporting-currency and permission subjects are recomputed for currentness, and permission changes make prior evidence stale without deleting it. Permission review displays same-company actor-role assignments, every role and permission, every registered protected action, covering roles and assigned actors, reason and step-up flags, missing coverage, and development/test-only labels. It does not create or edit production security data. Chart acquisition and exact chart invalidation were assigned to 15A4; account-role repair and exact assignment invalidation were assigned to 15A5. The warning-free solution build passed, and the full solution passed 1,240 tests with 102 expected PostgreSQL-gated skips. PostgreSQL tests were not run against the preserved UAT database because their fixture reset truncates application data.

15A4 implementation record: Guided Setup now presents the starter-chart, active-current-chart, and staged CSV paths together. CSV staging preserves and reloads the source fingerprint, normalized account rows, actor and time, and field-level warnings or blocking errors. The desktop shows code, name, type, normal balance, status, imported source meaning, and posting eligibility before commit; only a valid displayed batch can be committed. The existing governed chart-import service performs account creation, history, authorization, audit, duplicate-source handling, and company isolation. Starter installation keeps its all-at-once collision preflight and explicit adopt, retain, cancel, retry, replay, and changed-meaning guards. The exact active chart acknowledgement now includes normal balance and posting eligibility and is rejected while the latest selected CSV preview remains staged or starter collisions remain pending. Focused verification passed 34 domain and desktop tests, and the full solution passed 1,245 tests with 102 expected PostgreSQL-gated skips. Existing PostgreSQL chart-import and collision-review tests cover durable rows, issues, commit results, restart, and company scope when the isolated reset-enabled test database is supplied; they were not run against the preserved UAT database. The derived chart and company-setup guides now document the visible paths and kept account-role repair unavailable at that slice boundary. Slice 15A4 is complete.

15A5 implementation record: Guided Setup now lists all nine required launch roles with their stable key, required-singleton cardinality, current account code/name/identity, account status, posting eligibility, and exact blocker. The assignment panel offers only active same-company posting accounts with direct posting allowed and requires a reason before calling the existing protected AssignLaunchRoleAsync path. Missing and duplicate roles can be assigned or replaced without changing account identity or inferring meaning from account code, name, or type; old assignments remain in account history and the chart-change audit. Readiness now requires chart_ready to be complete, rejects missing, duplicate, wrong-company, inactive, retired, non-posting, and indirect-posting targets, recomputes the exact role-subject fingerprint, and disables acknowledgement until every required role is valid. The existing PostgreSQL singleton replacement test now explicitly reloads through a new repository instance. Focused verification passed 70 setup and desktop tests. The full standard solution passed 1,250 tests with 102 expected PostgreSQL-gated skips. The derived chart and company-setup guides document the visible resolution and recovery path while keeping production security roles separate. Slice 15A5 is complete; 15A6 is the sole next active slice.

15A5C completion record: accepted ADR 0035 makes the durable conversion chart step an explicit Setup review pause. Exact chart-subject comparison now makes material account changes stale, and the account-role subject is causally bound to that chart fingerprint. Conversion apply persists its chart step, returns a value-free audited Blocked result with the incomplete Setup item ids, and leaves the run applying. After ordinary exact chart and required-role review, the same application and command resume without recommitting the chart; an interrupted opening post reuses its durable journal and Source Document on the next resume. Focused verification passed 47 tests. The full standard solution passed 1,251 tests with 102 expected PostgreSQL-gated skips. Existing PostgreSQL coverage reloads an applying conversion with its single persisted chart step, so no schema change was required. Slice 15A5C is complete; 15A6 is again the sole next active slice.

15A6 completion record: Guided Setup now presents two explicit opening-balance dispositions. The posting path accepts a posting date, source-document date, unique source identifier, evidence reference, explanation, and a variable number of account lines. Review recomputes current prerequisites, same-company eligible accounts, company currency, routine-period eligibility, line meaning, balanced totals, and prior opening source identifiers; only that exact reviewed draft can be posted through OpeningBalanceSetupReviewService and central Accounting. The desktop prevents concurrent submission, displays changed-draft and duplicate-source outcomes without creating a second entry, reloads existing opening entries, and shows journal, Source Document, and audit identifiers with append-only correction guidance. The not-required path now requires an explicit business reason and evidence reference. ADR 0015's no-idempotency-key rule supersedes the slice's former exact-replay wording, so interrupted recovery is inspection of the durable result followed by a deliberate retry only when no posted source exists. No schema or PostgreSQL repository changed. Focused opening service verification passed 9 domain tests; application verification passed 239 tests with 4 expected PostgreSQL-gated skips; and the full standard solution passed 1,255 tests with 102 expected PostgreSQL-gated skips. Existing central PostgreSQL posting, source identity, audit, company isolation, and backup coverage remains applicable but was not run against the preserved UAT database because its fixtures reset application data. The derived startup and company-setup guides now match the visible paths. Slice 15A6 is complete; 15A7 became the next active slice.

15A7 implementation record: Setup now derives a completion-handoff state from the same recomputed OnboardingCompletionState that owns overall readiness. When all ten items are current, the existing concise fiscal-calendar, chart, permissions, and opening-balance summary is paired with an explicit Enter Current Period action and a reminder that Setup remains available. The action reloads Setup immediately before navigation; if any governed subject became stale, it withholds the handoff, preserves prior evidence, and shows the first incomplete item and recovery action. The handoff itself grants no permission, posts no entry, changes no period, starts no conversion, and writes no setup fact. Regression covers both opening dispositions, starter/retained/imported chart paths, workflow reconstruction after interruption or restart, later permission-subject invalidation, preserved stale evidence, Current Period readiness, and the first supported manual posting path. Focused application verification passed 55 tests, and the full standard solution passed 1,259 tests with 102 expected PostgreSQL-gated skips. No schema, canonical truth, or bp3-doli change was required. The user guide matches the visible handoff, and UAT-0005 passed the final no-database-intervention development-mode functional walkthrough on 2026-08-13 and closes 15A7 and Step 15A. To reduce repetitive local UAT entry, explicit development/test mode defaults each empty responsible-person input to the signed-on actor display name while preserving deliberate evidence reference, version, and typed assignments. The responsibility step now keeps its labeled inputs and acknowledgement action together immediately after the blocker card and hides its duplicated subject rows and distant generic action; other Guided Setup steps and production defaults are unchanged. UAT-0006 owns the later production authorization gate.

15R1 implementation record: the Ledger now projects each immutable posted entry as an entry heading with journal-entry number, posting date, financial- period label, company currency, source reference, explanation, and balanced totals. Ordered journal lines appear beneath the heading with line number, stacked account code and name, description, debit, and credit. Missing account metadata remains visible as Account unavailable plus the stable account id. Debit lines display before credit lines while their persisted line numbers stay unchanged. A compact Details action at the right of each entry heading loads the selected immutable entry in the existing Current Period Support Detail drilldown, including its source-document and audit evidence. The change does not alter persisted entries, line currency, posting, period resolution, source evidence, company isolation, or audit. Focused application verification passed 39 tests, and the full solution passed 1,236 tests with 102 expected PostgreSQL-gated skips. PostgreSQL-enabled tests were not run against the preserved UAT database because their fixture reset truncates application data.

Production-mode desktop UAT-0004 passed on 2026-08-03. The accepted Ledger surface shows account code and name, debit detail before credit detail without renumbering persisted lines, and a compact Details action that opens the existing drilldown. Slice 15R1 and UAT-0004 are complete.

15A2 completion record: the canonical Setup Readiness Contract defines the stable ten-item readiness registry, objective and acknowledged completion modes, exact review subjects and evidence, deterministic currentness and invalidation, blockers and recovery actions, prerequisite order, overall completion, and later re-entry. It gives responsibilities and policy-baseline review durable content boundaries, keeps acknowledgements from overriding governing facts or permissions, and leaves final production role templates, support access, QBO conversion, and practice management outside the slice. The contract is linked from the implementation index and relevant derived user guidance. Slice 15A2 is complete.

bp3-wiki owns the completed 15A2 contract and derived documentation alignment. bp3 owns 15A3 through 15A7 application, presentation, persistence, and test work. Step 15A has no bp3-doli handoff. Its main risks are stale company-scoped UI state during reselection, acknowledgements that outrun the facts reviewed, and opening- balance UI code bypassing protected central posting; the slice boundaries and acceptance gates above address those risks directly.

Step 15B0 active-workflow presentation inventory

Repository inspection on 2026-08-13 closes this presentation gate without adding executable workflow actions. WorkflowNavigationCatalog records the ten accepted initial-release areas with a stable id, exact ADR 0020 family placement, group, label, and active taxonomy status. The existing Setup, Current Period, Fiscal Calendar, and Ledger buttons carry catalog ids; no service-only area receives a desktop entry point. Here active means accepted initial-release scope, not present desktop availability.

ADR 0020 has one explicit taxonomy irregularity that 15B0 does not silently reconcile: Reporting's Family placement is Ledger and close review support, which is not one of the four named workflow families. The catalog preserves that exact accepted value. Before rendering a full family tree, 15D must amend ADR 0020 or accept a replacement decision that either assigns Reporting to a named family or defines support placement separately.

Active taxonomy-node matrix

This matrix covers every ADR 0020 node marked active, including nodes active only through a bounded owner. Listed permissions are the existing protected policy families; an omitted policy never authorizes presentation code to bypass its owning service.

Family / group / active label	Implemented owner and desktop entry	Blocked outcome, review/register, and drilldown	Permission and UAT handoff
Financial Control / Setup & Onboarding / Setup & Onboarding	Company entry, onboarding, calendar, chart, role, permission, opening-balance, and completion workflows; Setup and Fiscal Calendar are visible.	Guided Setup shows prerequisites, stale/blocked state, reviewed subject, recovery, completion summary, and posted-opening-entry drilldown.	Setup/calendar/chart/policy/posting actions; UAT-0001, UAT-0003, and UAT-0005 passed. UAT-0006 remains 15G/15K.
Financial Control / Accounting policy / Accounting policy	`CompanySetupReviewService`, `SetupReadinessService`, and policy acknowledgement are visible in Guided Setup; there is no general policy editor.	External reference/version, governed subject, and staleness are visible; missing or changed evidence blocks completion.	`accounting_policy.change`; UAT-0005 functionally passed, production administration remains 15G.
Financial Control / Approval controls / Approval controls	`PermissionSetupReviewService`, `ProtectedActionRegistry`, and protected outcomes are implemented; Setup exposes review, not administration.	Review shows roles, actors, coverage, reason/step-up flags, missing coverage, and development-only labels.	All registered actions; development UAT-0005 passed and production UAT-0006 remains open.
Operating Transaction Capture / Current Period Workbench / Current Period Workbench	`CurrentPeriodWorkbenchWorkflow`, Summary desk, manual-entry, posted-register, exception, and drilldown workflows; Current Period is visible.	Existing Summary batch, manual entry, posted entries, sources, exceptions, and Support Detail are visible. File creation and domain fact entry are absent.	Summary, posting, source, and report-view actions as invoked; retain regressions and add the full path to 15F.
Operating Transaction Capture / General expenses / General expenses through Purchasing and Payables Summary	Purchasing preparation/workflow and shared Summary services are implemented; no entry.	Preparation issues, lifecycle blockers, batch result, and evidence are service-only; no register or drilldown.	Summary actions; 15B1 then 15F.
Operating Transaction Capture / Revenue & receivables / Revenue & receivables through Sales and Receivables Summary	Income preparation/workflow and shared Summary services are implemented; no entry.	Preparation issues, batch lifecycle, source evidence, and posting result are service-only.	Summary actions; 15B1 after 15B0T, then 15F.
Revenue & receivables / Sales tax generated from sales activity / summarized income and bounded ADR 0034 control	Capability profiles, owned tax results, Sales preparation, durable return control, protected remittance posting, the exact non-posting Finance match, and all five Close checks are implemented. Sales Tax exposes the bounded control register and actions; general Sales intake remains unavailable until 15B1.	The register distinguishes seller and facilitator amounts, guides the filing/remittance chain, displays blockers and exact evidence, links posted entries and Finance evidence, and previews the five Close checks.	15B0T1-T5 are complete; 15B0T6 implementation is complete and functional UAT is pending.
Operating Transaction Capture / Purchasing & payables / Purchasing & payables through Purchasing and Payables Summary	Purchasing and bounded contractor/1099 services plus shared Summary owners are implemented; no entry.	Facts, blockers, filing support, recipient statements, and evidence are service-only.	Summary and contractor/information-return actions; split presentation at owning services in 15B1, then 15F.
Operating Transaction Capture / Inventory & production / Inventory & production through Inventory Summary	Period-summary, purchase-price-variance, standard-cost-revision, and Inventory workflow services are implemented; no entry.	Preparation, lifecycle, persisted outcome, and evidence are service-only.	Summary actions; 15B1 then 15F.
Operating Transaction Capture / Cash & banking / Cash & banking through Banking and Finance Summary	Finance preparation/workflow and non-posting-result review are implemented; no entry.	Posting/non-posting outcomes, blockers, allocations, evidence, and closing balances are service-only.	Summary actions; 15B1 then 15F.
Cash & banking / Reconciliation / Reconciliation through Banking and Finance Summary	The same Finance owners implement the bounded reconciliation result; no entry.	Matched, unmatched, warning, blocked, and source-result review lack a register and drilldown.	Finance/Summary boundary; 15B1 then 15F.
Cash & banking / Tax payments and remittances / bounded ADR 0034 remittance	Protected external-payment evidence, central remittance posting, and the Finance-owned exact non-posting match are exposed through Sales Tax.	Guided review records external evidence, posts the governed entry, records the exact Finance match, and links its supporting evidence; no payment is initiated.	15B0T4 is complete; 15B0T6 functional UAT is pending.
Close Processing / Period Close / Period Close	`ClosePreparationService`, `CloseWorkflowService`, repositories, audit, and `CloseReviewWorkflow` are implemented. Visible calendar toggles are not canonical `CloseRun`.	Checks, waivers, approval, finalization, reopen, history, stale/denied/failed review are service-only.	Close-run and period actions; 15C replaces legacy controls, then 15F.
Close Processing / Close report packs / Close report packs	Close coordination and persisted ReportRuns exist; no canonical Close entry exposes them.	Required report, currentness, missing/blocked pack, and source drilldown are not visible together.	Close/report actions; 15C consumes 15D and 15F tests integration.
Close Processing / Review adjustments / review through correction and posting controls	Correction preparation/workflow/app review and posting exist; no Corrections entry.	Protected readiness/posting and immutable chains are service-only; Current Period can show only the posted result.	Correction and reverse/adjust actions; 15B2 then 15F.
Close Processing / Manual close-period entries / ordinary posting and correction controls	Ordinary manual entry is visible; correction owners are service-only.	Validation, posting blockers, and posted-entry drilldown are visible; adjustment/reversal initiation and chain review are absent.	`journal_entry.post` plus correction actions; 15B2/15C/15F.
Correction & Conversion Controls / Opening balances / opening balances through Setup & Onboarding	Onboarding opening-balance workflow, central posting, review, and posted drilldown are visible in Setup.	Balanced review/post, not-required disposition, blockers, recovery, and result are visible; posted-error correction is unavailable.	Posting/source actions; UAT-0005 passed, correction handoff waits for 15B2.
Correction & Conversion Controls / Corrections / Corrections	Correction preparation, workflow, persistence, audit, and app review are implemented; no entry.	Blocked/ready/abandoned/posted results and immutable chains are service-only.	Correction and reverse/adjust actions; 15B2 then 15F.
Correction & Conversion Controls / Voids and reversals / voids and reversals through correction controls	Same correction owner; there is no separate void engine and no desktop action.	Target validation, readiness, authorization, result, and chain review are service-only.	Correction and reverse actions; 15B2 then 15F.
Correction & Conversion Controls / QBO controlled cutover / QBO controlled cutover	Connector/capture/mapping, conversion workflow, persistence/audit, backup, and fixture qualification are implemented; no entry.	Connection, capture, mapping, reconciliation, approval, apply, Setup pause, retry, and evidence are service-only.	QBO and conversion actions; 15E owns UI/qualification, 15F UAT, and the live broker remains a gate.

Implemented-service exposure inventory

The grouped inventory makes the service boundary exact without turning the roadmap into a permanent class catalog. Shared owners are listed once.

Area	Implemented service evidence	Exposure and owner
Setup	`CompanyEntryWorkflow`; onboarding, calendar, opening-balance, Setup-review/readiness/completion, chart, account-role, company, security, posting, and source-document owners.	Available; production administration remains 15G.
Current Period, intake, and shared Summary	Workbench, Summary desk, `AccountingImportWorkflow`, posting, manual-entry, register, exception, and drilldown workflows; import intake and Summary intake, preview, readiness, evidence-link, and posting services.	Workbench/manual/existing-batch paths available; file intake waits for 15B1 and duplicate/conflict decisions for 15B2.
Sales	`IncomeAccountingPreparationService`; `IncomeAccountingWorkflowService`; shared Summary owners.	Not exposed; 15B0T then 15B1 Sales.
Purchasing and 1099	Purchasing preparation/workflow; contractor support, treatment review, protected data, payer profile, support run, draft, filing, recipient statement; shared Summary owners.	Not exposed; separate owning-service sub-slices inside 15B1.
Inventory	Period-summary, purchase-price-variance, standard-cost-revision preparation; `InventoryAccountingWorkflowService`; shared Summary owners.	Not exposed; 15B1 Inventory.
Banking	Finance preparation/workflow; `FinanceNonPostingResultReviewService`; shared Summary owners.	Not exposed; 15B1 Banking.
Corrections and duplicate relationships	Correction preparation/workflow/app review; `AccountingEventRelationshipReviewService`; import replay/duplicate/conflict owners.	Not exposed; 15B2.
Close	Close preparation/workflow/app review, durable repositories, and audit.	Canonical path not exposed; 15C.
Reporting	`TrialBalanceWorkflow`; standard-report preparation; ReportRun capture/review; app reporting review.	Trial balance available in Ledger; remaining reports and ReportRuns wait for 15D.
QBO cutover	Connector, live-capture qualification, chart mapping, fixture/HTTP adapter, conversion workflow/repository/audit, and coordinated backup.	Not exposed; 15E.

Catalog tests verify ten unique workflow ids, accepted labels and placements, status metadata, and the absence of tags for unexposed areas; MainWindowStateTests continue to verify current paths. The inventory was cross-checked against application workflows, domain services, protected policies, repositories, and focused test classes. No schema, domain, posting, permission, or executable navigation behavior changed. The focused catalog and window-state selection passed 24 tests. The full solution passed 1,264 tests with 102 expected PostgreSQL-gated skips, and the strict wiki build passed.

15B0 is complete. Downstream boundaries are 15B0T sales-tax truth/contract/service/presentation; five independently reviewable 15B1 surfaces (file intake, Sales, Purchasing/1099, Inventory, Banking); 15B2 Corrections and duplicate review; 15C Close; 15D Reporting; and 15E QBO cutover.

Step 15B0T sales-tax accounting and remittance slices

ADR 0034 and the canonical Sales Tax Accounting and Remittance Contract govern this work. Slice 15B0T2 replaced the legacy tax-amount default in IncomeAccountingPreparationService with reviewed capability-profile and owned-result validation. Return-control, remittance, bank-link, Close, and desktop behavior remain unimplemented and retain their owning slices below.

Slice	Outcome and stable boundary	Dependencies, exclusions, and handoff	Verification and acceptance	Status
15B0T1. Canonical contract and dependent truth	Accept capability profiles, tax-result ownership and equations, seller/facilitator preparation, return control, reconciliation, protected external completion, remittance posting, Finance match, amendments, Close checks, Reporting boundary, audit, replay, backup ownership, and exclusions. Amend Sales, Finance, Close, Reporting, Source Documents, Security/Audit, Backup, and developer guidance only where the new contract consumes their owners.	`bp3-wiki` only. ADR 0034 governs. No schema, application code, provider adapter, filing transmission, payment initiation, or user procedure.	Contract is canonical; dependent binding pages link without contradiction; the current code conflict is explicit; strict wiki build passes.	Complete
15B0T2. Capability profile and Sales preparation foundation	Add provider-agnostic `SalesTaxCapabilityProfile` and `SalesTaxResult` domain behavior, exact ownership/control equations, jurisdiction-summary eligibility, and seller/facilitator Sales preview preparation. Preserve existing seller-owned behavior only when the new required fields and evidence validate.	Depends on T1. Owns domain models, preparation services, in-memory tests, and route isolation. Excludes durable return controls, remittance, Close, UI, and provider mappings. Existing tax-bearing requests without canonical ownership/profile meaning remain visibly held rather than defaulting to seller liability.	Tests cover seller-only, facilitator-only, mixed, accounting-only, filing-summary, profile effective dates/evidence, exact totals, replay meaning, and every held outcome.	Complete
15B0T3. Return-control service and persistence	Implement return-control identity/numbering, inclusions, immutable reconciliation snapshot, currentness, amendment linkage, filing approval/evidence, PostgreSQL repositories/migrations, protected actions/audit, concurrency/recovery, and complete company backup/restore catalog changes.	Depends on T2 accepted Sales results. Split from ledger mutation and Finance matching. No filing transmission, credentials, payment, desktop, or Close evaluator.	Domain, repository, PostgreSQL, schema-conformance, backup/restore, denial, replay, concurrency, interruption, and company-isolation tests pass.	Complete
15B0T4. Remittance posting and Finance match	Implement remittance preparation/approval, external-payment evidence, protected central posting, exact once-only result, and Finance-owned non-posting statement match with persistence, audit, recovery, and backup coverage.	Depends on T3 filed return controls. Central Accounting owns the journal entry; Finance owns only the later match. Excludes payment initiation, fees/penalties/interest/refund posting, automatic matching, and UI.	Tests prove approval/evidence ordering, period/account/currency checks, exact debit/credit, no duplicate posting, mismatched/duplicate bank-match holds, no match posting, interruption recovery, and restored state.	Complete
15B0T5. Close and review integration	Add the five versioned Close evaluators, fingerprint inputs, applicability/due-date behavior, support drilldown, and Reporting separation for sales-tax controls.	Depends on T3/T4. Close consumes owners and creates no tax fact, return, payment, match, or entry. Formal Reporting remains posted-ledger-only.	Close tests cover pass, blocker, not-applicable, allowed bank-match waiver, staleness, amendment, evidence supersession, due-date cutoff, and restored evaluation inputs.	Complete
15B0T6. Desktop control surface and UAT	Add discoverable Sales-tax return/remittance register, guided review/actions, blocked outcomes, evidence/result drilldown, posted-entry and Finance-match links, and Close handoff.	Depends on T2-T5. No native calculation, filing, payment initiation, provider API, operational subledger, or speculative tax advice. `bp3-doli` has no handoff in this boundary.	Application tests and focused PostgreSQL tests cover all visible states and permissions; development-mode functional UAT exercises seller-owned and facilitator-remitted accounting, filing evidence, remittance, bank match, amendment, and Close blockers before 15F.	Active — desktop implemented; functional UAT pending

15B0T2 completion record: provider-agnostic capability profiles, tax results, and filing-coverage summaries now validate company/source identity, effective dates, supported responsibility values, active same-company Source Document evidence, exact customer-charge and seller-receivable controls, original-event meaning, and jurisdiction eligibility. Sales preparation credits only seller- owned tax to tax.sales_tax_payable; facilitator or other statutory-collector tax remains non-ledger support and is excluded from seller receivable. Mixed summaries prepare from explicit components. Legacy tax-bearing requests and unsupported or inconsistent inputs remain held. This slice adds no persistence, return control, remittance, Close, desktop, or provider mapping.

15B0T3 completion record: accepted Sales-tax results now persist in company- scoped return controls with stable numbering and identity, exact inclusions, immutable reconciliation snapshots, currentness and amendment linkage, protected readiness and filing approval, external-filing evidence, status history, optimistic concurrency, replay recovery, and audit outcomes. The PostgreSQL schema and the then-current company-snapshot-v22 catalog preserve and atomically restore the complete T3 aggregate. This slice adds no remittance posting, payment initiation, Finance match, Close evaluator, desktop surface, or filing transmission.

15B0T4 completion record: positive approved remittances now use stable STR- numbering, protected approval, active external-payment evidence, eligible-period central posting, exact debit to the immutable Sales Tax Payable account and credit to the reviewed bank account, replay recovery, and reasoned prepared- state abandonment. Banking and Finance persists only an exact same-company, same-account, same-currency, same-amount statement match and creates no posting. PostgreSQL schema and company-snapshot-v23 preserve remittances, payment evidence, status history, Finance matches, numbering, journal and audit links. Payment initiation, automatic matching, fees, penalties, interest, discounts, refund posting, Close evaluation, and desktop presentation remain excluded.

15B0T5 completion record: ClosePreparationService now consumes a registered sales-tax evaluator and emits the five canonical versioned checks with exact company-time cutoff behavior, due-date visibility, the contract's four non-waivable boundaries, and the policy-controlled bank-match waiver boundary. The versioned evaluation fingerprint and immutable check snapshots preserve capability, result, return, remittance, ledger, evidence/supersession, Finance match, and statement-coverage references. Durable runs preserve the exact cutoff used by their preview and restore normalized statement-coverage inputs. Close remains read-only over these owners and formal Reporting remains posted- ledger-only. The full solution passed 1,293 tests with 103 expected PostgreSQL- gated skips.

15B0T6 implementation record: the desktop now exposes a Sales Tax workspace under the accepted Sales and receivables workflow family. It presents accepted seller-owned and facilitator-remitted results, return and remittance registers, actual currentness, one governed next action, held outcomes, exact evidence and accounting identifiers, posted-entry and Finance-evidence drilldowns, and the five canonical Close checks for the selected return's fiscal month. Filing and payment remain explicitly external. A production-unavailable development/test scenario installer creates persisted seller and facilitator facts and a staged return because the general Sales intake surface remains owned by 15B1; a second development action prepares a governed amendment after the original chain is complete. The remittance lifecycle now refreshes the completed return's currentness fingerprint after the expected payable posting, and Close evaluates the current accepted result in a correction chain rather than double-counting its replaced predecessor. The full solution passes 1,297 tests with 104 expected PostgreSQL-gated skips. The configured PostgreSQL test reset was not run during implementation because it truncates the configured application tables; run it only against an explicitly disposable test database. Functional desktop UAT remains required before this slice is complete.

The single next action is the 15B0T6 development-mode desktop UAT: install the provided scenario, complete the original external filing/remittance/Finance match chain, prepare and complete its zero-additional-remittance amendment, and confirm the five Close handoff checks and drilldowns.

Step 15U User-guide alignment

The user guide needs an early accuracy pass before it can serve as dependable product or marketing material. Repository inspection on 2026-08-13 confirms that the desktop exposes company selection and startup creation, the current Setup surface, Current Period Workbench and Summary Transaction Desk, manual journal posting, Ledger review and drilldown, fiscal-calendar controls, and a live trial balance. The canonical application workflows for import intake, Corrections, CloseRun review, full Reporting, the four domain Summary areas, and QBO conversion exist behind application or domain services but do not yet have supported desktop entry points. Service and test coverage is evidence of implemented behavior, not evidence that a user can perform the workflow.

The documentation update introduces no new product meaning. It is governed by the Vision, UX Principles, ADR 0020, the contracts cited by each page, and the current desktop application. In the guide, active must be explained as initial-release scope and must not be used as a synonym for available in this build.

Page assessment

Page and purpose	Governing truth	Verified state and significant drift	Disposition
`index.md` — guide entry and route map	Vision, UX Principles, ADR 0020	Available route map. It leads with the verified startup, current-period, Ledger, and trial-balance tasks and separates unavailable product scope.	Revised in 15U1 and 15U3; keep new task links gated by supported desktop entry points.
`getting-started.md` — shortest product path	Vision, Source Documents, Posting and Reversal, ADR 0020	Available. It follows the verified startup-to-manual-post, Ledger, and live trial-balance path and states the major unavailable workflows.	Revised in 15U1 through 15U3; keep it compact and link to detailed task pages.
`getting-organized.md` — pre-configuration business checklist	Vision, Setup Readiness, Roles and Permissions, and accounting truth	Available preparation guidance. The page now matches the five external-reference responsibility fields and policy coverage shown by Guided Setup. The retained role/action matrix and policy checklist are explicitly labeled non-authoritative examples requiring business and professional review.	Revised in 15U2; keep the examples outside the executable product path and do not promote them as role, permission, accounting, legal, or tax defaults.
`workflows.md` — release taxonomy and scope	ADRs 0020, 0021, 0024, 0025, 0028, 0029, 0032, and 0034	Available scope map. It distinguishes present desktop availability from implemented services, accepted scope, and deferred work, including the Ledger route added in 15U3.	Revised in 15U1 through 15U3; update only when verified availability changes.
`company-setup.md` — company entry and setup	Company, Setup Readiness, Financial Period, single-currency, bootstrap, security, chart-import, starter-chart, account-role, and business-time authorities	Available for the current startup path. The procedure follows company creation, bootstrap, reselection, governed subjects, calendar setup, all chart paths, required-role resolution, permission review, both opening dispositions, and the revalidated Current Period handoff.	Revised through 15A7; final production roles and QBO replacement remain explicit exclusions.
`chart-of-accounts.md` — chart acquisition and roles	Accounts, Account, Account Role, Chart Import, Starter Chart Installation, Setup Readiness, ADRs 0017 and 0023	Available for chart acquisition, exact chart review, and required launch-role resolution. Collision handling, durable import preview/commit, eligible account selection, audited singleton replacement, and exact role acknowledgement follow the desktop.	Revised through 15A5; keep optional future workflow roles and production security administration outside this surface.
`current-period-workbench.md` — current open-period work	Journal Entries, Source Documents, Posting and Reversal, Setup Readiness, Summary Accounting, ADR 0020	Available. The guide now covers period and setup prerequisites, two-line manual validation/posting, registers, exceptions, Support Detail, blocked recovery, and the Ledger handoff using exact desktop labels.	Revised in 15U3; keep unavailable domain entry, Corrections, and Close outside the ordinary manual path.
`accounting-imports-and-batches.md` — existing Summary batch review	Summary Accounting, Summary Batch, Source Documents, Posting, ADRs 0020, 0022, and 0026	Partially available. The guide now covers only existing-batch selection, review, the limited audited Add Line repair, derived next actions, posting, outcome, and recovery. File intake and duplicate/conflict decisions remain unavailable.	Revised and narrowed in 15U3; add intake procedures only after 15B1 and duplicate/conflict procedures only after 15B2.
`ledger-review.md` — posted entry and line review	Journal Entries, Posting, Source Documents, Account, single-currency authority	Available. The 15R1 page covers explicit reload, entry headings, debit-first lines with stable persisted numbers, Details drilldown, and immutable posted-history boundaries.	Added in 15U3; keep Corrections out until 15B2 exposes the governed path.
`income-accounting.md` — Sales and Receivables scope	Summary Accounting, ADRs 0021, 0022, 0024, 0034	Implemented but not exposed; sales-tax preparation is partially implemented behind services.	Remove from primary task navigation until 15B1; retain a short, explicitly unavailable scope description.
`expense-accounting.md` — Purchasing, Payables, and contractor scope	ADRs 0024 and 0025 and their contracts	Implemented but not exposed. Purchasing and 1099 services have no desktop entry point.	Remove from primary task navigation until its 15B1 sub-slice; retain only an honest scope boundary.
`inventory-accounting.md` — Inventory Summary scope	ADRs 0024, 0028, 0029 and Inventory Period Summary Fact Contract	Implemented but not exposed.	Remove from primary task navigation until its 15B1 sub-slice; retain only an honest scope boundary.
`banking-and-finance-summary.md` — Finance Summary scope	ADRs 0024, 0029, 0034 and Banking and Finance Summary Fact Contract	Implemented but not exposed, including the exact sales-tax remittance bank match.	Remove from primary task navigation until its 15B1 sub-slice; retain only an honest scope boundary.
`sales-tax-and-remittance.md` — responsibility and intended control	ADR 0034 and the canonical Sales Tax Accounting and Remittance Contract	Implemented behind services, not exposed. Sales preparation, return control, remittance posting, the Finance match, and all five Close checks exist, but no supported desktop procedure exists.	Keep out of active task navigation and retain only responsibility/availability boundaries until 15B0T6 exposes and qualifies the workflow.
`corrections.md` — reversal and adjustment orientation	Posting and Reversal, ADR 0020; missing direct citation to Accounting Correction Contract	Implemented but not exposed. The page is too small to be an operating guide.	Merge its current orientation into the scope map; restore a task guide with the Accounting Correction Contract when 15B2 exposes the workflow.
`period-close.md` — CloseRun procedure	Close, Financial Periods, Close Run Contract, ADR 0020	Implemented but not exposed. It describes the canonical CloseRun path, while the desktop exposes legacy direct fiscal-period Soft Close, Hard Close, and Reopen controls. The page is not a usable guide for the current window.	Keep out of active task navigation until 15C replaces the legacy controls; do not document the legacy bypass as the supported close procedure.
`reporting.md` — formal report review	Reporting and Trial Balance contracts, Money, Business Time, Close, ADR 0020	Partially available. The page now gives the exact live trial-balance date-entry, run, interpretation, and blocker procedure. Balance sheet, income statement, ReportRun capture/review, currentness, and drilldown remain service-only.	Revised in 15U3; expand only after 15D exposes the remaining Reporting surfaces.
`faq.md` — common help	Accounts, Close, Posting and Reversal	Unsupported as help. It contains questions without answers and points at unavailable Corrections and Close paths.	Remove from navigation now; recreate from verified user questions after functional UAT.

All 18 pages have the required Status, Audience, and Source truth headers. Strict build verification remains the link and navigation gate.

Smallest useful information architecture

Keep the public route task-oriented and distinguish available work from product scope:

Start — one overview/getting-started entry, then Getting Organized.
Set up — Company Setup and Chart of Accounts, limited to actions visible in the supported startup path.
Work in the current period — Current Period Workbench, manual entry, Summary desk review, and a new compact Ledger Review task page.
Review results — Trial Balance instructions in Reporting.
Product scope and availability — one compact workflow map explaining implemented-but-unexposed, accepted-but-unimplemented, and deferred areas.

Do not keep unavailable domain chapters in the primary task path merely to mirror the canonical workflow taxonomy. Their durable scope may remain linked from the availability map until the owning desktop slice supplies a real user procedure.

Documentation slices

Slice	Outcome and included pages	Dependencies and exclusions	Acceptance and verification	Status
15U1. Truthful entry and availability navigation	Revise `index.md`, consolidate or expand `getting-started.md`, reduce `workflows.md` to a user-facing scope/availability map, reorganize User Guide navigation, and add prominent present-build boundaries to every page that remains reachable. Remove the empty FAQ from navigation.	Uses current truth and verified XAML/application evidence. Does not document service-only workflows as usable, change canonical status, or package customer docs.	Every primary task link leads to a supported desktop action or an explicit availability page; `active` is defined as release scope; no unavailable procedure is presented as executable; strict MkDocs build and human navigation read pass.	Complete
15U2. Startup and setup guide	Align `getting-organized.md`, `company-setup.md`, and `chart-of-accounts.md` with the supported company-selection, bootstrap, reselection, calendar, starter-chart/collision, review, and opening-disposition path. Retain the invented role/action matrix only as a clearly labeled, non-authoritative example; mark policy templates for accounting/legal review.	Follow the completed 15A3 surface for guided reviewed-subject wording. Do not pre-document 15A4 chart import, 15A5 role assignment, 15A6 opening posting, 15A7 completion handoff, final production roles, or QBO conversion.	Steps can be followed against the desktop without database intervention; blockers and recovery match Setup Readiness; UAT-0001 and UAT-0003 paths are represented; strict build and desktop documentation walkthrough.	Complete
15U3. Current-period, Ledger, and trial-balance guide	Rewrite `current-period-workbench.md`; narrow `accounting-imports-and-batches.md` to visible Summary desk review; add a compact Ledger Review page for the 15R1 surface; narrow `reporting.md` to the visible trial balance while naming unavailable report functions.	Uses current manual-entry, workbench, Ledger, Source Document, posting, and Reporting truth. Excludes file intake creation, domain-specific fact entry, Corrections, Close, ReportRun capture, balance sheet, and income statement.	A user can prepare/validate/post a manual entry, review or repair an existing Summary batch, inspect registers and drilldown, verify the Ledger result, and run a trial balance; UAT-0002 and UAT-0004 evidence is reflected; strict build and desktop walkthrough.	Complete
15U4. Workflow-guide activation handoffs	Convert each held scope page into an operating guide only as its owning UI slice completes: sales tax after 15B0T6; intake and four Summary areas after 15B1; Corrections after 15B2; Close after 15C; full Reporting after 15D; QBO replacement after 15E.	Each guide must use the released desktop path and its accepted truth. No speculative procedures and no Dolibarr operational instructions without a supported BooksPlus handoff.	Owning UI tests and UAT pass first; page covers prerequisites, actions, blockers, recovery, evidence, results, and boundaries; strict build and task-specific human read pass.	Planned; dependency-driven

15U1 completion record: the User Guide now opens with the verified current- desktop path, separates BooksPlus 1.0 scope from present availability, and groups primary navigation under Start, Set Up, Work in the Current Period, Review Results, and Product Scope. getting-started.md describes only the supported startup-to-first-post and trial-balance path. workflows.md is a compact availability map instead of a copied taxonomy. Available, partial, service-only, accepted-but-unimplemented, and deferred states are explicit; every retained or scope-linked page has a prominent current-desktop boundary. The empty FAQ and service-only workflow chapters are no longer primary task navigation. Strict MkDocs verification and a navigation/readability review passed. No canonical truth, application code, or bp3-doli behavior changed. 15U2 completion record: getting-organized.md, company-setup.md, and chart-of-accounts.md now follow the completed 15A3 Guided Setup sequence and use its visible labels, governed subjects, blockers, stale-review recovery, starter-chart collision actions, permission-review boundary, and honest opening-balance disposition. Service-only chart import and role repair, opening-balance posting, final completion handoff, production role administration, and QBO replacement remain explicitly unavailable. The invented role/action matrix remains only as an Example only business discussion aid; it disclaims BooksPlus role, permission, control, and desktop- availability meaning. The policy checklist likewise requires accounting and, where applicable, legal or tax review. getting-started.md now links to the detailed guide. Strict MkDocs verification passed, as did 33 focused onboarding and window-surface tests. No canonical truth, application code, or bp3-doli behavior changed.

15U3 completion record: current-period-workbench.md now gives the exact manual-entry, register, exception, Source Document, Support Detail, and blocked- recovery path. accounting-imports-and-batches.md is narrowed to existing Summary batches and the visible review, audited Add Line repair, derived next action, posting, and outcome controls. New ledger-review.md records the UAT-0002 reload behavior and UAT-0004 entry heading, debit-first account lines, stable line numbers, and Details handoff. reporting.md now documents only the live inclusive-date trial balance and explicitly withholds service-only Reporting. Navigation, overview, Getting Started, and the availability map link the verified tasks. File intake, domain-specific fact entry, Corrections, canonical Close, ReportRun capture, balance sheet, and income statement remain outside executable instructions. Strict MkDocs verification passed, as did 115 focused desktop tests. No canonical truth, application code, or bp3-doli behavior changed. The 15A6 documentation alignment is now complete; 15U4 remains dependency-driven.

Findings, exclusions, and handoffs

Resolved documentation drift: primary navigation now separates supported tasks from scope-only pages; the availability map distinguishes release scope from build availability; the current-period and Summary guides no longer present file intake or domain-specific services as desktop procedures; and the empty FAQ remains outside navigation.
Resolved truth/documentation conflict: the starting authority matrix in getting-organized.md formerly implied a production role-permission matrix that the Roles and Permissions Contract explicitly defers. It is now labeled as a non-authoritative example and is outside the executable product path.
Implementation/documentation conflict: period-close.md documents CloseRun while the desktop still exposes legacy period toggles. Preserve the canonical page meaning but withhold it as an operating procedure until 15C.
Truth gaps: final production role templates and permissions remain gated by 15G; detailed seller-owned sales-tax behavior remains gated by 15B0T. Neither gap blocks truthful documentation of currently visible work.
Resolved truth/implementation conflict: ADR 0035 and slice 15A5C define and implement a durable pause after controlled-conversion chart application. Material account changes now invalidate exact chart and dependent role review; ordinary Setup review is required before exact conversion resume can post opening balances.
Resolved planning/truth conflict: the former 15A6 acceptance wording required exact replay, but ADR 0015 explicitly gives ordinary manual posting no idempotency key. The implemented desktop revalidates the exact reviewed draft, prevents concurrent resubmission, exposes a duplicate source as a conflict, and tells the user to inspect durable result identifiers after an interruption; it does not claim exact replay.
Completed Setup functional acceptance: development-mode desktop UAT-0005 passed on 2026-08-13, verifying the no-database-intervention handoff, first posting, Setup re-entry, and restart path. This closes 15A7 and Step 15A but is not evidence of production authorization readiness.
Production authorization release gate: UAT-0006 confirms that the initial production bootstrap lacks fiscal_calendar_profile.create_draft and the desktop has no supported production permission-administration path. Step 15G owns the truth-gated role/protected-action and administration resolution; Step 15K must rerun the complete production startup and handoff path.
Implementation gaps: provider-agnostic file intake, all four domain Summary entry surfaces, contractor/1099 work, Corrections, canonical Close, full Reporting, and QBO replacement remain unavailable through supported desktop navigation.
Skipped from current operating instructions: seller-owned sales-tax work (missing desktop path and UAT); domain Summary entry and 1099 work (no desktop entry); duplicate/correction review (no desktop entry); canonical Close (no supported desktop entry); balance sheet, income statement, ReportRun capture/review (no desktop entry); QBO conversion (no desktop entry and live broker qualification outstanding); production user administration (truth-gated); installation, update, backup, licensing, and recovery (sysadmin/15H-15I ownership); Dolibarr operations (no current supported desktop handoff); and all ADR 0020 deferred workflow nodes.
Subject-matter handoff: an accountant and, where appropriate, legal or tax counsel must review optional policy templates, capitalization examples, tax-responsibility language, retention suggestions, and internal-control advice before those materials are promoted as customer guidance.

bp3-wiki owns 15U. bp3 supplies stable visible labels, blocked outcomes, tests, and UAT evidence. There is no current bp3-doli change. 15U1 through 15U3 and Step 15A are complete; 15U4 activates only after its owning UI slices. The sole next action is 15B0T6 development-mode functional UAT; UAT-0006 remains a later release dependency on 15G and 15K.

Priority and slices

Use one reviewable slice at a time. A later slice may be refined while an earlier UAT slice runs, but implementation should preserve the order below unless new evidence changes a dependency.

Priority	Slice	Outcome and included work	Truth gate, exclusions, and acceptance	Status
1	15A. Complete Setup & Onboarding release readiness	Execute 15A0 through 15A7 above: close the current UAT evidence, make company reselection safe, establish canonical readiness meaning, expose guided review, chart acquisition, account-role resolution, and opening-balance posting, then qualify the completion handoff.	Preserve the detailed truth gates and exclusions in the 15A slice table. Development-mode UAT-0005 qualifies functional behavior only. Production user/role administration and UAT-0006 remain 15G/15K release gates; QBO replacement remains 15E.	Complete; UAT-0005 passed 2026-08-13
2	15R1. Ledger entry-and-line review presentation	Replace the flat posted-entry summary with an entry heading and its journal lines. Show entry number, posting date, financial-period label, company currency, source, explanation, and totals at entry level; show debit lines before credit lines with account code and name, line description, debit, and credit. Add a compact entry-heading Details action into the existing Support Detail drilldown.	Governed by the Journal Entry Contract, Account Contract, UX Principles, and ADR 0026. Currency remains explicit on every persisted line even when displayed once in the single-currency entry heading. Display grouping does not renumber persisted lines. Preserve immutable entry/line identity, source evidence, posting, period resolution, company isolation, and audit. Application tests cover account resolution, missing-account fallback, debit/credit grouping, stable line numbers, totals, drilldown navigation, and XAML bindings; PostgreSQL and desktop retest close UAT-0004.	Complete
3	15U. User-guide alignment	Execute 15U1 through 15U4 above: correct guide navigation and availability claims, document the verified startup and current-period paths, and activate later workflow guides only after their owning desktop slices pass.	Derived documentation only; no new product meaning, no service-only procedure presented as usable, and no customer-doc packaging before 15J.	15U1 through 15U3 complete; 15U4 remains dependency-driven
4	15B0. Active-workflow presentation inventory	Build an exact matrix from every ADR 0020 active workflow and implemented application service to its desktop entry point, actions, blocked outcomes, review/register, drilldown, permissions, and UAT case. Add workflow-family/group/label/status navigation metadata before exposing additional actions.	This is a presentation and planning audit, not permission to invent missing workflow meaning. Split implementation at the owning application-service boundary; do not create one cross-domain UI commit.	Complete
5	15B0T. Sales-tax accounting and remittance control	Execute 15B0T1 through 15B0T6 above: accept the contract, then implement capability/Sales preparation, return controls, remittance/Finance match, Close integration, and desktop/UAT as separately reviewable owners.	ADR 0034 and the canonical Sales Tax Accounting and Remittance Contract govern. Exclude tax calculation, native invoicing, filing transmission, payment initiation, operational tax subledgers, and provider transaction APIs.	15B0T1-T5 complete; 15B0T6 desktop implemented, functional UAT next
6	15B1. Intake and operational Summary desktop surfaces	In separate bounded sub-slices, wire provider-agnostic accounting-file intake and its review decisions, Sales and Receivables, Purchasing and Payables plus contractor/1099 work, Inventory, and Banking and Finance into the existing Summary desk/register patterns. Preserve candidate, fact, evidence, batch, non-posting result, and posting-result drilldown.	Use each canonical intake/Summary contract and the Step 15B0 matrix. The UI submits facts and commands to existing owners; it does not post directly, infer missing provider facts, activate deferred operational ERP work, or treat the Dolibarr placeholder connector as production intake.	Planned after 15B0T
7	15B2. Corrections and duplicate-review desktop surface	Add discoverable correction preparation, readiness, reversal/adjustment posting, workflow support, immutable posted-chain review, and import duplicate/replay/conflict outcomes. Link from the posted-entry and import surfaces where the owning workflows already support the action.	Use the Accounting Correction and Accounting Import Candidate contracts. Exact replay must not create another workflow record or post; duplicate meaning remains reviewable; conflicts and unresolved relationships remain blocked. Excludes silent mutation and a second correction engine.	Planned
8	15C. Canonical Close desktop surface	Replace the legacy direct period-toggle controls with CloseRun evaluation, check review, evidence/report-pack coordination, waiver/revocation, hard-close approval, soft/hard finalization, top-down reopen, and run/reopen history.	Use the Close Run Contract and protected actions. Blocked, stale, denied, and failed outcomes stay visible. Close creates no ledger line. Automated closing entries and automatic reopen cascades remain deferred.	Planned
9	15D. Standard Reporting desktop surface	Keep the existing trial balance, add balance sheet and income statement live review, ReportRun capture/register/review, currentness, source drilldown, and Close handoff.	Use canonical Reporting truth and contract. All formal results derive from posted ledger lines. Rendering, printing, spreadsheet/PDF export, automated closing entries, and configurable statements remain deferred unless separately accepted.	Planned
10	15E. QBO replacement-scenario surface and qualification	Expose explicit company/realm selection, connection and capture status, mapping review, control reconciliation, approval, application, blocked outcomes, resume/retry, and immutable evidence. Run the representative fixture path first, then one authorized live sandbox/company test through backup and recovery.	ADR 0032 and the QBO conversion contracts govern. Never apply the flow to startup companies. No QBO writes, full-history conversion, Desktop conversion, or recurring sync. Resolve and qualify the client-secret/callback/refresh/revocation broker boundary before calling live conversion customer-ready.	Planned
11	15F. Functional UAT cycle	Exercise provider-agnostic file intake, current-period manual work, each Summary workflow, seller-owned and facilitator-remitted sales-tax accounting, filing-summary eligibility, return/remittance evidence and bank linkage, contractor/1099 support and portal handoff, duplicate/conflict handling, correction, adjustment, manual pre-close entries, trial balance, balance sheet, income statement, soft close, hard close, reopen, QBO replacement, and backup/restore. Convert every defect into a bounded remediation unit and rerun affected scenarios.	Functional UAT may use an explicit development/test role so permission setup does not obscure workflow defects. It must not be used as evidence of production authorization readiness.	Planned
12	15G. Production users, security, and permissions	First settle the launch actor lifecycle, OS-identity mapping, minimum role templates or reviewed custom-role path, protected-action matrix, role assignment/review, disable/retire behavior, administrator handoff/recovery, step-up boundary, and security audit review. Then implement the production UI and rerun protected-action UAT with narrow actors, including UAT-0006 denial and authorized Setup success.	Truth gate: amend the Roles and Permissions contract and related security truth, adding a dedicated ADR if the decision warrants one, before implementation. Preserve separable sysadmin/accounting authority, explicit Setup/Correction/Close/Reporting/Conversion grants, no hidden production full-access role, and no permanent support access. UAT-0006 cannot be closed by direct database grants or a development/test role.	Planned after functional UAT; owns UAT-0006 resolution
13	15H. Installation, update, and lawful-license truth	Decide the supported OS/package boundary, managed PostgreSQL ownership, prerequisites, install/repair/update/rollback/uninstall behavior, migration and health checks, recovery-safe failure behavior, application signing, license/activation/transfer/disable evidence, offline behavior, and customer-data access when a license is unavailable.	Truth gate: accept a deployment/licensing ADR and update security/audit/backup contracts where needed. Copy protection must not strand existing records, backups, exports, or recovery material.	Planned after functional UAT
14	15I. Customer installer and operational recovery	Build and qualify the installer/updater from 15H, including managed database initialization, configuration, migrations, health diagnostics, repair, upgrade recovery, safe uninstall/data retention, application signing, and license enforcement. Expose supported backup, export, validate, and restore operations needed for customer control.	Clean-machine, interrupted-install, failed-migration, upgrade, repair, uninstall/reinstall, license-state, backup/restore, and at-rest protection tests must pass on every supported launch OS.	Planned
15	15J. Customer wiki subset	Define a manifest and reproducible build for customer-facing user and sysadmin documentation; add navigation, version labeling, product prerequisites, install/update, security, backup/restore, onboarding, QBO conversion, Corrections, Close, Reporting, sales-tax responsibility and remittance limits, troubleshooting, and deferred-feature boundaries.	Derive only from binding truth and the released UI. Exclude `docs/truth/`, `docs/planning/`, internal developer/Codex guidance, fixtures, test evidence, secrets, and provider-development material. Link checking and a human customer-read pass are required.	Planned
16	15K. Release-candidate qualification	From a clean machine, install a signed build, bootstrap a production administrator, create and restore companies, complete startup and replacement scenarios, exercise narrow-role denial/success, run correction-close-report cycles, qualify bounded sales-tax return/remittance control, upgrade the prior supported build, verify backup/export/recovery, validate customer docs, and record the exact release manifest. Rerun the complete production UAT-0006 startup, Setup completion, Current Period handoff, protected first posting, re-entry, and restart path.	No blocker or major UAT findings remain open. Standard, PostgreSQL-enabled, packaging, migration, recovery, security, and smoke suites pass with exact evidence. Any waived limitation is explicit in customer-facing release notes and does not contradict truth.	Planned; final UAT-0006 qualification

Post-initial-release integration horizon

The following work is intentionally retained so it is not lost again, but it is not a BooksPlus 1.0 release gate:

Dolibarr capture, provider-specific mapping, durable outbox delivery, retry, acknowledgement, and reconciliation evidence for Sales and Receivables, Purchasing and Payables, Inventory, and Banking and Finance Summary contracts;
reviewed journal-source profile and provider-payload mapping into versioned, provider-agnostic BooksPlus intake contracts; and
direct IRIS A2A submission, acknowledgments, rejection handling, and linked corrections if direct transmission is accepted for a future release.

These items require their own future-release roadmap and stable shared wire contracts. The existing manual/file paths and reviewed IRIS Taxpayer Portal handoff remain the initial-release fallbacks.

Commit strategy

Use one reviewable slice at a time:

release truth and development plan;
application-repo pointer to the plan;
workflow taxonomy updates in derived user docs;
kernel stabilization;
one workflow implementation slice at a time, in the sequence above.

When a slice touches posting, close, source documents, security, or reporting, read the relevant truth page, contract, and accepted ADR before implementation.

BP3 Initial Release Plan

Planning maintenance model

Release objective

Current implementation baseline

Step status

Completed-step handoffs

Launch workflow model

Workflow family mapping

Scope boundaries

Architecture guardrails

Development sequence

1. Align release truth and navigation

2. Stabilize the accounting kernel

3. Build Setup & Onboarding

4. Build the Current Period Workbench

5. Add summary accounting foundation

6. Simplify the Current Period Workbench around the summary transaction desk

7. Build Sales and Receivables Summary

Completed Step 7 baseline

Step 7 source-file strategy

Step 7 slices

Step 7 fixture acceptance

Step 7 boundaries and verification

8. Build Purchasing and Payables Summary

9. Build Inventory Summary

10. Build Banking and Finance Summary

11. Build Corrections

12. Build Period Close

13. Build Reporting

14. Build replacement-scenario QBO controlled conversion; defer external automation

Verified implementation baseline

Slices

Slice 14B completion record

Slice 14C1 completion record

Slice 14C2A completion record

Slice 14C2B completion record

Slice 14C2C completion record

Slice 14D completion record

Slice 14E completion record

Deferred professional interchange

Kernel follow-up: business time and period cutoffs

Step 3 startup-scenario UAT remediation

Work unit 3R1 completion record

Work unit 3R2 implementation handoff

Work unit 3R3 completion record

Step 15 release readiness and production delivery

Verified presentation and delivery baseline

Step 15A Setup & Onboarding slices

Step 15B0 active-workflow presentation inventory

Active taxonomy-node matrix

Implemented-service exposure inventory

Step 15B0T sales-tax accounting and remittance slices

Step 15U User-guide alignment

Page assessment

Smallest useful information architecture

Documentation slices

Findings, exclusions, and handoffs

Priority and slices

Post-initial-release integration horizon

Commit strategy