What a chart of accounts is for.
The chart of accounts (COA) is the list of every account in your general ledger, organized into the five classes: assets, liabilities, equity, revenue, expenses. Each account has a number, a name, a class, and rules about who can post to it. Every transaction in your business eventually lands in one or more accounts on this list. The COA shape determines what reports you can run, what comparisons you can make, and what stories your books can tell.
A common mistake is treating the COA as paperwork to copy from a textbook. It is not. The COA is the data model of your business. A retailer with 3 branches and 5 product categories needs a different COA than a services firm with 2 partners and 10 client accounts. Designing it for your business takes a half-day; reusing someone else's template costs you forever.
Flat vs nested, the trade-off.
A flat COA has one level: 4001 Sales - Atlanta, 4002 Sales - Manchester, 4003 Sales - Berlin. Easy to set up, painful to report. To see total Sales you sum 4001 + 4002 + 4003 manually. A nested COA has parents and children: 4000 Sales (parent), with children 4001-Atlanta, 4002-Manchester, 4003-Berlin. The parent rolls up automatically. Three levels is usually plenty: class -> group -> specific account.
Better than both: flat COA plus dimensions. One Sales account (4000) with branch as a separate dimension on every transaction. Now you have 1 account but unlimited reporting cuts: by branch, by department, by project, by customer. Modern systems including Nonari are dimension-first, so the COA stays small while reporting stays rich. The classic 1500-account COA bloated across branches is a 1990s pattern.
A four-digit numbering scheme that scales.
Use four digits with leading digit by class. 1xxx assets, 2xxx liabilities, 3xxx equity, 4xxx revenue, 5xxx COGS, 6xxx operating expenses, 7xxx other expenses, 8xxx other income, 9xxx tax. Within each class, group: 11xx cash and equivalents, 12xx receivables, 13xx inventory, 14xx fixed assets, 15xx prepayments. Within each group: 1101 Cash on Hand - HQ, 1102 Cash on Hand - Atlanta Branch, 1103 Cash on Hand - Manchester Branch, etc.
Leave gaps. Number 1101, 1102, 1110, 1120 instead of 1101, 1102, 1103, 1104. Six months from now you will need a new account between two existing ones, and gaps mean no renumbering. Renumbering once you have 6 months of data is a nightmare; gaps are free insurance. Nonari ships with a -tuned starter COA you can fork and customize.
The branch dimension, three options.
Option one: separate accounts per branch. Sales Atlanta 4001, Sales Manchester 4002, Sales Berlin 4003. Works for 3 branches. Breaks at 30 branches. Option two: classes/locations as a tag, single account. One Sales account 4000, every transaction tagged with branch. Reporting cuts by tag. This is what QuickBooks Online uses. Awkward for your tax authority returns because branch-specific tax codes are a stretch on a tag system.
Option three: branch as a first-class dimension on every line, with branch-specific opening balances and inventory. This is what an enterprise ERP does and what Nonari does for SMBs. Each branch has its own COGS via WAC, its own AR ledger by customer, its own bank account, its own till. The COA is shared but the ledger is partitioned. Reports run by branch in milliseconds; consolidation is a single click.
- Flat COA + branch dimension scales best.
- Branch-specific WAC needs branch as ledger key.
- Tax codes by branch (e.g., POS vs distributor) need branch context.
- Inter-branch transfers need paired entries, not single tags.
- Consolidated reports come for free if branch is a dimension.
Departments and projects as additional dimensions.
Beyond branches, two dimensions matter. Department: marketing, operations, finance, sales. Helps allocate overhead and run departmental P&Ls. Project: each construction project, each consulting engagement, each marketing campaign. Helps measure project profitability. With three dimensions on every line (branch, department, project), one Salaries account covers your entire payroll and you can still answer "how much did we spend on the Atlanta marketing team in March."
The temptation is to bake all this into account numbers: 6101 Salaries - Atlanta - Marketing - Project A. By the time you have multiplied dimensions you have 4,000 accounts and no human can navigate it. Single account, three dimensions, infinite reporting. This is the cleanest possible COA for an SMB that wants to grow without constant restructuring.
-specific accounts every COA needs.
Five specific accounts that growing SMBs always need. Sales Tax Payable - Output (split by your local sales tax rates if your products span rates). Sales Tax Receivable - Input. withholding tax Payable - 153(a) for goods. withholding tax Payable - 153(b) for services. Income Tax Payable - corporate or AOP. Plus EOBI Payable, social security if applicable, professional tax. Get these right and your monthly your sales tax return and quarterly withholding tax statements pull straight from the ledger.
Two often-missed accounts: Bank Charges (separate from finance cost so you can see the operational cost of banking), and your tax authority Default Surcharge (so you know how much late filings have cost you cumulatively). Both small line items, both useful diagnostics. With Nonari's starter COA these are pre-built; manual setups often miss them and merge into generic Bank Charges or Tax Expense.
Avoiding common COA mistakes.
Mistake one: too many revenue accounts. Sales by product category is rarely useful at the COA level; use product or item dimensions instead. Mistake two: too few expense accounts. Travel, meals, entertainment, training are different things and useful to track. Mistake three: mixing balance sheet and P&L on the same account (e.g., one "Tax" account that holds liabilities and expenses simultaneously). Mistake four: account names that change meaning over time. "Mr. Khan" should not be an account, "Account Receivable - Customers" with Mr. Khan as a customer record is correct.
Mistake five: posting to summary parent accounts instead of leaf accounts. If 4000 Sales is a parent, never post directly to it; only its children should receive entries. Posting to parents creates ambiguous data that breaks all reporting. Nonari prevents posting to parent accounts; manual systems trust the bookkeeper to remember.
Migrating from a legacy COA.
If you already have 6 years of data on a different COA, do not abandon it. Run the legacy COA in parallel for one fiscal year. Map old accounts to new accounts in a spreadsheet. Post current transactions on the new structure starting July 1 (FY start), keep historical transactions on the old structure. At fiscal year end, generate comparative reports using the mapping. By next FY start, old structure is read-only history and new is the live ledger.
Migration in the middle of the year is much harder because comparative reports lie. Time the switch to FY start. Communicate the new COA to every branch manager and bookkeeper before launch. Train for two weeks before going live. Most COA migrations fail not because of technology but because the team continues to mentally use old account names for six months.