Post and reverse fiscal-close system batches

Purpose

Fiscal close uses this module’s functions to post recognition and reverse it when a period reopens.

How It Works

The close process calls the system-posting and recognition functions within its transaction. Those functions collect due entries and produce the period’s system batch. Event identity prevents a repeated close from writing another result. System batches remain outside the ordinary batch actions. Reopening writes mirrors of their entries and resets the affected recognition. The close module owns the surrounding job, screens and fiscal-period lifecycle.

Relationships

Prerequisite: Plan deferred revenue and adjust its remaining releases, which addresses the connected batch work.
Related outcome: Use the batch’s permitted lifecycle actions, which addresses the connected batch work.
Related outcome: Unpost a batch for correction and replacement posting, which addresses the connected batch work.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Fiscal recognition and reopening connect schedule state with the period’s system accounting work.
Surfaces: job
Constraints: Month-end Close owns close and reopen orchestration, screens and period states.
Intent sources: services-accounting:docs/accounting/batches.md#Unposting deletes the entries (Andrew, Reporting D7, 2026-10-21)

Controls

18 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-005 TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-DAT-001 TC-DAT-004 TC-LOG-002 TC-LOG-003 TC-LOG-005 TC-PI-002 TC-PI-003 TC-PI-005

Business Rules

11 rules, 11 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Fiscal close posts one system batch per type, unit and period using its supplied name and date, and a later re-close reuses that batch with a new posting. proved by `ATS-ACC-BAT-020-01`, `TST-ACC-BAT-069`	lifecycle	service	test services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#writes the batch already posted, in the period, named and dated as given
`02`must prove Proposed	Repeated close event keys return the original batch and posting without writing, while reusing a key for different entries or a different period is refused. proved by `ATS-ACC-BAT-020-01`, `TST-ACC-BAT-069`	invariant	service, database	test services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#is refused with other entries (`event_key_reused`)
`03`must prove Proposed	System posting requires entries balanced on the unit’s accounts in base and transaction amounts, within two-decimal validation, dated in the period and without duplicate entry references. proved by `ATS-ACC-BAT-020-02`, `TST-ACC-BAT-069`, `TST-ACC-BAT-121`	validation	service	test services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses unbalanced entries (`entry_unbalanced`)
`04`must prove Proposed	System posting and recognition admit Open and Closing periods, while system reversal and unrecognition admit Closed and Reopening periods. proved by `ATS-ACC-BAT-020-03`, `TST-ACC-BAT-071`, `TST-ACC-BAT-121`	lifecycle	service, database	test services-accounting:modules/batches/tests/unit/close/close-rules.spec.js#refuses system_reversal in a period that is open (period_not_closed)
`05`must prove Proposed	Recognition takes current open schedules booked by the period end, releases all unrecognised entries due by then including earlier stragglers, and closes schedules fully recognised. proved by `ATS-ACC-BAT-020-04`, `TST-ACC-BAT-072`, `TST-ACC-BAT-073`	calculation	service	observed services-accounting:modules/batches/services/close/close-rules.ts:recogniseSchedule; services-accounting:modules/batches/services/close/revenue-recognition.ts:recognise_due_entries
`06`must prove Proposed	Recognition runs in the caller’s close transaction with system posting and period state, and refuses execution outside a transaction. proved by `ATS-ACC-BAT-020-04`, `ATS-ACC-BAT-020-11`, `TST-ACC-BAT-072`, `TST-ACC-BAT-073`	invariant	service	test services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#refuses recognition outside a transaction (`transaction-required`)
`07`must prove Proposed	Fiscal reopening retains original system entries, adds debit-credit mirrors, reverses the posting and returns its batch to Open. origin: services-accounting:docs/accounting/batches.md#Unposting deletes the entries (Andrew, Reporting D7, 2026-10-21) proved by `ATS-ACC-BAT-020-05`, `ATS-ACC-BAT-020-11`, `TST-ACC-BAT-018`, `TST-ACC-BAT-072`, `TST-ACC-BAT-073`	lifecycle	service	test services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#writes a reversing entry for each entry, debits and credits swapped, and keeps the originals
`08`must prove Proposed	Reopening resets recognised entries dated from the period start or recognised by that period and reopens affected schedules while preserving unaffected earlier recognition. proved by `ATS-ACC-BAT-019-14`, `ATS-ACC-BAT-020-05`, `ATS-ACC-BAT-020-10`, `TST-ACC-BAT-018`, `TST-ACC-BAT-072`, `TST-ACC-BAT-073`	lifecycle	service	test services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#un-recognizes A's and B's September entries and opens both schedules again
`09`must prove Proposed	System reversal rejects an ordinary posting and returns a no-change result for a posting already reversed. proved by `ATS-ACC-BAT-020-06`, `TST-ACC-BAT-069`, `TST-ACC-BAT-073`	validation	service	test services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#refuses a transaction batch's posting (`not_a_system_batch`)
`10`must prove Proposed	A system batch with a current posting rejects a new close key, and system-batch creation cannot take another batch’s name within the unit. proved by `ATS-ACC-BAT-020-06`, `TST-ACC-BAT-069`, `TST-ACC-BAT-073`	validation	service	test services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses a new key while the batch is posted (`system_batch_posted`)
`11`must prove Proposed	A closed period prevents ordinary unposting, and its system batch refuses all ordinary actions. proved by `ATS-ACC-BAT-004-14`, `ATS-ACC-BAT-016-14`, `ATS-ACC-BAT-020-07`, `ATS-ACC-BAT-020-08`, `ATS-ACC-BAT-020-09`, `TST-ACC-BAT-018`, `TST-ACC-BAT-074`	policy	service	test react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0528.spec.ts#ACT-ACC-0528

Scenarios

Id	Given	When	Then	Provenance
`01`	Membership schedules include entries due in July and August, with some booked late.	The close recognises the relevant due entries.	August’s system batch can include earlier July-dated stragglers on their original dates.	test services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#dates the swept-in entries in July, in August's batch
`02`	September’s system batch is Posted.	The period reopens and closes again.	Reopening resets recognition and adds system reversals, and re-close creates the next posting on the same batch.	test services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#posts September's same batch again, as its second posting

Planning

Implementation

Post and reverse fiscal-close system batches ​

Purpose ​

How It Works ​

Relationships ​