--- id: CON-ACC-PRD-004 name: Accounting Setup feature: FEAT-ACC-PRD-04 product_area: accounting module: products revision: 3 status: draft product_intent: proposed implementation_evidence: observed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- An accounting setup records the product-specific accounts, dimensions and allocation instructions available to later financial processing. owned_by: MOD-ACC-PRD synonyms: - Financial configuration - Product account assignments not_to_be_confused_with: - A posted financial entry - The chart of accounts - A purchase-time price facets: - name: Account slots meaning: 'Named account slots express receivable, revenue, deferral, write-off, cost and inventory purposes.' used_for: Selecting appropriate accounts in the product’s unit. - name: Dimensions and merchant account meaning: 'Department, project and merchant references retain analytical and routing choices.' used_for: Keeping financial dimensions and routing with the product. - name: Revenue recognition meaning: 'Immediate, automatic, fixed-date and relative-date strategies describe revenue timing.' used_for: Defining valid recognition instructions and schedule coverage. - name: Revenue splits meaning: Percentage or fixed shares allocate revenue to other income accounts. used_for: Distributing value within percentage and price limits. - name: Inter-entity accounts meaning: Other-unit entries identify that unit’s receivable and liability references. used_for: Supporting sales processed in another business unit. - name: Tax class meaning: A setup class takes precedence in current tax resolution. used_for: Assigning product-specific tax treatment during the transfer. - name: Kind default tax class meaning: A kind default supplies a class when a product has no own assignment. used_for: Providing a workspace-wide classification fallback. - name: Lock and version meaning: Separate setup protection and read versions control replacement and deletion. used_for: Keeping financial correction deliberate and concurrent edits detectable. relationships: - to: CON-ACC-PRD-001 statement: The product owns its financial setup in its fixed business unit. provenance: observed source: 'services-accounting:modules/products/db/product-accounting-setups.table.ts' - to: CON-ACC-PRD-002 statement: Fixed revenue allocations are limited by the product’s standard base-currency price. provenance: test source: >- services-accounting:modules/products/tests/integration/services/persistence/product-accounting-setups.integration.spec.js#refuses fixed amounts adding up to more than the standard base price acted_on_by: - CAP-ACC-PRD-015 - CAP-ACC-PRD-016 - CAP-ACC-PRD-017 - CAP-ACC-PRD-018 visible_to: - ACT-ACC-006 - ACT-ACC-007 - ACT-ACC-008 - ACT-ACC-009 - ACT-ACC-011 evidence: - 'react-console:components/accounting-config/products/inter-entity-accounts-editor.tsx' - 'react-console:components/accounting-config/products/product-accounting-section.tsx' - 'react-console:components/accounting-config/products/product-gl-accounts-card.tsx' - 'react-console:components/accounting-config/products/revenue-recognition-editor.tsx' - 'react-console:components/accounting-config/products/revenue-splits-editor.tsx' - 'react-console:components/configuration/tax/product-type-tax-classes-panel.tsx' - 'react-console:lib/accounting-config/product-accounting-rules.ts' - 'services-accounting:docs/accounting/products.md' - 'services-accounting:docs/milestones/plans/ACCT-M1-plan.md' - 'services-accounting:docs/milestones/plans/ACCT-realignment-2026-10-22.md' - 'services-accounting:modules/products/db/product-accounting-children.table.ts' - 'services-accounting:modules/products/db/product-accounting-setups.table.ts' - 'services-accounting:modules/products/db/product-type-tax-classes.table.ts' - 'services-accounting:modules/products/services/persistence/product-accounting-setups.ts' - 'services-accounting:modules/products/services/persistence/product-type-tax-classes.ts' - 'services-accounting:modules/products/services/rules/product-rules.ts' - >- services-accounting:modules/products/tests/integration/services/persistence/product-accounting-setups.integration.spec.js supersedes: - react-console acceptance inventory CAP-ACC-PRD-014 - react-console acceptance inventory CAP-ACC-PRD-016 --- # Accounting Setup ## What It Is An accounting setup describes a product’s financial treatment. It identifies the accounts and dimensions finance wants later posting to use, explains any revenue deferral, and can allocate shares to other accounts or supply accounts for sales in another business unit. The setup belongs to one product and retains that product’s unit as its financial context. This is optional configuration. A product can exist with no setup, and the recorded posting policy then uses business-unit defaults. A configured setup makes treatment explicit for that product rather than relying on the general defaults. Its own version lets a specialist correct financial information separately from catalogue details. Staff encounter this information in the product editor’s accounting cards. The service exposes full setup information through a separately authorized read, while ordinary product reads provide a smaller summary. That distinction allows finance to grant setup management independently of product management. ## What It Is Not A setup is neither a journal entry nor evidence that revenue has been posted. It describes the instructions available to posting. The chart of accounts, departments, projects and merchant accounts remain records of Books. Selecting them here does not create or change those records. A setup also does not determine a final purchase price. The grid describes pricing choices, while splits describe allocation. Tax assignment remains visible in the built setup during the approved move of tax ownership to Commerce; its presence here should not establish a permanent boundary. ## How It Is Used A finance specialist selects accounts belonging to the product’s unit. New references must be active and ordinary account slots require suitable categories. Later retirement of a referenced account does not by itself prevent an unrelated correction retaining it. The specialist supplies the setup version when replacing existing information. Saving replaces the setup and its collections as a transaction. A failed replacement preserves the previous configuration. Console creation is a separate sequence: the product can commit before its setup is refused. Finance can fix that setup and retry. For several products, the API offers a bulk transaction that fails together and identifies the offending entry. ## Its Facets **Accounts and dimensions.** Revenue, receivable, deferred revenue, write-off, cost and inventory slots describe different financial purposes. Department and project add dimensions; merchant selection provides routing information. **Recognition timing.** Immediate, automatic, fixed-date and relative-date strategies describe when revenue belongs in income. Fixed percentages allocate the full amount. Relative rules describe transaction-month coverage and fallback treatment. **Revenue shares.** Splits allocate a percentage or fixed amount to other income accounts in the same unit. Their identities matter for continuing references, and the console currently regenerates them during saves. **Other units.** Inter-entity entries identify accounts in another business unit. They are limited to one entry per other unit and cannot target the product’s own unit. **Tax assignment.** A setup class takes precedence over the product kind’s default. Both are part of the current implementation while the ownership transfer awaits a detailed contract. **Protection and remarks.** Setup locks govern replacement and deletion independently of product locks. Notes retain finance’s explanation without creating a separate approval process. ## How It Relates The product owns the setup, and its prices supply the limit used for fixed shares. Books owns referenced financial configuration. Transactions retain the information needed for individual charges and Batch management owns posting. Commerce becomes the tax owner under the recorded realignment decision. These dependencies need contracts beyond a catalogue read. ## What It Could Become The product should preserve revenue-share identities through console corrections and align recognition validation across editing paths. Design also needs to settle accounting edits on retired products and the separate-save failure experience. A tax handover must retain existing assignments while establishing one authoritative owner for future classification.