Chart of Accounts

Because financial transactions only become information when they are grouped, and the grouping has to be decided before the transactions arrive rather than after.

The chart of accounts decides which questions the financials can answer. Reporting can only slice along lines the chart already draws, so a chart designed around the transactions produces statements nobody can act on, while one designed around the reports produces both. It is the most consequential piece of accounting design in an implementation and the one most often inherited unexamined.

• Every postable account belongs to exactly one of asset, liability, equity, income or expense. That classification determines which statement it appears in and cannot be ambiguous.
• Group accounts organise; only leaf accounts receive postings. Posting to a group is a misconfiguration, not a shortcut.
• An account with transactions may be disabled but never deleted, and never repurposed — reusing a code makes every historical report about it ambiguous.

It gets copied from the previous system, because it worked there and rebuilding it feels like scope. Then the first time leadership asks for margin by product line, the answer is that the chart cannot produce it — and by then there are two years of transactions posted against a structure that would have to be restated to fix.

• Migrating from a flat chart, where a legacy code maps to two new accounts and the split needs a judgement per transaction.
• Multi-currency accounts, which hold a balance in both transaction and reporting currency and revalue independently.
• Control accounts for receivables and payables, which must reconcile to their sub-ledgers and should never be posted to directly.
• Charts inherited from an accountant's template that carry accounts for a business model this business does not have.