--- id: CAP-ACC-CLS-005 title: Resolve ledger work that prevents closing feature: FEAT-ACC-CLS-02 product_area: accounting module: close revision: 1 status: draft product_intent: confirmed implementation_evidence: observed supersedes: - >- CAP-ACC-REC-016 (react-console acceptance inventory, the period, batch and transaction checks) - RUL-ACC-REC-066 - RUL-ACC-REC-067 - RUL-ACC-REC-068 source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f intent_sources: - >- services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 73 (class A: period ended, batches posted, transactions accounted) purpose: >- Finance staff identify unfinished period and ledger work before the posting boundary becomes final. outcomes: - The checklist exposes transactions that have not reached a posted batch. - Staff can locate each outstanding record and the work it requires. concepts: - CON-ACC-CLS-002 actors: - ACT-ACC-015 - ACT-ACC-012 surfaces: - console - api preconditions: [] postconditions: [] permissions: - key: accounting.fiscal-periods.read where_checked: api scope: tenant rules: - id: BR-CAP-ACC-CLS-005-01 proved_by: [ATS-ACC-CLS-005-01, TST-ACC-CLS-043] statement: >- The prior-periods check blocks for every earlier month that is not closed and presents those months in date order. kind: validation enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/unit/readiness/period-rules.spec.js#is blocked by a period of an earlier year, and counts every one oldest first origin: fiscal-close design L2 (Rhythm 1.0 CLOSE-2 kept) - id: BR-CAP-ACC-CLS-005-02 proved_by: [ATS-ACC-CLS-005-01, TST-ACC-CLS-043] statement: >- The ended-period check passes only after the month’s final day in the workspace time zone and identifies the first eligible closing date. kind: validation enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/unit/readiness/period-rules.spec.js#is blocked on the period’s last day origin: >- services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 73 (class A: period ended; departs from Rhythm 1.0, design R1) examples: positive: >- September becomes eligible for the ended-period check on October’s first day. negative: The final day of September still fails the ended-period check. - id: BR-CAP-ACC-CLS-005-03 proved_by: [ATS-ACC-CLS-005-02, ATS-ACC-CLS-005-04, ATS-ACC-CLS-005-05, TST-ACC-CLS-004, TST-ACC-CLS-036, TST-ACC-CLS-038, TST-ACC-CLS-041] statement: >- The batches check blocks for batches in the period that are neither posted nor downloaded and includes their count in its explanation. kind: validation enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/integration/services/readiness/evaluate-readiness.integration.spec.js#blocks on each failing check with its headline: 23 batches must be posted origin: >- services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 73 (class A: batches posted) - id: BR-CAP-ACC-CLS-005-04 proved_by: [ATS-ACC-CLS-005-02, ATS-ACC-CLS-005-04, TST-ACC-CLS-004, TST-ACC-CLS-036, TST-ACC-CLS-038, TST-ACC-CLS-041] statement: >- Archived batches prevent closure even though the earlier product allowed them. kind: validation enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/unit/carried/fiscal-years/logic/validate-period-closing-batches.spec.js#2.0: is blocked by the archived batch of 1.0's baseline, which 1.0 let through origin: fiscal-close FC2-3 departure (archived batches block; no recorded ruling) - id: BR-CAP-ACC-CLS-005-05 proved_by: [ATS-ACC-CLS-005-02, TST-ACC-CLS-036, TST-ACC-CLS-038, TST-ACC-CLS-041] statement: >- Outstanding batches identify the next action for their state, including closing, posting, waiting, retrying or restoring. kind: policy enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/unit/readiness/batches-posted.spec.js#names the action each unposted status requires origin: none - id: BR-CAP-ACC-CLS-005-06 proved_by: [ATS-ACC-CLS-005-02, TST-ACC-CLS-036, TST-ACC-CLS-038, TST-ACC-CLS-041] statement: >- Deferred revenue and cost of goods sold system batches owned by the close are excluded from outstanding batches, including after reopening. kind: policy enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/unit/readiness/batches-posted.spec.js#never counts the close’s own open system batches, deferred revenue and COGS, as unposted origin: none - id: BR-CAP-ACC-CLS-005-07 proved_by: [ATS-ACC-CLS-005-03, ATS-ACC-CLS-005-04, ATS-ACC-CLS-005-05, TST-ACC-CLS-004, TST-ACC-CLS-035, TST-ACC-CLS-046] statement: >- The transactions check includes eligible invoices, payments, credits, credit applications, refunds, memos and write-offs dated in the period when their batch is absent, unposted or failed; draft and pro forma invoices are excluded. kind: validation enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/integration/services/persistence/unaccounted-transactions.queries.integration.spec.js#answers every kind, mapped whole, by date with each reason origin: >- services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 73 (class A: transactions accounted) - id: BR-CAP-ACC-CLS-005-08 proved_by: [ATS-ACC-CLS-005-03, TST-ACC-CLS-035, TST-ACC-CLS-046] statement: >- Each outstanding transaction identifies its posting problem and links to the corresponding record. kind: policy enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/fiscal-close/tests/unit/readiness/transactions-accounted.spec.js#routes each kind to its own record origin: none - id: BR-CAP-ACC-CLS-005-09 proved_by: [] statement: >- Outstanding transactions return no customer name in the current readiness response. kind: policy enforced_at: - service must_prove: false provenance: observed source: >- services-accounting:modules/fiscal-close/services/readiness/transactions-accounted.ts:ruleTransactionsAccounted origin: none scenarios: - id: SC-CAP-ACC-CLS-005-01 given: >- September contains twenty-three open batches and an invoice without a batch. when: Readiness runs on October’s third day. then: >- Batch and transaction checks expose the outstanding work while the ended-period check passes. provenance: test source: >- services-accounting:modules/fiscal-close/tests/integration/services/readiness/evaluate-readiness.integration.spec.js#names the open earlier period, the unaccounted invoice and reconciliation’s blocker unchanged - id: SC-CAP-ACC-CLS-005-02 given: October’s final day has not passed. when: Staff evaluate October. then: The ended-period check prevents closure until November’s first day. provenance: test source: >- services-accounting:modules/fiscal-close/tests/integration/services/readiness/evaluate-readiness.integration.spec.js#blocks October, which has not ended edge_cases: [] constraints: [] depends_on: - CAP-ACC-CLS-004 related: - CAP-ACC-CLS-003 journeys: - JNY-ACC-CLS-002 open_questions: [] evidence: - >- services-accounting examination inputs: modules/fiscal-close/services/readiness/prior-periods-closed.ts, period-ended.ts, batches-posted.ts, transactions-accounted.ts, services/persistence/unposted-batches.ts, unaccounted-transactions.ts; tests unit/readiness/period-rules.spec.js, batches-posted.spec.js, transactions-accounted.spec.js, unit/carried/fiscal-years/logic/validate-period-closing-batches.spec.js, integration/services/persistence/unposted-batches.queries.integration.spec.js, unaccounted-transactions.queries.integration.spec.js, readiness/evaluate-readiness.integration.spec.js. - >- react-console examination inputs: components/accounting/close/details/batches-detail.tsx, transactions-detail.tsx, periods-detail.tsx. controls: [TC-IAM-001, TC-IAM-002, TC-IAM-004, TC-IAM-005, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-AZ-006, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-LOG-002, TC-LOG-003, TC-LOG-004, TC-PI-001, TC-PI-002, TC-PI-005] exercised_by: [FAS-ACC-CLS-02-01, FAS-ACC-CLS-02-03, FAS-ACC-CLS-02-04] suites: [TST-ACC-CLS-004, TST-ACC-CLS-035, TST-ACC-CLS-036, TST-ACC-CLS-038, TST-ACC-CLS-041, TST-ACC-CLS-043, TST-ACC-CLS-046] --- # Resolve ledger work that prevents closing ## Purpose Finance staff identify unfinished period and ledger work before the posting boundary becomes final. ## How It Works The controller first addresses calendar work before tackling ledger work. The checklist identifies earlier periods that remain outstanding and shows whether the selected month has ended. Batch results explain what to do for each unposted state. Archived batches require restoration and posting. The close’s own system batches are excluded so a reopened month can close again. Transaction results identify documents without a suitable posted batch. Each item distinguishes an absent batch from unfinished or failed posting. Staff open those records, resolve the cause and evaluate readiness again. Customer names are currently absent from these results. ## Relationships - Readiness combines these checks with the other closing conditions. - The posting boundary protects the period after this outstanding work is resolved.