Accounting Responsibilities
How the Product Area Is Divided
Accounting keeps an association's financial records and the configuration behind them. Books holds the business units, the chart of accounts and the other reference records everything else points at. Products holds the shared catalogue of what is sold, with its prices, selling settings and accounting treatment. Transactions holds invoices, memos, payments and the other documents; Batch Management groups and posts them; Reconciliation and Month-end Close check and close the books. Only the Products module has a design so far; the others are named so the boundary is clear and each gets its own section when its design is drafted.
Products
Products maintains the common catalogue record, registered kinds, price grids, accounting setups and workspace tax defaults for each kind. Its service declares 18 HTTP operations and three database functions, including the public health operation and the functions domains use within their own transactions. The service contract identifies their individual authorization boundaries. No event publication is declared.
The cited invariants state both requirements and enforcement limits. Local product rows and collections share a transaction; Platform confirmation content commits independently and has no implemented compensation. Reference validation distinguishes unit-owned accounts and dimensions, workspace-wide tax classes and explicitly named other-unit accounts. Application and kind checks restrict domain writes. Bundle validation does not serialize the entire graph, and price changes do not revalidate existing fixed revenue shares. Product metadata declares no custom-field support. Preservation of previously posted accounts is documented downstream behavior, rather than a guarantee enforced by setup saving.
Products stores purchase configuration but delegates its execution through the concerns above. Unverified downstream execution, audit requirements and remote recovery remain recorded in the module findings and workflows.
Month-End Close
Close controls the closing fields on the calendar’s existing periods. It owns readiness evaluation, accepted requests, durable job records and immutable closing snapshots. Books continues to own the calendar records themselves.
The service exposes ten operations for calendar review, readiness, authority, close and reopen submission, request history, recovery and retained evidence. Six named event types belong to job history. The examined module does not publish them on the event bus.
A period lock coordinates changing work and postings into the same month. Acceptance retains the request with its first job. Financial steps retain their output with their transaction, and successful finalization captures the closed state and snapshot together. Neighbouring-month sequence checks do not lock the neighbouring periods, and failure recovery reads the run before taking the period lock. Job events and calendar generation have separate commit boundaries.
The findings retain the remaining qualifications: aging can hold up finalization, command comparison omits the requester, committed recognition restricts cancellation, execution can remain stranded, and deployment shares other Accounting functions. Recovery and evidence should be assessed with those limits before implementation preparation.
Batch Management
Batch Management owns the domain objects listed in its module row and exposes the aligned service operations. Its collection configuration supports intake, while posting generations connect reviewed documents to ledger results and revenue plans. Posting writes account-resolution snapshots on Transactions lines within the accounting transaction.
The guarantees reference their domain-object homes rather than creating additional rules here. Their limits include response-only first-batch refusal, unproved dependent recovery, missing job reconciliation, post-commit settlement failure, incomplete history and external delivery, and disputed historical export semantics. Current operations have no examined Submissions binding.
Allocation of Responsibility
Books maintains shared accounting configuration. Products maintains saleable definitions and their financial setup; Batches performs posting; Transactions maintains financial documents; Close moves period standing; Reconciliation handles settlement and payouts. Billing owns its business orchestration as a separate application. The present responsibility row covers Books, with other module rows awaiting their own design.
Books, Business Units and Chart of Accounts
Books owns unit setup, charts, calendars, document content and workspace definitions and settings. Its configuration service exposes the maintained records and global vocabularies. Its maintenance service provides shared scheduling and registers lifecycle participation across Accounting. Close and Reconciliation write their assigned fields, and participant code provisions or erases lifecycle data.
Creation and collection replacement have atomic database boundaries. Declared founding fields and references have database protection; not every soft reference has that protection. Ordinary replacements require the loaded version, while default-purpose writes do not. An occurrence has one history row, but unfinished handlers may run repeatedly. The detailed guarantees and limitations are recorded in the owning design contracts.
Delegated Work and Open Boundaries
Platform owns access decisions, workspace lifecycle orchestration, provider secrets, query execution and console hosting. Close owns period standing, Batches owns posting, Transactions owns document production and Reconciliation owns settlement. Billing’s recurring preparation is still timed here. The recorded Commerce realignment leaves an unresolved transfer of editable tax configuration. Configuration history is proposed without an adopted implementation or delegated contract.
Reconciliation
Reconciliation owns the five domain objects named in its module row: deposits, outstanding settlement effects, deposit explanations, investigations and period readiness. Supporting records retain holdings, accounting requests, evidence and activity within that service boundary.
Its operation inventory matches the service contract. The console uses a subset of those operations, while Transactions records settlement effects in its financial transaction, Batch Management consumes accounting requests, and Close requests readiness. Attention items, activity records and scheduled occurrences remain distinct integrations.
The referenced invariants retain each guarantee in its domain-object home. Their qualifications include unversioned supplemental commands, readiness that does not freeze every assessed record, accounting requests awaiting posting and disabled attention delivery. The shared request-key store also supports commands from other Accounting modules without transferring ownership of those commands.
Transactions
Transactions owns customer billing and its correction documents, receipts and their collection and return records, credit grants and applications, saved customer terms, historical aging and the shared financial facts and history. Its service contract exposes console operations, separately granted Commerce capabilities and processor event handling. The pinned billing function also retains legacy installment operations despite the target Billing ownership boundary.
The object invariants and service consistency rows identify its financial protections. Database maintenance bounds ledger-derived amounts, while keyed command transactions and conditional external-outcome recording protect retry effects. Those protections have explicit limits: history-event counts vary, communication uses a different deduplication mechanism, snapshot chunk cleanup is unproved, and credit reservations affect availability without determining status.
Batch management resolves posting accounts and writes the subledger. Transactions checks accounting and lifecycle eligibility and supplies the financial documents posting consumes. Staff-billing tax ownership, partial chargebacks, console delivery of approved amendment, document-lock ownership and externally transmitted refund reasons still need resolution. The examination also identifies settlement credit restrictions and charge-reference recovery as disagreements with planning that must be reconciled before implementation preparation.
What Is Delegated to Platform and Other Areas
Platform stores and validates the product's own confirmation template and sends messages, registers the product object's metadata, evaluates permissions, and runs workspace export and purge. Commerce evaluates prices, realises migrated audiences and will own product tax classification after the transfer; Orders applies the selling settings at purchase. CRM owns the task types and queues task instructions name. Domain applications own their extension records. Record history and change events are not yet provided for products and await a product decision.