Place documents in eligible batches and protect posted work

Purpose

Batch intake and posting safeguards keep document placement aligned with the owning unit and recorded ledger work.

How It Works

Transaction workflows provide a batch explicitly or obtain one through assignment. The intake check verifies the batch’s unit, type and working state. Staff can move eligible documents before posting. The console and API differ in whether an Error batch is selectable. Posting brings stronger database safeguards that protect placement even from direct writes. Corrections then use the permitted document workflow or controlled unposting.

Relationships

Prerequisite: Assign new documents to the appropriate batch stream, which addresses the connected batch work.
Related outcome: Run and monitor a batch posting job, 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: Issued documents enter eligible collections and posted documents retain intake protection.
Surfaces: consoleapi
Constraints: Transactions owns document issuance, amendment and voiding; batch intake and posting protection are the concern here.
Intent sources: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-4services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-6services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-7services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-14

Controls

23 controls apply, from the corpus control catalogue.

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

Permissions

Key	Checked at	Scope
`accounting.batches.update`	console	tenant

Business Rules

10 rules, 10 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	Document intake accepts only an Open or Error transaction batch belonging to the document’s business unit and refuses an ineligible batch. proved by `ATS-ACC-BAT-007-01`, `TST-ACC-BAT-026`, `TST-ACC-BAT-063`, `TST-ACC-BAT-074`	validation	service	test services-accounting:modules/batches/tests/integration/services/close/system-batch-guard.integration.spec.js#refuses an invoice, a credit memo and a write-off naming the system batch (a transaction batch only, batch_not_open)
`02`must prove Proposed	The API can place documents in an Error batch, while the console picker restricts its choices to Open batches. proved by `ATS-ACC-BAT-007-02`, `TST-ACC-BAT-025`	policy	service, console	observed services-accounting:modules/batches/services/rules/batch-rules.ts:BATCH_ACCEPTING_STATUSES
`03`must prove Proposed	Draft and pro forma invoices remain outside batches. proved by `ATS-ACC-BAT-007-03`, `TST-ACC-BAT-031`, `TST-ACC-BAT-084`	invariant	database, service	test services-accounting:modules/batches/tests/integration/services/persistence/batch-totals.queries.integration.spec.js#is refused a batch by the database, so no batch’s totals can count one
`04`must prove Proposed	The database prevents moving a document into or out of a Posting, Posted or Downloaded batch. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-6 proved by `ATS-ACC-BAT-007-04`, `ATS-ACC-BAT-007-10`, `ATS-ACC-BAT-013-18`, `TST-ACC-BAT-025`, `TST-ACC-BAT-105`	invariant	database	test services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#refuses, in the database, moving a document out of a posted batch (RHA05)
`05`must prove Proposed	Before posting, staff can reassign a document between eligible Open batches of its unit, with batch-update permission required by the console. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-6 proved by `ATS-ACC-BAT-007-04`, `ATS-ACC-BAT-007-11`, `ATS-ACC-BAT-007-12`, `ATS-ACC-BAT-016-10`, `TST-ACC-BAT-025`, `TST-ACC-BAT-105`	policy	service, console	test react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0538.spec.ts#ACT-ACC-0538
`06`must prove Proposed	Posted batches reject new allocations, and an allocation without a batch is refused when its payment is posted and assignment provides no replacement. proved by `ATS-ACC-BAT-007-05`, `TST-ACC-BAT-106`	invariant	database, service	test services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#refuses, in the database, an allocation row into the posted batch (RHA05)
`07`must prove Proposed	Posted invoices, memos, payments and credits reject voiding and require an eligible correction document or controlled unposting instead. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-4 proved by `ATS-ACC-BAT-007-06`, `TST-ACC-BAT-102`, `TST-ACC-BAT-105`, `TST-ACC-BAT-106`	lifecycle	service	test services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#refuses voiding an invoice of a posted batch (batch_not_open), the invoice unchanged
`08`must prove Proposed	An issued invoice may be amended before posting subject to amendment and applied-money safeguards, while Posting and Posted batches reject that amendment. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-14 proved by `ATS-ACC-BAT-007-07`, `TST-ACC-BAT-031`	lifecycle	service, database	test react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0552.spec.ts#ACT-ACC-0552
`09`must prove Proposed	The recorded product decision permits date correction only before posting and keeps issued money, customer and payment method immutable. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-7 proved by `ATS-ACC-BAT-007-08`	invariant		documented services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-7
`10`must prove Proposed	Documents without an explicit batch use their unit’s assignment and must satisfy the same batch-intake checks. proved by `ATS-ACC-BAT-007-01`, `ATS-ACC-BAT-007-09`, `ATS-ACC-BAT-011-11`, `TST-ACC-BAT-026`, `TST-ACC-BAT-063`, `TST-ACC-BAT-074`	policy	service	test services-accounting:modules/batches/tests/integration/services/close/system-batch-guard.integration.spec.js#refuses the system batch as a default batch (BA-12)

Scenarios

Id	Given	When	Then	Provenance
`01`	An invoice belongs to an Open receivables batch.	Staff move it to another Open batch of the unit and post that target.	The invoice posts with its target batch and cannot subsequently leave it.	test react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0538.spec.ts#ACT-ACC-0538
`02`	An invoice belongs to a Posted batch.	Staff request a void.	The batch restriction refuses the void, leaving correction to an eligible memo or unposting workflow.	test services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#refuses the void of an invoice whose batch is posted, batch_not_open

Planning

Implementation

Place documents in eligible batches and protect posted work ​

Purpose ​

How It Works ​

Relationships ​