Rhythm 2.0 Specifications

Appearance

CAP-ACC-REC-014Carry reconciliation accounting through operational posting

Markdown

CAP-ACC-REC-014

Carry reconciliation accounting through operational posting

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

Planning

Feature
FEAT-ACC-REC-03
Exercised by
FAS-ACC-REC-03-01, FAS-ACC-REC-03-02, FAS-ACC-REC-03-03, FAS-ACC-REC-03-05, JNY-ACC-REC-001, JNY-ACC-REC-005
Key concepts
CON-ACC-REC-003
Actors
ACT-ACC-011, ACT-ACC-018
Journeys
JNY-ACC-REC-003
Related
CAP-ACC-REC-007, CAP-ACC-REC-011, CAP-ACC-REC-013, CAP-ACC-REC-018
Proved by
ATS-ACC-REC-014

Implementation

Executable suites
TST-ACC-REC-021, TST-ACC-REC-044, TST-ACC-REC-045, TST-ACC-REC-051, TST-ACC-REC-067, TST-ACC-REC-068, TST-ACC-REC-091

KindCapabilityProduct areaAccountingModuleReconciliationRevision2

Read atservices-accounting f47cb263

Carry reconciliation accounting through operational posting ​

Purpose ​

The system needs reconciliation’s accounting effects to use the established batch-posting path.

How It Works ​

Finalization, reversal or write-off produces an accounting request. Rhythm assigns the request to the operational batch selected by accounting policy. Batch posting creates its ledger entries, while reconciliation derives whether those entries are currently posted. Unposting makes the request pending again rather than rewriting its financial history. Missing batches, closed periods or unsupported currency exponents stop request creation.

Relationships ​

Reconciliation decisions produce requests, Books supplies accounts, Batch Management posts them and readiness reports pending accounting.

The Formal Contract

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

Outcomes
Distinct effect keys protect each requested accounting movement.Staff can distinguish current posted entries from pending requests.
Surfaces
job
Intent sources
services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D7services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D2services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D10 (§4: the architecture §6 invariants hold; INV-11, INV-12, INV-16)services-accounting:docs/reconciliation/brief.md#Accounting (Andrew’s product brief, 2026-10-15): reconciliation must not become a second ledger

Controls

