Skip to content

Last reviewed: 2026-07-29

Summary Accounting

Purpose

Summary accounting accepts reviewable period-summary facts from external operations so BooksPlus can account for sales and receivables, purchasing and payables, inventory, and banking and finance activity without owning the operational systems that produced that activity.

Canonical rules

  • Summary accounting records preserve period-summary facts for review before they affect the ledger.
  • Summary batches are workflow staging and review records, not formal report truth.
  • Summary batches must have a company-scoped, human-visible batch number for user-facing lookup, registers, exception messages, and drilldown labels.
  • Formal accounting reports derive from posted journal entries and current reporting rules, not summary batches or validation issues.
  • All ledger effects from summary accounting must post through Accounting.
  • Summary accounting must preserve source-system identity, external event identity, idempotency key, source-world dates, BooksPlus acceptance time, assigned summary batch number, validation issues, evidence links, review state, and resulting journal-entry references.
  • Summary batch numbers are assigned by BooksPlus intake, positive, immutable, unique within a company, and displayed as SA- followed by the company-scoped number padded to at least six digits, such as SA-000001.
  • Summary batch numbers are human-facing references and lookup values. They are not source-system identity, not part of normalized source meaning, and do not replace the durable internal batch id.
  • Mutating summary batch actions must emit batch-level audit events with target_type = summary_accounting_batch and target_id set to the durable summary batch id.
  • Summary batch audit event reason text must use the human-visible summary batch number, such as SA-000001, while durable identity remains in the audit event target id.
  • Summary preview and drilldown line displays must resolve account ids to visible account code and name for review; persisted preview and journal lines remain anchored to immutable account ids.
  • Summary posting-result displays must use the posted journal entry number, such as JE-000001, when the linked journal entry can be resolved. Durable posting-result links remain anchored to internal journal entry ids and audit event ids; unresolved journal entry links must display a shortened internal id rather than a full GUID.
  • Summary readiness evaluation must explain the current batch status, the permitted next state-machine transition, and why ready_to_post is allowed or blocked. Readiness reason codes are domain and presentation output, not persisted batch fields.
  • Summary readiness evaluation must expose a compact "why not ready" summary for user-facing review. The compact summary is derived domain/presentation output, not a persisted batch field, and complements detailed validation issues without replacing them.
  • Validation errors block staged -> ready_to_post; warnings require review but do not block that transition.
  • A user-facing workbench may combine approval and posting for a clean staged summary batch as Approve and Post, but only as application orchestration that first performs mark_ready: staged -> ready_to_post and then performs post: ready_to_post -> posted. The separate protected-action checks, audit events, status transitions, and central Accounting posting path must remain intact.
  • Summary posting workspaces must show an inline consequential-action preview before posting: source/evidence context, prepared journal-entry lines, totals, readiness result, and expected posted outcome.
  • Source Documents owns business evidence identity, references, and supersession.
  • Conflicting imports must not silently overwrite accepted meaning.
  • Corrections and reversals must be explicit; summary accounting must not silently mutate posted accounting records or accepted source evidence.
  • Sales-tax-bearing Sales facts must follow the Sales Tax Accounting and Remittance Contract. Seller-owned tax posts through the Sales template; facilitator- or statutory-collector-remitted tax remains non-ledger support and is excluded from seller receivable and Sales Tax Payable.

Deferred work

  • Sales and Receivables Summary fact and posting-template meaning is defined by accepted ADRs 0021 and 0024.
  • Purchasing and Payables Summary fact and posting-template meaning is defined by accepted ADR 0024 and its canonical contract; contractor and 1099 meaning remains assigned to its separate truth slice.
  • Inventory Summary fact and posting-template meaning is defined by accepted ADR 0028 and its canonical contract.
  • Banking and Finance Summary fact, posting-template, relationship, statement-match, and reconciliation meaning is defined by accepted ADRs 0024 and 0029 and its canonical contract.
  • BillCatcher and the entire capital-project and fixed-asset lifecycle are deferred beyond the initial release.
  • Provider-specific adapters, mailbox intake, binary evidence artifact storage, corrections, close, reports, and report persistence are separate workflow slices.

Developer implications

  • Treat summary accounting as workflow intake and review state.
  • Keep provider-specific vocabulary outside summary accounting contracts.
  • Validate source identity and idempotency before accepting machine or file intake as ordinary meaning.
  • Assign summary batch numbers through the central intake path only when a new batch is created; idempotent replay must return the existing batch number.
  • Do not include assigned summary batch numbers in normalized meaning hashes or source identity comparisons.
  • Let summary workflows prepare posting requests, but require the central Accounting posting path to accept or reject ledger effects.
  • Preserve batch-level audit events for summary workflow actions separately from journal-entry audit events created by central Accounting posting.
  • Display account code and name in summary preview and drilldown line details; do not replace stored account identity with account code.
  • Display linked posted journal entry numbers in summary posting results when available; do not replace persisted posting-result journal entry ids.
  • Use readiness reason codes to drive user-facing next-action text, while preserving batch status as the persisted workflow state.
  • Use compact readiness blocker summaries for scanning registers and drilldown; keep detailed validation issues available for review.
  • Treat Approve and Post as a workbench convenience over existing summary readiness and posting services, not as a new persisted status or domain transition.
  • Link business evidence through Source Documents rather than defining a separate evidence identity model.
  • ../contracts/accounting-import-run.contract.md
  • ../contracts/summary-accounting-batch.contract.md
  • ../contracts/purchasing-and-payables-summary-fact.contract.md
  • ../contracts/inventory-period-summary-fact.contract.md
  • ../contracts/banking-and-finance-summary-fact.contract.md
  • ../contracts/sales-tax-accounting-and-remittance.contract.md
  • ../contracts/source-document.contract.md
  • ../contracts/journal-entry.contract.md
  • ../contracts/financial-period.contract.md
  • ../decisions/accepted/0007-provider-agnostic-import-boundaries.md
  • ../decisions/accepted/0020-initial-release-scope-and-financial-workflow-taxonomy.md
  • ../decisions/accepted/0021-income-accounting-facts-and-templates.md
  • ../decisions/accepted/0022-reviewable-accounting-file-intake.md
  • ../decisions/accepted/0024-operational-summary-workflow-boundaries-and-purchasing-facts.md