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.