21 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-DAT-001 TC-DAT-004 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 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: 11 confirmed by a product decision, the rest inheriting this capability's confirmed.

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Ledger requests join the operational batch selected by the unit’s default assignment for that merchant, and fail without writes when the batch cannot accept work or its period is closed.
origin: services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D7
proved by ATS-ACC-REC-007-11, ATS-ACC-REC-007-12, ATS-ACC-REC-014-01, ATS-ACC-REC-014-10, ATS-ACC-REC-014-14, TST-ACC-REC-067
policyservicetest
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#refuses a unit with no open batch for its requests (400, `no_open_batch`), writing nothing; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#answers the request as stored: in the unit’s open batch, on its date, the document date kept, its lines with their roles; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#assigns the batch the default-batch rule gives the unit and merchant account; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#asks for no batch when there is no plan: a unit with none answers nothing, not a refusal
02must prove
Confirmed
Request accounting dates follow the operational batch, document dates preserve the original effect and lines distinguish bank, clearing, fee, reserve, adjustment and write-off roles.
origin: services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D10 (§4: the architecture §6 invariants hold; INV-16)
proved by ATS-ACC-REC-007-11, ATS-ACC-REC-007-12, ATS-ACC-REC-014-01, ATS-ACC-REC-014-10, ATS-ACC-REC-014-14, TST-ACC-REC-067
calculationservicetest
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#answers the request as stored: in the unit’s open batch, on its date, the document date kept, its lines with their roles; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#assigns the batch the default-batch rule gives the unit and merchant account; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#refuses a unit with no open batch for its requests (400, `no_open_batch`), writing nothing; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#asks for no batch when there is no plan: a unit with none answers nothing, not a refusal
03must prove
Confirmed
An effect generating no posting plan needs no operational batch, including a zero transfer without fees.
proved by ATS-ACC-REC-007-11, ATS-ACC-REC-007-12, ATS-ACC-REC-014-01, ATS-ACC-REC-014-10, ATS-ACC-REC-014-14, TST-ACC-REC-067
policyservicetest
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#asks for no batch when there is no plan: a unit with none answers nothing, not a refusal; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#answers the request as stored: in the unit’s open batch, on its date, the document date kept, its lines with their roles; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#assigns the batch the default-batch rule gives the unit and merchant account; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#refuses a unit with no open batch for its requests (400, `no_open_batch`), writing nothing
04must prove
Confirmed
Requests are append-only, remain within one unit, balance by currency and contain one to twenty lines with exactly one debit or credit side each.
origin: services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D10 (§4: the architecture §6 invariants hold; INV-11)
proved by ATS-ACC-REC-014-02, TST-ACC-REC-044, TST-ACC-REC-045
invariantdatabasetest
services-accounting:modules/reconciliation/tests/integration/db/reconciliation-postings.table.integration.spec.js#refuses at commit a posting whose debits and credits differ in USD (RHF36); services-accounting:modules/reconciliation/tests/integration/db/reconciliation-postings.table.integration.spec.js#commits a balanced posting with its two lines (premise of the refusals); services-accounting:modules/reconciliation/tests/integration/db/reconciliation-postings.table.integration.spec.js#refuses at commit a posting with no lines (RHF36); services-accounting:modules/reconciliation/tests/integration/db/reconciliation-posting-lines.table.integration.spec.js#refuses position 21, so a posting has at most 20 lines; services-accounting:modules/reconciliation/tests/integration/db/reconciliation-posting-lines.table.integration.spec.js#refuses a line with both a debit and a credit; services-accounting:modules/reconciliation/tests/integration/db/reconciliation-postings.table.integration.spec.js#refuses the owner an UPDATE, by the append-only trigger (RHF32); services-accounting:modules/reconciliation/tests/integration/db/reconciliation-posting-lines.table.integration.spec.js#refuses the owner a DELETE outside a tenant purge, by the append-only trigger (RHF32)
05must prove
Confirmed
Each accounting effect uses a workspace-unique key that distinguishes finalization, reversal, write-off and successive item recognitions.
origin: services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D10 (§4: the architecture §6 invariants hold; INV-11)
proved by ATS-ACC-REC-014-03, TST-ACC-REC-045, TST-ACC-REC-091
invariantdatabasetest
services-accounting:modules/reconciliation/tests/integration/db/reconciliation-postings.table.integration.spec.js#refuses an event key the tenant already has; services-accounting:modules/reconciliation/tests/unit/rules/posting-plans.spec.js#appends :reverse to a recognition’s key; services-accounting:modules/reconciliation/tests/unit/rules/posting-plans.spec.js#numbers a second recognition after a reversal
06must prove
Confirmed
Bank and clearing lines use their bank and merchant ledger accounts, while fees, reserves and write-offs resolve the unit’s purpose defaults.
origin: services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D2
proved by ATS-ACC-REC-014-04, TST-ACC-REC-091
calculationservicetest
services-accounting:modules/reconciliation/tests/unit/rules/posting-plans.spec.js#takes a fee’s counter-account from processor_fee_expense; services-accounting:modules/reconciliation/tests/unit/rules/posting-plans.spec.js#takes a reserve release’s counter-account from processor_reserve_receivable; services-accounting:modules/reconciliation/tests/unit/rules/posting-plans.spec.js#debits the bank and credits clearing for a positive payout; services-accounting:modules/reconciliation/tests/unit/rules/posting-plans.spec.js#debits the write-off account and credits clearing for a positive item never paid out
07must prove
Confirmed
Posted status is calculated from an unreversed batch posting containing the request’s reconciliation entry; reversing that posting makes the request pending again.
origin: services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D7
proved by ATS-ACC-REC-010-13, ATS-ACC-REC-014-05, ATS-ACC-REC-014-11, ATS-ACC-REC-014-12, TST-ACC-REC-051, TST-ACC-REC-068
calculationservicetest
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#is posted when an unreversed batch posting holds its reconciliation entry; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#is not posted when the batch posting holding its entry was reversed; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#is not posted by an entry of another transaction type naming its id; services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#writes the transfer, the fee and the reserve as balanced reconciliation entries on the accounts of the example; services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#deletes the entries, empties the clearing account and makes the three requests pending again; services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#writes the same entries when the batch is posted again
08must prove
Confirmed
Operational batch posting creates the reconciliation entries, one per request, and unposting removes those entries; reconciliation does not post directly.
origin: services-accounting:docs/milestones/plans/ACCT-M8-plan.md#D7
proved by ATS-ACC-REC-010-13, ATS-ACC-REC-014-05, ATS-ACC-REC-014-09, ATS-ACC-REC-014-11, ATS-ACC-REC-014-12, ATS-ACC-REC-014-13, TST-ACC-REC-021, TST-ACC-REC-051, TST-ACC-REC-068
policyservicetest
services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#writes the transfer, the fee and the reserve as balanced reconciliation entries on the accounts of the example; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#is posted when an unreversed batch posting holds its reconciliation entry; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#is not posted when the batch posting holding its entry was reversed; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#is not posted by an entry of another transaction type naming its id; services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#deletes the entries, empties the clearing account and makes the three requests pending again; services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#writes the same entries when the batch is posted again; react-console:acceptance/accounting/playwright/journeys/reconciliation-close/ACT-ACC-0627.spec.ts#ACT-ACC-0627
09must prove
Confirmed
Posting requests support two-decimal currencies only and reject other exponents without writes until batch posting supports minor units.
proved by ATS-ACC-REC-014-06, TST-ACC-REC-067
validationservicetest
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#refuses a currency whose exponent is not 2 (409, `unsupported-currency-exponent`), writing nothing; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#refuses a three-decimal currency the same way
10must prove
Confirmed
Pending batch requests are read in creation order with event-key tie breaking and pages capped at five hundred.
proved by ATS-ACC-REC-014-07, TST-ACC-REC-068
policyservicetest
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#answers the batch’s requests not posted, oldest written first, then by event key; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#refuses a limit of 0; services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.queries.integration.spec.js#refuses a limit above 500
11must prove
Confirmed
Request creation requires the causing command’s transaction, and its operational batch cannot be deleted while the request refers to it.
proved by ATS-ACC-REC-014-08, TST-ACC-REC-045, TST-ACC-REC-067
invariantservice, databasetest
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#refuses to record outside the command’s transaction; services-accounting:modules/reconciliation/tests/integration/db/reconciliation-postings.table.integration.spec.js#is not deleted while the posting rides in it

Scenarios

IdGivenWhenThenProvenance
01Three approved requests are assigned to an open operational batch.Post that batch.Three balanced reconciliation entries leave no request pending.test
services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#leaves no request pending: each is posted
02Those operational entries are posted.Unpost the batch.Entry removal makes the requests pending and reverses the example’s clearing effect.test
services-accounting:modules/reconciliation/tests/integration/services/batch-lifecycle/finalize-posts-to-subledger.integration.spec.js#deletes the entries, empties the clearing account and makes the three requests pending again

Edge Cases

IdGivenWhenThenProvenance
03The merchant settles in yen.Create a required posting request.Unsupported exponent refusal leaves no written request.test
services-accounting:modules/reconciliation/tests/integration/services/persistence/reconciliation-ledger-postings.integration.spec.js#refuses a currency whose exponent is not 2 (409, `unsupported-currency-exponent`), writing nothing

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software