---
id: ADR-ACC-BAT-006
title: Keep collection and ledger ownership in Batch Management
product_area: accounting
module: batches
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  The proposed internal boundary gives Batch Management control of collection
  configuration, posting generations and jobs, ledger entries and revenue plans,
  with in-process access for neighboring Accounting modules.
constrains:
  - RESP-ACC
  - SVC-ACC-BAT-batches
  - DOM-ACC-BAT-001
  - DOM-ACC-BAT-003
  - DOM-ACC-BAT-004
  - DOM-ACC-BAT-005
origin: >-
  The 2026-10-22 realignment (Andrew, final): ledger, subledger, batches,
  posting, close and reconciliation are Accounting's, recorded at
  services-accounting:docs/architecture/realignment-2026-10-22/ownership.md; the
  module boundary within Accounting is proposed by this design
alternatives:
  - option: Have Transactions generate the ledger during document issuance.
    why_not: >-
      That would conflict with the recorded batch-posting boundary and
      distribute accounting writers.
  - option: Give fiscal close an independent ledger writer.
    why_not: >-
      A second writer would duplicate generation, balance and immutable-row
      responsibilities.
consequences:
  - >-
    Posting also writes resolved-account snapshots on Transactions document
    lines within accounting execution.
  - Fiscal close consumes four transaction-required system-accounting functions.
  - >-
    Inter-unit account mappings are stored with this module, but their
    management writer remains unestablished.
supersedes: []
evidence:
  - >-
    services-accounting at f47cb263:
    docs/architecture/realignment-2026-10-22/ownership.md;
    modules/batches/services/close/index.ts;
    modules/transactions/services/batches-for-documents.ts
---

# Keep collection and ledger ownership in Batch Management

## Context

The recorded area realignment places financial records in Accounting. This design proposes the finer module boundary without treating the observed layout as approval.

## Decision

This record describes the proposed boundary in its decision field. Its observed implementation does not constitute Andrew’s approval.

## Alternatives Considered

The alternatives above identify the competing implementation choices and their consequences. They preserve the distinction between a recorded product ruling and a proposed engineering boundary.

## Consequences

The consequence rows describe obligations and known implementation limits at this boundary. Related artifact references retain the affected design homes.