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.