--- id: CON-ACC-CLS-004 name: Close Record feature: FEAT-ACC-CLS-04 product_area: accounting module: close revision: 1 status: draft product_intent: proposed implementation_evidence: observed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A close record combines the retained evidence of a successful close with its execution and linked correction history. owned_by: MOD-ACC-CLS synonyms: - close snapshot - the record not_to_be_confused_with: - A fresh evaluation of current readiness. - The separate receivables aging version. facets: - name: Captured evaluation meaning: >- The immutable snapshot retains revalidated readiness, reconciliation and close outputs. used_for: Recovering the evidence used during execution. - name: Exception participants meaning: Accepted exceptions retain their requesting and approving people. used_for: Reviewing exceptional reconciliation decisions. - name: Audit entries meaning: >- Request, close and reopen entries record people, times and correction reasons. used_for: Explaining the month’s later history. - name: Linked reopens meaning: Correction requests refer to the close they address. used_for: Following changes after the original close. - name: Aging request meaning: The run identifies the aging version requested for month end. used_for: Connecting closing with the separate reporting process. - name: Customer data operations meaning: >- Exports carry retained snapshots and erasure removes them in dependency order. used_for: Accounting for customer history throughout data lifecycle operations. relationships: - to: CON-ACC-CLS-003 statement: The record exists for one successful close with its snapshot. provenance: observed source: >- services-accounting:modules/fiscal-close/services/runs/close-run-view.ts:closeRecordOf - to: CON-ACC-CLS-002 statement: It preserves the revalidation result stored during execution. provenance: test source: >- services-accounting:modules/fiscal-close/tests/integration/services/jobs/close-job.integration.spec.js#records the close snapshot of the period - to: CON-ACC-CLS-001 statement: The closed period identifies its associated close run. provenance: observed source: >- services-accounting:modules/fiscal-close/services/persistence/fiscal-periods.ts:setPeriodStatus acted_on_by: - CAP-ACC-CLS-011 - CAP-ACC-CLS-014 - CAP-ACC-CLS-015 - CAP-ACC-CLS-016 visible_to: - ACT-ACC-007 - ACT-ACC-015 - ACT-ACC-014 evidence: - >- services-accounting examination inputs: modules/fiscal-close/db/period-close-snapshots.table.ts, services/persistence/period-close-snapshots.ts, services/runs/close-run-view.ts, services/ports/ar-snapshot-port.ts, export/fiscal-close.dataset.ts; modules/maintenance/services/participants/fiscal-close-participant.ts; docs/fiscal-close/PHASE-2-PLAN.md §2, §4.1. - >- react-console examination inputs: components/accounting/close/close-record.tsx, close-history.tsx. supersedes: [] --- # Close Record ## What It Is A close record is the retained evidence associated with one successful close. Its central snapshot contains the readiness captured during revalidation, the reconciliation summary and the close outputs with acknowledged warnings. Finalization writes that snapshot in the same transaction as the closed period and successful run outcome. The response combines the snapshot with the run and its later linked reopening history. Staff can see what was evaluated, which reconciliation exceptions were accepted, and the request and completion entries in the audit trail. Each later successful close has its own evidence, so correcting a month does not replace the earlier snapshot. The record has a different time boundary from a fresh readiness evaluation. It preserves the run’s stored re-check, including the period state represented during that check. It does not claim that all underlying data stayed unchanged until finalization. Its value is an accountable record of the evidence execution retained. ## What It Is Not The record is separate from the live checklist, which evaluates current information. It is also separate from the receivables aging version requested during finalization. Transactions defines that report type and Platform supplies its ledger. A failed run may have events and recorded outputs, but it has no completed close record without a successful close and snapshot. ## How It Is Used Controllers and auditors open the record from a successful run or Close History. They review the captured checks and payment context, identify the participants in accepted exceptions, and inspect later reopening requests and their reasons. The original snapshot remains available after correction so an earlier decision can still be reviewed. The console resolves user references through Platform. Service readers currently receive identifiers without resolved names for people. A customer export embeds snapshots with their owning runs. Erasure removes the evidence before removing records that those runs reference. These data operations preserve the dependency order rather than bypassing the close’s history protections. ## Its Facets **Captured evaluation.** Readiness, reconciliation and output documents retain the run’s evidence. Each is a structured object with a storage-size bound, and the snapshot cannot be updated. **Exception participants.** Accepted reconciliation exceptions retain the person who requested and the person who approved them, supporting later review of exceptional decisions. **Audit entries.** Request and completion entries identify the actor and time, with reopen reasons adding correction context. **Linked reopens.** Reopen runs refer to the close they address. The record currently returns the oldest one hundred without a continuation, so an unusually long history can be incomplete. **Aging request.** The run output identifies the requested report version and basis. Requesting a version does not establish that its computation has completed. **Customer data operations.** Export includes the customer’s runs and captured snapshots while withholding operational job rows and retry keys. Erasure removes the retained records for the selected workspace. ## How It Relates The successful run owns the snapshot, and the closed fiscal period points to its closing run. Readiness supplies the stored evaluation, while Reconciliation supplies its payment context. The aging request belongs to the same finalization but produces a separate reporting artifact. Accounting Maintenance hosts the customer data participant used by Platform. ## What It Could Become The product should return resolved people’s names through the service as the approved plan requires. It should expose aging readiness without making the close wait for another active aging run. Long correction histories need an explicit continuation or truncation signal. Additional close checks should preserve their evidence here only after Product defines the obligation and suitable acceptance coverage establishes it.