ADR: Accountant payment runs without durable batch entity

Status

Accepted

Date

2026-07-17

Context

Task 7 of the accountant exception workflow adds batch preview/approve for safe Ready payments. A durable AccountantPaymentRun entity was considered for progress after reload, API restart mid-run, partial-result recovery, and support/audit of a run.

Decision

Do not introduce a durable batch entity or EF migration for v1.

Batch runs are:

• previewed synchronously (POST /api/accountant-payment-runs/preview);
• approved synchronously per item via the existing single-item approve-and-queue path (AcceptRisk never true);
• correlated with a client-supplied correlationId used as the prefix of each item idempotency key ({correlationId}:{bankTransactionId}).

Partial results are returned in the approve response. Replay/double-submit is handled by per-item idempotency and existing posting/allocation state mapping (AlreadyQueued / AlreadyCompleted / Processing).

Consequences

• No new tables or migrations for batch runs.
• Support reconstructs outcome from individual allocations, postings, audit, and the correlation/idempotency keys.
• If a future need proves durable run progress across process restarts mid-HTTP-batch is required, revisit with a new ADR and EF migration policy compliance.

Alternatives considered

1. Persist AccountantPaymentRun + items — stronger recovery, higher operational cost, migration now without proven need.
2. In-memory-only run store — lost on restart; rejected for supportability.