Chart of accounts
Domain design for accounts, hierarchy, classifications, and legacy differences.
The chart of accounts is the first slice of accounting and the reference every later service copies platform patterns from.
Why this first
It exercises hierarchy, closed enums, uniqueness constraints, and reference data other services will consume — without ledger complexity. It is also a prerequisite for journal entries.
Chart and ledger share one service and one database as separate packages.
Classifications
Every account requires one Account classification: One of asset, liability, equity, revenue, or expense; required on every account and used to derive normal balance and financial statement placement.: asset, liability, equity, revenue, or expense. Normal balance and financial statement placement derive from classification — not from stored display fields.
Key fields
| Field | Role |
|---|---|
id | UUIDv7 entity identity |
chart_id | Which chart; codes unique per chart |
code | Accountant-visible number |
name | Label |
parent_id | Tree structure (input as parent_code on create) |
is_postable | False for grouping headers like ASSETS |
active | Enforced at post time; accounts are never deleted |
Legacy vs new (summary)
The legacy system duplicated charts per property and conflated presentation with semantic class. The new model uses one chart per jurisdiction, real legal entities, stored dimensions at post time, and a single required classification enum.
Full comparison: docs/accounting/chart-of-accounts.md.
Open design questions: docs/accounting/open-questions.md.