---
id: CON-ACC-TRX-006
name: Transaction Record
feature: FEAT-ACC-TRX-06
product_area: accounting
module: transactions
revision: 1
status: draft
product_intent: proposed
implementation_evidence: observed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
definition: >-
  A transaction record provides shared identity, financial context, applicable posting placement and history
  while each document kind retains its own lifecycle.
owned_by: MOD-ACC-TRX
synonyms:
  - financial transaction
  - document
not_to_be_confused_with:
  - 'A batch (the container transactions post in, owned by batch management)'
  - 'A ledger entry (what posting writes from a transaction, owned by batch management)'
facets:
  - name: Number
    meaning: Applicable numbered documents receive stable kind-specific references starting at one million.
    used_for: Identifying retained financial documents.
  - name: Batch
    meaning: Eligible posting placement groups records within a business unit.
    used_for: Supporting review and posting.
  - name: Document and accounting dates
    meaning: Business and accounting dates locate eligible financial effects in time.
    used_for: Explaining the period and later date corrections.
  - name: Receivable entries
    meaning: Signed facts reconstruct monetary position by date and information cutoff.
    used_for: Supporting summaries and historical capture.
  - name: Document events
    meaning: Retained append-only events describe attributed commands and transitions.
    used_for: Preserving audit explanation.
  - name: Repeat-safe key
    meaning: A workspace command identity protects against duplicate execution.
    used_for: Retrying interrupted work safely.
  - name: Record actions
    meaning: Current authority and standing determine permitted transitions and disabled explanations.
    used_for: Choosing supported next work.
  - name: Lock
    meaning: Owner protection restricts update or deletion according to its setting.
    used_for: Safeguarding records under review.
  - name: Datasets and exports
    meaning: Query and export projections expose financial populations with their own authority.
    used_for: Supporting staff discovery and financial review.
relationships:
  - to: CON-ACC-TRX-001
    statement: Invoices participate as a financial document kind.
    provenance: observed
    source: 'services-accounting:modules/transactions/db/transactions.view.ts'
  - to: CON-ACC-TRX-003
    statement: Receipt and coordinated-operation records retain their respective financial kinds.
    provenance: observed
    source: 'services-accounting:modules/transactions/db/transaction-kind.views.ts'
  - to: CON-ACC-TRX-005
    statement: Customer standing and aging reconstruct position from receivable history.
    provenance: test
    source: >-
      services-accounting:modules/transactions/tests/integration/services/invoices/as-of.integration.spec.js#it
      answers, as of today and known now, exactly the live balance of every open invoice (FC-07)
acted_on_by:
  - CAP-ACC-TRX-001
  - CAP-ACC-TRX-002
  - CAP-ACC-TRX-006
  - CAP-ACC-TRX-015
  - CAP-ACC-TRX-016
  - CAP-ACC-TRX-020
visible_to:
  - ACT-ACC-012
  - ACT-ACC-002
  - ACT-ACC-021
  - ACT-ACC-022
evidence:
  - >-
    services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: docs/accounting/record-actions.md,
    queries.md, change-events.md, invoices.md and payments.md (the key rule);
    docs/architecture/accounting-2.0/02-decisions.md (D-01, D-04, A-6, A-7, M4-6);
    modules/transactions/db/transactions.view.ts, transaction-kind.views.ts, document-events.table.ts,
    receivable-events.table.ts; services/actions/*, services/document-edits/*,
    services/batches-for-documents.ts.
  - >-
    react-console at baf6dae382d6f41dce976c7f848667ccc37e076f:
    app/(console)/console/[tenantId]/accounting/transactions/page.tsx;
    components/accounting/transactions/transactions-explorer.tsx; journeys ACT-ACC-0186, 0191, 0205, 0206,
    0212, 0217, 0807.
supersedes: []
---

# 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.