Accounting
A practical chart of accounts for high-growth teams
· 9 min read
Too granular and reporting stalls; too flat and you lose signal. Here's a structure that scales with headcount, products, and new entities.
The two failure modes
Too flat: 'Software' holds Stripe, AWS, Figma, and a random SaaS tool the intern bought. You cannot answer what infrastructure costs, and tax prep becomes a reconstruction project.
Too granular: a new account for every vendor. The close slows down because every transaction needs a debate, and the P&L becomes unreadable. High-growth teams usually over-correct from the first failure into the second.
Design for decisions, not for vendors
Accounts should map to questions you ask every month: gross margin, payroll burden, paid acquisition, infrastructure, professional services, and occupancy. Vendors belong in the payee field, not in the chart.
Use classes, locations, or projects for product lines and entities before you split the chart. A second entity does not automatically need a second, incompatible account list. Consistency is what makes consolidated reporting possible.
Leave room, then freeze it
Number ranges with spare capacity (for example 6000–6999 for opex) let you add a legitimate new category without renumbering. After the first clean quarter, freeze the chart. New accounts require a written reason and an owner.
The chart of accounts is a control, not a wiki. If anyone can add accounts, you will spend the close mapping aliases instead of reviewing the business.
What to do with the mess you already have
Do not recode three years of history in one weekend. Freeze new posting to a target structure, map the old accounts, and recode only what you need for comparative reports. Perfect historical purity is how close projects never end.
Modern Accounting AI starts teams on a practical US small-business chart and keeps categorization consistent so reporting and tax prep are a review, not an archaeology project.