Two audiences, opposite needs
A chart of accounts has to satisfy two readers who want incompatible things.
Your accountant and any external reader — lender, auditor, acquirer — want a small, conventional structure that maps cleanly onto standard financial statements and tax forms. They want to see one Rent account, not eleven.
You want to know whether the Denver location is profitable, what the new product line costs to support, and which marketing channel is worth funding. That is a detailed, business-specific question.
The near-universal mistake is trying to answer the second question by adding accounts, which produces a 400-line P&L that no external reader can use and no internal reader can summarize. The resolution is that those two needs get served by different mechanisms, and the accounting system has always had both.
Accounts answer what. Dimensions answer where and which.
This single distinction prevents most chart of accounts problems.
An account records the nature of a transaction: what kind of thing was this? Rent. Software. Salaries. Product revenue.
A dimension records the context: which location, which department, which product line, which customer, which project. Every accounting system supports these under some name — classes, locations, departments, tags, tracking categories, segments.
So if you find yourself creating "Rent - Denver", "Rent - Austin" and "Rent - Warehouse", stop. That is one Rent account crossed with a Location dimension. Built that way, adding a fourth city adds one dimension value instead of six new accounts, and you can report rent by city or rent in total without restructuring anything.
The test
If an account name contains a hyphen followed by a place, a person, a team or a product, it is almost certainly an account and a dimension mashed together. Every such pair multiplies the account count and none of them can be summarized cleanly.
A numbering scheme that leaves room
Four digits is the right size for almost every private company. Five is worth it only above roughly $50M or with genuinely complex segment reporting. Three runs out of room fast.
The convention below is near-universal, which matters: a new controller, a lender's analyst or an auditor recognizes it immediately and does not have to learn your system.
- 1000-1999 Assets — 1000s cash, 1200s receivables, 1300s inventory, 1500s fixed assets, 1600s accumulated depreciation
- 2000-2999 Liabilities — 2000s payables, 2100s accrued liabilities, 2300s deferred revenue, 2700s long-term debt
- 3000-3999 Equity — contributions, distributions, retained earnings
- 4000-4999 Revenue — separated by the categories you actually price and manage, not by customer
- 5000-5999 Cost of revenue — only costs that scale with delivery
- 6000-7999 Operating expenses — grouped by function: 6000s people, 6500s facilities, 7000s sales and marketing, 7500s general and administrative
- 8000-9999 Other income and expense — interest, taxes, gains and losses, anything below the operating line
Leave gaps, and put the gross margin line where it belongs
Number in tens rather than consecutively. 6010, 6020, 6030 leaves room to insert 6015 later in the right position. Consecutive numbering forces every new account to the bottom of its section, and within two years the sequence tells you nothing about how things group.
The more consequential decision is the boundary between cost of revenue and operating expense, because it determines your gross margin — the number investors, lenders and buyers look at first and the one you will be benchmarked on.
The rule that holds up: a cost belongs in cost of revenue if it scales with delivering the product or service to customers. Hosting, payment processing, direct fulfillment labor, support headcount tied to account volume. It belongs in operating expense if it would continue largely unchanged if volume fell by half. Sales, marketing, product development, the finance team, the office.
Engineering salaries are the perennial argument. For most software businesses they sit in operating expense, because the team builds the product rather than delivering each instance of it. Implementation and professional services engineers who are billable or tied to individual customer onboarding are the genuine exception and belong in cost of revenue.
How many accounts is right
Fewer than you think. A well-run company under $10M in revenue typically operates on 80 to 150 active accounts. Above 250 you almost certainly have dimensions encoded as accounts.
- Decision test. Would seeing this line separately ever change something you do? If not, roll it into a parent. Nobody has ever made a decision from a standalone Coffee Supplies account.
- Materiality test. If an account will never hold more than about 1% of total expense, it is detail, not a line item.
- Consistency test. Could two different people code the same transaction to two different accounts? If yes, either the definition needs writing down or the accounts should be merged. Ambiguity produces inconsistency, and inconsistent coding is worse than coarse coding.
Write the coding guide
One page mapping your recurring vendors and transaction types to accounts. It takes an hour, it eliminates most coding questions, and it is the single thing that makes your books survive a bookkeeper transition intact.
Restructuring without losing your history
If your chart of accounts is already a mess, the fix is a project with a right and a wrong way to run it. The wrong way is renaming accounts in place mid-year, which silently restates prior periods and leaves you unable to reconcile to your own filed tax return.
- Time it to a fiscal year boundary. A clean break means prior years stay comparable to what you filed.
- Export the last two years of the full general ledger before touching anything. This is your ability to answer questions about the old structure later.
- Design the new chart on paper first, including the dimension scheme. Do not build it in the accounting system while you are still deciding.
- Build a mapping table: every old account to exactly one new account. One-to-many mappings mean you are combining a restructure with a re-coding project, which doubles the work and the risk.
- Merge rather than delete. Merging preserves transaction history under the surviving account; deleting orphans it.
- Restate the prior year through the mapping so you have one comparative year on the new structure. Without it, your first year on the new chart has nothing to compare against.
- Publish the coding guide and the dimension definitions the same week you go live.