---
id: TST-ACC-CLS-023
title: 'Real deferred revenue through close, reopen and replay'
kind: integration
product_area: accounting
module: close
revision: 1
status: draft
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
repository: services-accounting
files:
  - >-
    modules/fiscal-close/tests/integration/services/jobs/revenue-recognition.integration.spec.js
implements:
  - ATS-ACC-CLS-003-02
  - ATS-ACC-CLS-008-06
  - ATS-ACC-CLS-009-01
  - ATS-ACC-CLS-009-03
  - ATS-ACC-CLS-009-04
  - ATS-ACC-CLS-012-01
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 3
isolation: >-
  The suite owns test-identifier workspaces and fixture records, removed by its
  teardown.
binding_policy: >-
  Each binding identifies the assertions this suite executes; combined scenarios
  may require other bound suites. Existence is not a recorded execution result.
evidence:
  - >-
    services-accounting:modules/fiscal-close/tests/integration/services/jobs/revenue-recognition.integration.spec.js
  - provenance: test
    source: >-
      services-accounting:modules/fiscal-close/tests/integration/services/jobs/revenue-recognition.integration.spec.js
    assertion_titles:
      - revenue recognition in the close and reopen jobs (integration)
      - July's close
      - >-
        finds the invoice's schedule as the engine wrote it, nothing recognized
        (premise)
      - 'ends the run succeeded, the recognition step completed'
      - >-
        records what the step posted: the batch, its posting by the close’s
        event key, the counts
      - 'posts July''s deferred revenue system batch, named and dated as 1.0 did'
      - 'posts it once, under the close’s event key'
      - >-
        writes one entry per July schedule entry, `<transaction_id>-<entry_id>`,
        debiting deferred revenue
      - marks the July entries recognized and leaves the later ones unrecognized
      - 'closes July, naming the run'
      - July's reopen
      - >-
        ends the reopen succeeded, the reversal step completed with what it
        un-recognized
      - un-recognizes the July entries
      - >-
        reverses the close’s posting by its event key, the batch open again with
        no count or total
      - 'writes a reversing entry for each, debits and credits swapped'
      - opens July
      - July's re-close
      - ends the run succeeded
      - >-
        posts the same batch again, as its second posting, under the new run’s
        key
      - stores the second posting's entries under the first's ids suffixed `-2`
      - marks the July entries recognized again
      - a retried recognition step
      - 'ran the port twice, the first attempt posting and then failing (premise)'
      - retries the step in the same job and ends the run succeeded
      - >-
        posts August's batch once, under the run's key: the failed attempt left
        nothing
      - marks the August entries recognized once
      - >-
        answers the step run again once done with what it recorded, writing
        nothing
real_dependencies: >-
  Production configuration, transaction, batch posting and close services use
  real PostgreSQL. The clock is fixed, a wrapped real recognition port injects
  one failure, and aging requests use a stand-in because no report worker runs
  here.
product_intent: proposed
implementation_evidence: observed
---
# Real deferred revenue through close, reopen and replay

## Verification Boundary

The suite checks its declared service or persistence boundary against local PostgreSQL. Bindings identify the assertions it contributes to a capability case; they do not establish every assertion in a combined case.

## What This Suite Proves

An invoice creates a real schedule and posting; closing recognizes due shares, reopening writes reversal entries and closing again posts new entries. A wrapped real port throws before commit to check rollback and replay without duplication.

## What It Does Not Prove

This register records assertion scope without claiming a passing run or complete coverage of every rule and scenario variant.

## Real Dependencies and Test Doubles

Production configuration, transaction, batch posting and close services use real PostgreSQL. The clock is fixed, a wrapped real recognition port injects one failure, and aging requests use a stand-in because no report worker runs here.

## Must Not Be Doubled

Keep production queries, writes, mappings, application-role privileges and database constraints real wherever they are the subject of an assertion. Recording financial ports establish invocation behavior; actual recognition and reversal require the suite using the real posting service.