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.