---
id: CON-ACC-CLS-003
name: Close Run
feature: FEAT-ACC-CLS-03
product_area: accounting
module: close
revision: 1
status: draft
product_intent: confirmed
implementation_evidence: partially-observed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
definition: >-
  A close run retains one close or reopen request, the jobs executing it and its
  recorded outcome.
owned_by: MOD-ACC-CLS
synonyms:
  - close
  - reopen
  - run
not_to_be_confused_with:
  - Batch posting execution within a period.
  - The captured evidence left by successful closing.
facets:
  - name: Run kind
    meaning: 'The request is a period close, final-period year close or reopen.'
    used_for: 'Selecting checks, execution and recovery authority.'
  - name: Execution standing
    meaning: >-
      The outcome distinguishes saved, active, failed, successful and cancelled
      requests.
    used_for: Finding the appropriate next action.
  - name: Durable steps
    meaning: Jobs retain ordered work and retry attempts for the run.
    used_for: Tracking progress and reusing committed results.
  - name: Command key
    meaning: Matching keyed request content returns the existing run.
    used_for: Recovering safely from a lost response.
  - name: Explanation and review
    meaning: >-
      Notes, correction reasons and warning acknowledgements explain the
      request.
    used_for: Helping later reviewers understand its context.
  - name: Close-owned revenue
    meaning: A recognition batch moves due revenue and a reopen reverses it.
    used_for: Accounting for the close’s own ledger effect.
  - name: Recovery choices
    meaning: >-
      Retained period state and committed effects constrain retry and
      cancellation.
    used_for: Resolving interrupted work safely.
  - name: Execution history
    meaning: Ordered job events and attempts describe how the request proceeded.
    used_for: 'Reviewing warnings, failure and recovery.'
relationships:
  - to: CON-ACC-CLS-001
    statement: >-
      Execution protects its period before completing the closed or open
      transition.
    provenance: test
    source: >-
      services-accounting:modules/fiscal-close/tests/integration/services/jobs/close-job.integration.spec.js#closes
      the period, by the requester, naming the run
  - to: CON-ACC-CLS-002
    statement: >-
      The close evaluates required conditions again and records a refusal when
      they block.
    provenance: test
    source: >-
      services-accounting:modules/fiscal-close/tests/integration/services/jobs/close-job.integration.spec.js#ends
      the run failed at revalidate, not retryable
  - to: CON-ACC-CLS-004
    statement: >-
      Successful finalization stores a close snapshot, and reopen execution
      names the earlier close.
    provenance: test
    source: >-
      services-accounting:modules/fiscal-close/tests/integration/services/jobs/reopen-job.integration.spec.js#ends
      the reopen succeeded, naming the close it reverses
lifecycle:
  - state: queued
    meaning: The request and job are saved before execution begins.
    how_it_changes: 'Locking starts execution, or eligible cancellation ends the request.'
  - state: running
    meaning: The job is carrying out the requested action.
    how_it_changes: 'Finalization completes the run, or failure stops it.'
  - state: failed
    meaning: Execution stopped and may retain the period.
    how_it_changes: 'Eligible retry starts another job, or cancellation ends the request.'
  - state: succeeded
    meaning: 'The period change has completed, even if future-year work remains.'
    how_it_changes: The successful run is final.
  - state: cancelled
    meaning: The request has ended through an eligible cancellation.
    how_it_changes: The cancelled run is final.
acted_on_by:
  - CAP-ACC-CLS-008
  - CAP-ACC-CLS-009
  - CAP-ACC-CLS-010
  - CAP-ACC-CLS-011
  - CAP-ACC-CLS-012
  - CAP-ACC-CLS-013
visible_to:
  - ACT-ACC-015
  - ACT-ACC-007
  - ACT-ACC-016
evidence:
  - >-
    services-accounting examination inputs:
    modules/fiscal-close/services/jobs/*.ts,
    services/persistence/period-close-runs.ts, fiscal-close-jobs.ts,
    services/runs/close-run-view.ts, services/rules/transitions.ts,
    db/period-close-runs.table.ts, db/fiscal-close-jobs.table.ts,
    aws/logic/fiscal-close.step-functions.ts;
    docs/migrations/fiscal-close/README.md (FC2-4).
  - >-
    react-console examination inputs:
    components/accounting/close/close-dialog.tsx, reopen-dialog.tsx,
    close-run-view.tsx, close-history.tsx.
supersedes: []
intent_sources:
  - >-
    services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a rows 74 to 75
    (class A; approved by D12)
---

# Close Run

## What It Is

A close run is the saved request and outcome for one period close, year close or reopen. It identifies the period, requester, request time and command content. A durable job performs its steps. The run stays recognizable when the job fails or a retry starts another job for the same request.

A period close and year close use the same six-step workflow, with year scope adding checks for the final period. Reopening uses three steps. Saving the request and job together lets the service return the run while execution continues. Staff follow that execution through its page rather than keeping the submitting browser connection open.

A command key protects repeated requests after a lost response. Matching command content returns the existing run. A competing request for a period already held by another run is refused. The saved run consequently provides the common reference for progress, recovery and the record produced by successful closing.

## What It Is Not

The run is distinct from its job attempts. Retry creates a new job but does not create another closing request. It is also separate from a batch posting run, which handles ledger work within a period. The retained close record is the evidence from successful finalization; failed or cancelled runs still have execution history without acquiring that record.

## How It Is Used

A controller starts closing after review and confirmation. The run page displays ordered steps, attempts, produced records and events. Revalidation may discover required work that was absent from the earlier screen. That refusal releases the period and explains why a fresh close is needed after correction.

Other failures can leave the period protected. The controller inspects the failed step and chooses an eligible recovery action. Retry keeps committed recognition work. Cancellation is restricted once recognition or reversal has committed. A correction to a completed month uses a reopen run, and another close later records the corrected state.

## Its Facets

**Run kind.** Period close, year close and reopen determine the workflow, relevant checks and recovery permission.

**Execution standing.** Queued and running indicate work still proceeding. Failed can permit retry; succeeded and cancelled are final run outcomes.

**Durable steps.** Steps through close finalization lock the period and reuse committed results. Future-year generation follows separately and commits years individually.

**Command key.** The request carries a key and matching content can return the original result. The implementation currently omits requester identity from that comparison.

**Explanation and review.** A close can include a note and acknowledged warnings. A reopen requires a reason, which remains available to later reviewers.

**Close-owned revenue.** Recognition produces the system batch used for the period’s deferred revenue. Reopening calls its matching reversal. Cost of goods sold remains skipped.

**Recovery choices.** The period’s retained state and committed revenue effects determine whether retry or cancellation is allowed.

**Execution history.** Events and attempts span the run’s jobs, allowing reviewers to follow retries and recorded warnings without treating each job as another close.

## How It Relates

The run takes and changes a fiscal period. Closing consumes readiness, invokes revenue processing, requests aging and asks Books for future years. Successful finalization writes the close snapshot. A reopen identifies the close whose work it reverses and adds to that close’s linked history. Platform supplies the durable execution machinery used for these jobs.

## What It Could Become

The product should enforce the recorded requester-identity ruling for command replay and remove the wait for aging required by the approved plan. It should decide when to re-check the original requester’s authority and how to alert staff to stranded execution. Recovery wording needs to describe the allowed action honestly. Partial future-year generation also needs clearer replay expectations and acceptance evidence.