Transaction Record
What It Is
A transaction record is the shared financial context around bills, adjustments, receipts, credit and coordinated money operations. It gives staff a way to identify an operation, inspect its customer and financial context, understand its posting placement and follow the history it produced. The individual document kind still determines its lifecycle and money effects. Shared treatment makes related records understandable together without requiring every kind to have identical fields or transitions.
Numbered financial documents use references separate from their internal identities. Draft invoices remain unnumbered, and quotes do not receive posting placement until conversion. Coordination records such as settlement explain how several resulting documents relate. Staff therefore need both the common record context and the particular kind’s meaning before interpreting a reference, a batch or a completed status as proof that money has moved.
What It Is Not
The record is not the posting batch or the general ledger entry. Batch management controls posting and the ledger it creates. A document’s retained customer label also does not replace CRM’s current party identity. Nor is an action list a permission grant: it describes what the current caller can attempt in the current state, and execution still checks the operation again. Audit history explains work already recorded rather than supplying an alternate editor or automatic undo.
How It Is Used
Staff locate records through the combined Transactions view or a kind-filtered entry page. They inspect the customer, standing and available value before choosing the next action. Permitted correction can update descriptive information or eligible posting placement. A protected state, invalid destination or intervening change can prevent the requested action. Reviewers use datasets and exports to inspect the same financial population without gaining authority to move money. Connected applications retain their retry identity so interrupted calls do not produce a second financial effect.
Its Facets
Reference. Kind-specific numbering supports customer conversations and review. A skipped number does not by itself establish a missing financial document, and preparation stages need not already have one.
Batch. Eligible posting placement groups financial work for review and posting. Supported movement preserves the same unit and stops at the posting boundary.
Business and accounting dates. Dates explain when the operation belongs in the financial history. Eligible correction retains opposing old-date and new-date entries instead of silently replacing earlier effects.
Receivable history. Signed facts reconstruct financial positions by business date and information cutoff. They supply current standing and monthly aging without maintaining a second editable customer balance.
Document events. Retained events identify actors, transitions and explanations. Their existence does not establish that staff can already read them through a public history screen.
Retry identity. Repeated work can return its earlier result or fail eligibility without another execution. Altering or changing ownership of the same identity does not authorize unrelated work.
Available actions. Current permissions, lifecycle and preconditions determine action choices. Disabled explanations help staff understand protection or access limits.
Protection. Supported record locks prevent the mutations they cover. They serve a different purpose from stale-version checks or posted-batch restrictions.
Datasets and exports. Query and export surfaces provide financial review under their own authorities and workspace context. Read access does not grant financial mutation.
How It Relates
Invoices, payments and credit supply the business content; customer-account views consume the resulting positions. Books and fiscal configuration provide context, while batch management owns posting. Commerce consumes order-line positions and configured change delivery. Platform provides routing, query infrastructure and the identities behind actors without taking ownership of Accounting’s documents.
What It Could Become
The product should expose retained activity on record pages and complete deferred settlement, reversal and dispute navigation. It should clarify payer and remitter visibility in reporting. Further routes also require a stack-capacity decision. These improvements should make existing financial evidence easier to use while keeping a document, its coordinated operation and its ledger effects distinguishable.