---
id: ADR-ACC-CLS-006
title: 'Finalization Stores Closure, Evidence and the Aging Request Atomically'
product_area: accounting
module: close
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Finalization commits period closure, its immutable evidence, an accepted aging
  request and run success together; active aging blocks that commit within a
  finite repeat limit.
constrains:
  - DOM-ACC-CLS-001
  - DOM-ACC-CLS-004
  - DOM-ACC-CLS-003
  - WF-ACC-CLS-001
  - SVC-ACC-CLS-fiscal-close
origin: >-
  services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 74 (class A;
  plan approved 2026-10-21); docs/fiscal-close/PHASE-2-PLAN.md#4.1 (agreed with
  Snapshot Architecture 2026-10-16). The wait contradicts D8, which requires the
  close not to wait for aging.
alternatives:
  - option: Request aging only after closure commits.
    why_not: >-
      A crash between commits could leave no reporting request unless another
      durable mechanism records pending work.
  - option: Persist a pending request for later fulfillment.
    why_not: >-
      This matches the approved nonwaiting direction, but the inspected close
      has not implemented that mechanism or its requested-or-ready signal.
consequences:
  - Normal close success retains both evidence and the accepted aging reference.
  - >-
    An active aging run can exhaust finalization’s repeat limit and fail the
    close, releasing only a month without committed recognition.
  - >-
    Separate business units share an aging key for the workspace’s calendar
    month.
  - >-
    The task reads other units’ overlapping period state when selecting
    finalized or reconstructed basis.
supersedes: []
evidence:
  - >-
    services-accounting at f47cb263:
    modules/fiscal-close/services/jobs/fiscal-close-job-tasks.ts:finalizeClose;
    services/ports/ar-snapshot-port.ts; services/jobs/fiscal-close-jobs.ts
    (repeat).
---

# Finalization Stores Closure, Evidence and the Aging Request Atomically

## Context

The service must retain evidence for a successful close and record its reporting request, while respecting the approved direction to avoid waiting for reporting.

## Decision

The current task combines closure, capture and aging-request acceptance in one transaction. The atomic boundary is retained in this account; the bounded wait is an observed departure from the approved nonwaiting direction.

## Alternatives Considered

Request aging only after closure commits. A crash between commits could leave no reporting request unless another durable mechanism records pending work.

Persist a pending request for later fulfillment. This matches the approved nonwaiting direction, but the inspected close has not implemented that mechanism or its requested-or-ready signal.

## Consequences

Normal close success retains both evidence and the accepted aging reference. An active aging run can exhaust finalization’s repeat limit and fail the close, releasing only a month without committed recognition. Separate business units share an aging key for the workspace’s calendar month. The task reads other units’ overlapping period state when selecting finalized or reconstructed basis.