Free tool

A chart that will not need unwinding

Most chart of accounts problems are one problem: a dimension living inside an account number. This generator produces a starting structure where accounts describe economics and dimensions describe context, which is the decision everything above the chart depends on.

Have a chart to review?

Send your existing chart and one report you cannot produce. We will tell you whether the chart is why.

1 / 3
Dimensions kept separateOne chart across entitiesRoughly 40 accounts, not 400
3

1000 Assets

  • 1010Cash and equivalents
  • 1020Accounts receivable
  • 1030Prepaid expenses
  • 1040Fixed assets
  • 1050Accumulated depreciation

2000 Liabilities

  • 2010Accounts payable
  • 2020Accrued liabilities
  • 2030Deferred revenue
  • 2040Notes payable

3000 Equity

  • 3010Contributed capital
  • 3020Retained earnings
  • 3030Distributions

4000 Revenue

  • 4010Product revenue
  • 4020Service revenue
  • 4030Other income
  • 4040Fee revenue — time and materials
  • 4050Fee revenue — fixed fee
  • 4060Reimbursable revenue

5000 Cost of revenue

  • 5010Direct labour
  • 5020Direct materials
  • 5030Subcontractors
  • 5040Hosting and delivery
  • 5050Billable labour
  • 5060Sub-consultants
  • 5070Reimbursable expenses

6000 Operating expense

  • 6010Salaries and wages
  • 6020Employer taxes and benefits
  • 6030Facilities
  • 6040Software and subscriptions
  • 6050Professional fees
  • 6060Marketing
  • 6070Travel
Dimensions, not accounts
DepartmentOfficeClientEngagementService line

32 accounts across 3 entities — one shared chart, with entity as a dimension rather than a separate chart per company.

Pick an industry and entity count. Note that entity count does not change the chart — it is a dimension, which is the entire point of the exercise.

How to read it

Three things this is telling you.

The specific account numbers matter far less than the two structural decisions the generator is demonstrating.

Accounts describe economics

What kind of transaction was this. Salaries, rent, product revenue. Not where it happened, who it was for, or which project it belonged to — those are dimensions.

One chart, not one per entity

Moving the entity slider does not add accounts. A group with fourteen entities uses one shared chart with entity as a dimension, which is what makes consolidation possible at all.

Forty accounts, not four hundred

The median chart we examine has 340 accounts of which 38% have had no activity in three years. Most of the excess is dimensions wearing an account number.

The mistake this is designed to prevent

A company opens separate revenue accounts per office, then per product line, then per major customer. Each addition is individually reasonable — somebody needed to see that number separately and the system offered no other way to get it.

Three years later there are 340 accounts, consolidation requires a mapping table nobody maintains, and adding a fourth office means creating eleven new accounts. Unwinding it is a chart of accounts redesign, which is a real project with a real cost.

Nearly every request for a new account is a request to see something separately. That is what a dimension is for, and it costs nothing structurally.

Why the entity slider does nothing

That is deliberate and it is the most important thing on this page. A chart per entity is the second most common structural mistake we find, and it makes consolidation a mapping exercise rather than an arithmetic one.

One shared chart with entity as a dimension means the consolidated P&L is a sum rather than a translation, intercompany elimination can match transaction to transaction, and adding an entity costs nothing structurally. Where a subsidiary genuinely needs an account nobody else uses, add it to the shared chart — an unused account in one entity is harmless.

What this generator does not do

It does not know your business. The industry variants add the accounts that industry genuinely needs and they are a starting point, not a specification. A real chart is designed against your actual transactions and your reporting requirements.

It also does not migrate anything. Adopting a new chart means remapping history so that year-over-year comparison still works, and that remapping — not the design — is most of the work in a real redesign.

The rule that keeps it clean

Charts re-bloat within three years unless somebody owns them. The policy worth writing down is a single question: does this request need a new account, or does it need a dimension on an existing one?

In our experience the answer is a dimension roughly four times out of five. Making that the default question rather than the exception is what stops the chart growing back.

What is behind the structure

The base chart follows conventional US GAAP grouping — 1000 assets, 2000 liabilities, 3000 equity, 4000 revenue, 5000 cost of revenue, 6000 operating expense — with ten-increment numbering inside each group to leave room for insertion.

Industry variants add accounts drawn from what those industries genuinely need in our engagements, not from a published template. They are additive to the base rather than replacing it.

Dimension sets per industry are the cuts we most often see requested in reporting for that sector. Five is a starting point; there is no structural penalty for more, which is precisely the difference between a dimension and an account.

Nothing you enter is captured or stored. The generator runs entirely in your browser, and the output is a starting structure rather than a chart you should adopt without review.

Questions

Common follow-ups.

How many accounts should we have?
Most mid-market companies operate well on 150 to 250 with proper dimensions behind them. The median chart we examine has 340, of which 38% are dormant.
Why does entity count not add accounts?
Because entity is a dimension. A chart per entity makes consolidation a mapping exercise rather than arithmetic, and it is the second most common structural mistake we find.
Can we adopt this directly?
It is a starting point, not a specification. A real chart is designed against your transactions and reporting requirements, and adopting a new one means remapping history.
What if our system only has two dimensions?
That is the Xero and QuickBooks ceiling and it is the usual reason companies encode dimensions in accounts. Integration solves it without a migration for most companies.
How do we stop it bloating again?
One written question on every new-account request: does this need an account or a dimension on an existing one? The answer is a dimension about four times out of five.

Accounts for economics, dimensions for context.

That single decision determines whether your reporting works and whether consolidation is arithmetic or archaeology.