Designing the chart of accounts

The chart of accounts decides what questions your financials can answer. Everything else in accounting is data entry against it.

Most businesses inherit theirs — from a previous system, from an accountant's template, or from whoever set up Tally in 2011. It usually works, in the sense that the trial balance balances. What it often cannot do is answer the questions the business actually asks, like which product line is profitable or what a branch costs to run.

Design for the report, not the transaction

Start from the reports you need and work backwards. If leadership wants gross margin by product category, the chart has to separate revenue and direct cost by category — or you need a dimension that does it without multiplying accounts.

That distinction matters. Two ways exist to slice financials:

More accounts. Separate ledger accounts for each thing you want to see. Simple, and it scales badly: three product lines across four branches is twelve revenue accounts, and adding a fifth branch means creating three more.

Dimensions. One revenue account, tagged by cost centre, project or a custom dimension. The chart stays small and the reporting stays flexible.

The rule of thumb: use accounts for things with genuinely different accounting treatment, and dimensions for things you want to slice by. Branches are a dimension. Revenue and deferred revenue are different accounts.

What Indian businesses have to get right

Schedule III. Statutory financials must present in the format the Companies Act prescribes. If the chart does not map cleanly to it, someone rebuilds the mapping by hand every year, and that mapping is where errors hide.

GST accounts. Input and output tax need separating by rate and by type — CGST, SGST, IGST and cess each need their own accounts, on both sides. Collapsing them makes return filing a reconciliation exercise rather than a report.

TDS. Deducted at source and payable are different accounts with different due dates, and lumping them together makes it impossible to see what is actually owed to the department this month.

Do not over-engineer it

The opposite failure is a chart with 800 accounts because someone tried to anticipate every question. Nobody can find the right account, postings land in approximations, and the detail everybody paid for turns out to be noise.

A useful test: if a person doing data entry cannot choose the right account without asking, there are too many.

Migration

Map the old chart to the new one explicitly, account by account, and get the mapping reviewed by whoever signs the financials. Opening balances go in against the new structure — which is the moment any gap in the mapping becomes visible, and the reason to do it before go-live rather than after.