Subledger Entry
What It Is
A subledger entry records the account movements created by accounting work. It combines a header that identifies the context with lines that describe debits and credits. Staff use the entry to understand what a document contributed to the books and to trace that contribution back to its batch and posting. The entry is an accounting result, carrying both monetary values and the account choices recorded when the work occurred.
What It Is Not
An entry is not the invoice or payment that originated the accounting facts. Source documents retain customer-facing detail and their own business lifecycle. An entry is also not a mutable worksheet for correcting a posted amount. Corrections follow the applicable recovery or document workflow. A reporting row is a projection of an entry line rather than another stored accounting fact. A system reversal represents the fiscal reopening path and should not be used to infer how ordinary unposting retains ledger history.
How It Is Used
Staff open entries from a posted batch to inspect the accounting result. The header gives them the batch, posting and document context; the lines make each account movement visible. Document references let them return to the transaction that explains an amount. Account names and codes describe the choices captured by posting, which matters when configuration changes later. Fiscal placement lets staff connect the work to a period without losing the source document’s own date.
Readers can also use list filters and reporting to examine more than one collection. The reporting dataset exposes line-level values for reconciliation and analysis, while detail keeps the complete entry together. A recovery workflow can remove ordinary posting entries, so a reader must distinguish posting history from the presence of ledger rows. Fiscal reopening has its own retained originals and reversing entries, with reporting controls determining whether that history is included.
Its Facets
The header carries ownership, fiscal placement and document context. Lines carry account choices, their debit or credit side and optional product or organizational dimensions. Currency facets keep base-currency values alongside document-currency values, so readers can examine both accounting balance and foreign-currency context. Stored amounts preserve exact monetary representation; the reader presents useful money values.
The reversal facet identifies accounting records written by the system recovery path. The reporting facet supplies one row for an entry line with its readable account, batch and document context. These facets support investigation without making the report another owner of posting rules. The ledger-protection capability defines the constraints that preserve accounting records, and the reading capability defines the supported views.
How It Relates
Batch supplies the collection and fiscal context. Posting supplies the accounting operation that owns the entry. Revenue Recognition Schedule links fiscal recognition work to the scheduled amount that became earned. Account and product configuration come from their owning modules, while the entry retains the choices used for the posted result.
What It Could Become
The product should make the relationship between a source document, its posting history and the current entry easier to follow. It should explain why ordinary recovery can leave posting history without ledger rows and why system reversals appear only in the requested view. Those explanations should remain aligned with the verified recovery capabilities.