# Chart of accounts

## Purpose

The chart of accounts (COA) is the **classification backbone** for financial reporting. It must remain **strictly tenant-scoped**: each tenant maintains its own COA; no cross-tenant account visibility or numbering collision across tenants.

## Account types

Standard ERP classification (normalized for reporting and policy):

| Type | Normal balance | Typical role |
| --- | --- | --- |
| **Asset** | Debit | Resources controlled by the entity |
| **Liability** | Credit | Obligations to third parties |
| **Equity** | Credit | Residual interest after liabilities |
| **Revenue** | Credit | Income from ordinary activities |
| **Expense** | Debit | Consumption of economic benefits |

Equity is included explicitly so closing and ownership structures remain first-class (even if minimal in early phases).

## Hierarchy

- Accounts form a **tree**: parent accounts aggregate children for reporting roll-ups.
- **Posting** (when implemented) occurs only on **leaf** accounts (postable accounts). Parent nodes are **summary** nodes unless explicitly designated otherwise by policy.
- Codes or numbers should be **stable** once used in posted history; renaming display labels is acceptable if audit preserves historical identifiers.

## Tenant isolation

- Every account row carries **`tenant_id`** (or equivalent tenancy key). Queries, caches, and APIs must enforce tenant scope identically to operational modules.
- **No shared master COA** across tenants at persistence layer—shared templates may seed per-tenant copies only.

## Relationship to operations

The COA **does not** drive inventory quantities, reservations, or fulfillment. Operations remain authoritative; accounts classify **financial consequences** once postings are introduced.