--- id: CON-ACC-BAT-003 name: Posting feature: FEAT-ACC-BAT-03 product_area: accounting module: batches revision: 1 status: draft product_intent: proposed implementation_evidence: observed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: Posting is the accounting work and retained history that connect a batch’s eligible documents to ledger entries and applicable recognition schedules. owned_by: MOD-ACC-BAT synonyms: - batch posting - posting run not_to_be_confused_with: - Document issuance before ledger generation - External accounting delivery facets: - name: Asynchronous work meaning: Represents posting or recovery as a watched job with visible stages. used_for: Following execution after the request returns. - name: Request equivalence meaning: Combines the scoped operation, selected batches and submission key. used_for: Reusing the existing job for equivalent requests. - name: Generation check meaning: Examines generation problems without applying every execution eligibility guard. used_for: Reviewing validation results with their limits understood. - name: Resolved account snapshot meaning: Retains account choices, resolution time and method on posted document facts. used_for: Tracing later corrections to the original account choices. - name: Accounting history meaning: Retains the posting and any later unposting identity and time. used_for: Distinguishing current accounting work from earlier attempts. - name: Failure context meaning: Connects document problems to related batch dependencies. used_for: Identifying corrections and ordering accounting work. - name: Ordinary recovery meaning: Takes back eligible ordinary posting work and its open schedules. used_for: Correcting the collection before submitting a fresh posting. - name: Scheduled submission meaning: Requests accounting work after a scheduled retirement or roll. used_for: Completing accounting without a staff submission. relationships: - to: CON-ACC-BAT-001 statement: The batch supplies the collection that accounting work attempts to complete. provenance: test source: services-accounting:modules/batches/tests/unit/rules/batch-repost-rules.spec.js#admits an open, a closed and an errored batch - to: CON-ACC-BAT-004 statement: Posting owns the applicable document entries, and ordinary recovery removes those ledger rows. provenance: test source: services-accounting:modules/batches/tests/integration/services/posting/unpost-deletes-entries.integration.spec.js#deletes the batch’s entries and their lines, and tells how many entries - to: CON-ACC-BAT-005 statement: Deferral plans originate with applicable posting work and open plans are voided through ordinary recovery. provenance: documented source: services-accounting:docs/accounting/batches.md#Unposting deletes the entries (Andrew, Reporting D7, 2026-10-21) lifecycle: - state: submitted meaning: Execution has been requested but has not started. how_it_changes: The job runner begins the work. - state: running meaning: Execution is checking and writing accounting results. how_it_changes: Successful completion or a refusal ends the run. - state: current meaning: The posting is the batch’s active accounting result. how_it_changes: Authorized unposting takes back ordinary accounting work. - state: reversed meaning: The retained history marks accounting work that was taken back. how_it_changes: A later posting creates a separate historical record. acted_on_by: - CAP-ACC-BAT-005 - CAP-ACC-BAT-012 - CAP-ACC-BAT-013 - CAP-ACC-BAT-014 - CAP-ACC-BAT-015 - CAP-ACC-BAT-016 visible_to: - ACT-ACC-006 - ACT-ACC-007 - ACT-ACC-012 evidence: - 'Examined pinned services-accounting (f47cb263): services/jobs/**, services/engine/**, services/preview/**, services/rules/posting-*.ts, db/batch-posting-jobs.table.ts, db/batch-postings.table.ts, aws/logic/batch-posting.step-functions.ts; docs/accounting/batches.md, docs/migrations/batch-posting/README.md, DESIGN.md; docs/architecture/accounting-2.0/02-decisions.md (D-03, A-1 to A-4), 08-batch-posting.md.' - 'Examined pinned react-console (baf6dae3): components/accounting/batches/batch-posting-panel.tsx, batch-validation-card.tsx, batch-posting-breakdown.tsx; acceptance inventory CAP-ACC-BAT-008 to 012, 019.' supersedes: [] --- # Posting ## What It Is Posting connects a collection of accounting documents to its ledger result. The term describes both the work that creates that result and the durable history of an attempt that succeeds. Staff encounter a request, a progress experience and a completed accounting record rather than a long page submission with no visible outcome. The batch remains the collection being processed; posting records what accounting work occurred for it. ## What It Is Not Issuing a document does not itself establish the batch’s ledger result. A preview is also distinct from a completed posting: it examines generation problems without creating the lasting accounting records. Posting does not include delivery to an external general ledger in this planning layer. Ordinary unposting and fiscal reopening are separate recovery paths, even though both affect whether earlier accounting work remains current. Readers should follow their respective capabilities rather than assume they share a single reversal model. ## How It Is Used A staff member reviews a batch, addresses missing setup and submits accounting work when appropriate. The progress panel helps them follow the request after submission. Scheduling can request the same accounting work when an automatic close or roll retires a collection. Administrators use unposting when ordinary posted work needs correction and the recovery safeguards permit it. The retained history lets staff distinguish a current result from an earlier attempt that was subsequently taken back. Errors have practical value beyond announcing failure. They identify the affected documents or configuration so staff can ask the right owner to correct the prerequisite. Dependencies explain why a later collection cannot be treated independently of the source transactions it uses. A successful retry should therefore be understood as new accounting work following a correction, rather than a change to the original ledger lines in place. ## Its Facets The job facet describes asynchronous execution and visible progress. Submission identity describes how repeated requests relate to existing work. Preview describes generation checks and their limits; it must not imply every execution safeguard has been applied. Account snapshots retain the resolved choices used when documents post, making later corrections traceable to those choices. Posting history connects batches to current and earlier accounting results. Error and dependency facets describe the relationships that affect completion. Unposting describes recovery of ordinary posted batches. Automatic posting describes work requested by scheduling without a staff submission. These facets belong together because they explain the lifecycle of accounting work, while their precise eligibility and write behavior remain in the capabilities. ## How It Relates Batch supplies the collection, accounting date and business-unit context. Subledger Entry records the resulting account movements. Revenue Recognition Schedule records future releases of deferred amounts. Products and Books supply configuration that account resolution consumes. Fiscal close supplies a separate system posting and reopening workflow; Platform supplies the surrounding durable-job experience. ## What It Could Become The product should make preview limitations visible enough for staff to interpret readiness accurately. It should also distinguish a repeated request from a new recovery attempt in progress and history. Decisions about status eligibility and recovery evidence need resolution before those refinements become approved design.