--- id: CON-ACC-CLS-002 name: Close Readiness feature: FEAT-ACC-CLS-02 product_area: accounting module: close revision: 1 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- Close Readiness is the evaluated set of period-closing conditions, supporting records, reconciliation context and planned effects. owned_by: MOD-ACC-CLS synonyms: - the checklist - month-end checklist not_to_be_confused_with: - The payment assessment owned by Reconciliation. - The posting preview for an individual batch. facets: - name: Individual checks meaning: 'Each condition carries a requirement, outcome and supporting context.' used_for: Locating and resolving outstanding work. - name: Requirement meaning: >- Required blocked, pending or error results prevent closure; advisory results do not. used_for: Determining the effect of a check on closing. - name: Outcome meaning: >- The result distinguishes success, outstanding work, warnings, missing evidence and evaluation failure. used_for: Reading the evidence without confusing absence with success. - name: Overall verdict meaning: The combined check results produce readiness and summary counts. used_for: Prioritizing the controller’s review. - name: Evaluation scope meaning: 'Monthly evaluation has nine checks, and year scope appends three.' used_for: Adding the fiscal-year review. - name: Reconciliation context meaning: >- Payment totals, exceptions and clearing information accompany the owning assessment. used_for: Reviewing findings in their payment context. - name: Planned effects meaning: The preview lists work requested by closing. used_for: Confirming an action with an understanding of its effects. - name: Verification policy meaning: A workspace choice makes unmatched finalized payouts a required blocker. used_for: Applying the customer’s bank-verification policy. relationships: - to: CON-ACC-CLS-001 statement: A readiness request selects one period and may add fiscal-year checks. provenance: observed source: >- services-accounting:modules/fiscal-close/services/readiness/evaluate-readiness.ts:evaluatePeriodReadiness - to: CON-ACC-CLS-003 statement: Execution stores another evaluation after taking the period. provenance: test source: >- services-accounting:modules/fiscal-close/tests/integration/services/jobs/close-job.integration.spec.js#keeps the readiness the close evaluated on the run - to: CON-ACC-CLS-004 statement: >- Successful finalization preserves the execution evaluation in a close snapshot. provenance: test source: >- services-accounting:modules/fiscal-close/tests/integration/services/jobs/close-job.integration.spec.js#records the close snapshot of the period acted_on_by: - CAP-ACC-CLS-004 - CAP-ACC-CLS-005 - CAP-ACC-CLS-006 - CAP-ACC-CLS-007 - CAP-ACC-CLS-008 - CAP-ACC-CLS-010 visible_to: - ACT-ACC-015 - ACT-ACC-006 - ACT-ACC-007 evidence: - >- services-accounting examination inputs: modules/fiscal-close/services/readiness/*.ts; docs/fiscal-close/README.md §3 to §5, console-contract.md, reconciliation-interface.md; docs/milestones/plans/ACCT-M4-plan.md §4a rows 73 to 75. - >- react-console examination inputs: components/accounting/close/close-workspace.tsx, readiness-summary.tsx, readiness-checklist.tsx, check-detail-drawer.tsx, reconciliation-panel.tsx, details/*.tsx. supersedes: [] intent_sources: - >- services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 73 (class A; approved by D12) --- # Close Readiness ## What It Is Close Readiness is the evaluated view of the conditions for closing a selected period. It brings calendar work, ledger completeness, payment reconciliation, recognition setup and action authority into a single checklist. Each result carries a short explanation and any relevant figures, records or actions. The overall verdict helps a controller choose where to start reviewing. The view is calculated when requested. A normal read does not save a new close record or change the books. During execution, the close evaluates readiness again and stores that result on its run. Successful finalization later preserves it in the close snapshot. The live view and retained evaluation serve different moments in the same work. The checklist offers more context than a refusal encountered only after pressing Close. Staff can inspect outstanding batches, incomplete transaction posting and reconciliation findings before committing to execution. Its effects preview also explains the work that closing requests, including recognition and receivables aging. ## What It Is Not A displayed result does not authorize a future close. Records and permissions can change after the screen loads, and execution applies its own checks. Readiness is also distinct from Reconciliation’s assessment: that module owns its findings and figures. A batch preview concerns one posting request, whereas this checklist concerns the period’s closing conditions. ## How It Is Used The controller opens the chosen month, reviews the verdict and examines the checks that need attention. Supporting items help them find unfinished work in the owning Accounting screen. They resolve those causes and evaluate again. The close dialog obtains another evaluation before accepting confirmation. Readers and auditors can inspect the same information, although the present verdict includes their own close authority. A clean month consequently appears not ready to someone who cannot close it. A failed evaluator remains an error result and does not quietly disappear. The other checks continue so the review still has useful context. ## Its Facets **Individual checks.** A check joins its condition, result, explanation and supporting information. Item lists are bounded while retaining total counts. **Requirement.** Required and advisory describe the effect on closing. Required warnings may still permit a close; required blocked, pending or error outcomes do not. **Outcome.** Passed, blocked, warning, pending, not applicable and error distinguish completed evidence from missing work or an evaluation problem. **Overall verdict.** The service derives readiness from the checks and supplies summary counts. Advisory concerns remain warnings even when their own evaluation fails. **Evaluation scope.** Period scope contains the monthly checks. Fiscal-year scope adds calendar and reconciliation review for the year, although the request boundary also accepts that scope on an earlier month. **Reconciliation context.** The adjacent summary gives payment-state totals, exceptions, findings and merchant clearing lines from the owning assessment. **Planned effects.** The preview describes the close’s intended work rather than reporting work already performed. **Verification policy.** A stored workspace choice changes bank verification from advisory to required. The customer currently lacks a control for changing that approved choice. ## How It Relates The fiscal period supplies the date boundary and calendar context. Batch management and Transactions supply ledger information and recognition schedules. Reconciliation supplies payment findings. The close run performs and retains the execution evaluation, and the close record keeps it for review after completion. Sharing a transaction does not establish a fixed database snapshot across every read. ## What It Could Become The product should decide whether viewer authority belongs outside the books’ verdict. It should expose the bank-verification choice and align console filters with service warning classification. Customer-name resolution and a receivables control comparison are further review opportunities. Each addition needs an explicit source and acceptance evidence before it becomes a confirmed closing obligation.