---
id: CON-ACC-TRX-005
name: Customer Account
feature: FEAT-ACC-TRX-05
product_area: accounting
module: transactions
revision: 1
status: draft
product_intent: proposed
implementation_evidence: partially-observed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
definition: >-
  A customer account brings together a CRM party’s debt, held money, collection choices and dated financial
  standing without creating another customer identity.
owned_by: MOD-ACC-TRX
synonyms:
  - receivable account
  - customer balance
not_to_be_confused_with:
  - >-
    The CRM contact or organization record itself (owned by CRM; Accounting stores no copy beyond names
    snapshotted on documents)
  - 'An account in the chart of accounts (a ledger account, owned by Books)'
facets:
  - name: Open items
    meaning: Debt and held receipt or credit value form the account’s dated population.
    used_for: Supplying current and historical standing.
  - name: Financial summary
    meaning: 'Currency groups explain outstanding, overdue, held and net amounts today.'
    used_for: Answering customer balance questions.
  - name: Payable description
    meaning: Eligible payment choices include invoice targets and fee quotations.
    used_for: Preparing tender in settlement and checkout.
  - name: Customer terms
    meaning: A saved party override selects collection settings and default payment terms.
    used_for: Applying customer-specific collection choices.
  - name: Money from others
    meaning: Payer attribution separates value supplied by a different sender.
    used_for: Explaining whose money is held.
  - name: Month-end aging snapshot
    meaning: Versioned capture retains the month-end population known at cutoff.
    used_for: Supporting reproducible receivables review.
  - name: Expected remittances
    meaning: Order remitter references identify bills expected from another party.
    used_for: Preparing group receipt entry.
relationships:
  - to: CON-ACC-TRX-001
    statement: Outstanding invoices and their due dates explain debt and overdue value.
    provenance: observed
    source: 'services-accounting:modules/transactions/services/persistence/customer-summaries.ts'
  - to: CON-ACC-TRX-003
    statement: Receipt value contributes to the customer’s position with third-party attribution shown separately.
    provenance: test
    source: >-
      services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts the
      unapplied payments another party sent (a payer that is not the customer, or a payer known by name alone)
      again, and not the customer’s own
  - to: CON-ACC-TRX-004
    statement: Available credit reduces the customer’s net debt.
    provenance: observed
    source: 'services-accounting:modules/transactions/services/customers/customer-summary.ts'
  - to: CON-ACC-TRX-006
    statement: Receivable history supplies the dated facts behind each summary.
    provenance: test
    source: >-
      services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it
      agrees with the aging’s as-of read for the customer: the same open items, the same amounts
acted_on_by:
  - CAP-ACC-TRX-010
  - CAP-ACC-TRX-017
  - CAP-ACC-TRX-018
  - CAP-ACC-TRX-019
visible_to:
  - ACT-ACC-012
  - ACT-ACC-002
  - ACT-ACC-021
  - ACT-ACC-024
evidence:
  - >-
    services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: docs/accounting/customers.md,
    remittances.md; docs/snapshots/ar-aging.md; docs/architecture/accounting-2.0/02-decisions.md (A-16, D-06,
    C-9); modules/transactions/services/customers/*, invoices/invoice-payability.ts,
    persistence/customer-summaries.ts, parties.ts; db/customer-terms.table.ts, ar-snapshot-items.table.ts,
    ar-snapshot-totals.table.ts, expected-remittances.view.ts.
  - >-
    react-console at baf6dae382d6f41dce976c7f848667ccc37e076f: lib/accounting/transactions/types.ts (the
    customer position).
supersedes: []
---

# Customer Account

## What It Is

The customer account is Accounting’s financial view of one CRM contact or organization. It brings together outstanding invoices, available receipt money, available credit and any saved collection choices. Accounting does not create a second customer identity or store a single editable balance on that identity. It derives the position from the financial records and receivable history that its operations retain.

That view has a present and a historical use. Current standing answers what the customer owes and what Accounting holds for them today, grouped separately by currency. Month-end capture answers a different question: what the receivable position was at cutoff using information known then. A later-recorded transaction can affect the current view without appearing in the earlier published capture. This distinction lets finance explain both today’s balance and a previously reported month without changing the meaning of either.

## What It Is Not

The account is not a general ledger destination in the chart of accounts, nor a duplicate CRM record containing independently maintained names and affiliations. It is not a customer statement document. Current standing and payable description also have different jobs: one summarizes a party’s own position, while the other identifies eligible invoices a particular caller may pay. Their current contact and primary-organization populations do not fully agree, which staff must understand before treating them as interchangeable totals.

## How It Is Used

Staff answering a member inspect debt, overdue value and money held for later use. They follow an outstanding amount to its invoice or a held amount to its payment or credit. Settlement and Commerce ask for payable choices and applicable fee quotations. Finance reads published monthly aging for review and audit. Administrators can save customer-specific terms through the service; the dedicated staff editor is still missing. Good use distinguishes currency groups, cutoff date and the population included in the selected view.

## Its Facets

**Open items.** Outstanding bills and held payment or credit value form the financial population. Adjustments change those items rather than creating an independent customer balance to edit.

**Current summary.** Invoice counts, overdue value, receipt money, credit and net position describe today’s standing. Debt due today remains current until its due date passes.

**Payable description.** Eligible invoice choices include available tender methods and fee quotations. The current primary-organization inclusion explains why this list may exceed a contact’s own summarized debt.

**Customer terms.** One saved record supplies exceptions to default collection settings and payment terms. Whole-record replacement and version checks protect concurrent edits; removing the exception restores defaults.

**Money from others.** Payer information separates available value contributed by someone else without removing it from the total held for the customer. Employer remainder belongs to the employer’s own position.

**Monthly aging.** Capture retains open items, labels, aging categories and grouped totals. Publication validates the result, and rerunning produces another version while retaining the earlier one.

**Expected remittances.** Order-provided remitter information identifies bills an employer is expected to pay. Staff can use that population when recording an outside payroll receipt.

## How It Relates

Invoices provide debt, payments and credit provide held value, and shared transaction history supplies the dated evidence. CRM remains responsible for the party and its relationships. Books supplies financial configuration and Billing owns the later collection-plan behavior. The account view consumes those facts without assuming ownership of their source records.

## What It Could Become

The product should implement visible collection holds for payment plans and decide how contact standing relates to primary-organization debt. It should provide staff editing of customer terms and an authorized way to request historical reruns. Customer statements remain later work and should clearly declare their population, currency and cutoff rather than implying that every financial view already represents the same balance.
