A chart of accounts you will not regret
Design from the decisions you make, not the chart you inherited. Three of those decisions are
one-way doors. Everything else you can change on a wet Tuesday.
Guide · updated 2026-10-17
Three decisions in a chart of accounts are irreversible. The segment list itself, and which of those segments
every transaction must carry. The grain of each natural account, because an account can never be split backwards.
And which facts you pushed into the chart instead of leaving in the subledger, because from then on two lists have
to be kept in step forever. Account names, numbering, report hierarchies, new values inside a segment you already
have, anything computed in the reporting layer: all of that is cheap, and you can change it in an afternoon.
Most advice here points at a long redesign of the whole chart. This page points at three decisions and then tells
you to stop. It is written for the first real ERP: one controller, an external bookkeeper, a decade of QuickBooks
or Sage history, two or three cities, no FP&A team.
What is locked and what is free
Everyone knows a chart of accounts is hard to change later. Which parts, and how hard, is the part you can act
on. There are only three answers: free, forward only, and never.
One: does a subledger record already carry this? Customer, vendor, item, project, employee,
fixed asset, site. If one of them does, it is not a segment, ever. The commonest mid-market failure is a segment
value per customer or per site: the segment list then has to be maintained alongside the customer list for the
life of the system, and nobody owns both.
Two: does it change the nature of the money? A salary is not a rent. Natural account.
Three: is it a stable, finite list of places the money belongs that every transaction can
answer? That, and only that, is a segment.
Four: is it true of some transactions and unanswerable for others? A tag, or a flag on a master
record. Never a required segment.
Five: can it be derived from the other four? Build nothing, and compute it in the reporting
layer.
Locked one: the segment list, and what it costs to carry
Count the segments you intend to make mandatory. For each one, name the master record the value defaults from:
vendor, customer, item, employee, site, or the user's profile. A segment with no default source is one a human
types on every line, and a finance team of two can sustain exactly one of those.
| Candidate segment | Defaults from | Verdict |
|---|
| Site or branch | Customer record, or the user's profile | Mandatory, defaulted, safe |
| Department or cost centre | Employee record, vendor record | Mandatory, defaulted, safe |
| Product line | Item record | Mandatory, defaulted, safe |
| Project | Nothing. It is a subledger record | Report it from the project ledger |
| Funding source, campaign, initiative | Nothing. A human types it | At most one typed segment in the design |
A dimension you can neither default nor make mandatory should be deleted from the design. Partially populated is
worse than absent: the report under-reports quietly, the total still looks plausible, and nobody finds out until
somebody ties it back to the trial balance.
Cause and effect get stated backwards here more often than not. The structure is rarely the binding constraint;
coding at the moment of entry is. Four dimensions produce rubbish if the dimension is optional on the purchase
invoice screen, if the default on the vendor record is wrong, or if the integration from the field app posts
everything to one code. Which dimensions are defaulted, typed, or enforced by validation belongs in the
process design stage, with the chart itself.
Locked two: the grain of each account
This is the only irreversible choice inside the account list, and it has a one-question test. For any two things
posting to the same account, ask whether you would ever need to see them apart for a period that has already
closed. If yes, separate accounts from day one: a segment added later is populated going forward only, and
one account can never be split backwards. If no, merge them, because a sibling account next year is free.
Travel and meals: split, because the tax treatment differs and you will be asked about prior years. Courier and
postage: merge, because nobody has needed those apart for a closed month. Run the test down the chart and you land
on the coarsest set of accounts that still produces every line below.
Locked three: what you pushed into the chart
The first two locks are choices you can see on a design document. This one is invisible until it has already
happened, so it needs a test you can run on a finished design.
The test: for each segment, name who adds a value, and what else that person has to add at the same
moment. If opening a new customer, site, project, vendor or employee also requires somebody to open a
matching segment value, that fact is pushed. You now have two lists that mean the same thing, maintained by two
different hands, and only one of them refuses to post when it is wrong. The customer list refuses. The segment
list silently accepts the stale value, which is why the drift is always discovered from the reporting side.
Run it on every mandatory segment. One answer of “and a matching code” is a design defect worth
fixing before go-live. Two means the chart is already being maintained twice, and the second copy has no owner.
The reason respectable designs fail this test is almost always the same, and it is worth naming: somebody tried
to make one chart serve statutory, management and consolidation reporting natively, and encoded a fact for each.
The three are listed as objectives everywhere. What to do when they disagree is not, and they do disagree: a tax
line that needs its own account in one entity and must disappear in the group pack, or a subsidiary that needs a
segment the others cannot populate.
That is settled by a decision, not by a cleverer design. Pick the one reporting view the chart serves natively and
serve the others by mapping. For twenty to two hundred people it is usually management reporting, because that is
the pack somebody reads monthly, while statutory output is produced a few times a year from a mapping an
accountant maintains. Choosing the other way round is defensible. Not choosing is how facts get pushed.
The sequence, run backwards from how most projects run it
Most projects start from the chart they have and tidy it. Start from the outputs instead.
01 Write the outputs first
- aThe monthly management pack: actual pages, actual lines, actual cuts
- bThe statutory and tax outputs each entity owes
- cThe questions you were asked last year and could not answer
02 Derive, do not invent
- dKeep only segments that appear on more than one of those outputs
- eNatural accounts: the coarsest set that still produces every line
03 Protect the history
- fBuild the legacy to new mapping and check it is many-to-one
- gFreeze the legacy chart, no new accounts, before cutover
Outputs firstA segment that appears on only one report is a report, not a segment. The freeze at step g stops the old chart growing a tail while you are migrating it.
The mapping table decides how much history you keep
Not migrating the legacy chart as-is is advice about the target. It says nothing about the twelve years of
transactions you still report against. Legacy accounts must map many-to-one onto new accounts. Wherever one
legacy account maps to two new ones, you have a choice with no third option.
One legacy account has to become two new accounts. The history cannot be split.
Option one
Let history collapse
Everything posted before cutover sits in one of the two. Year one comparatives are produced on the merged
line, with a note, and the split starts at cutover.
Option two
Keep the legacy trial balance readable
Hold the old trial balance as a read-only side by side. It costs a decision about where it lives and who
may read it, and it answers questions about the old years.
Decide this account by account, in writing, before cutover, and never during the
load weekend, where the only hands available belong to people who do
not own the answer. The mapping table is a permanent deliverable: whoever gets a question about the old years has
to be able to read it, and that may be an auditor three years from now. How much history to carry, opening
balances against full detail, is covered in the
data migration checklist.
Six counts on the chart you have, before you design anything
Run these against the live file. They take an afternoon.
- Accounts with zero postings in the last twelve months.
- Accounts whose name contains Other, Misc, Sundry, a year, a person's name or a city.
- Families of accounts that differ only by a dimension you already have: Travel Sales, Travel Ops, Travel Admin.
- Segment combinations used fewer than three times in the year.
- Accounts that exist because one person wanted one report, once.
- Whether the monthly pack and the tax return come from the chart directly, or from a spreadsheet that remaps it.
The sixth count is the one that matters. If a spreadsheet sits between the chart and every output anyone reads,
the chart has already failed and the spreadsheet is the real chart of accounts. Design the new chart to produce
what that spreadsheet produces. If the file you are counting is QuickBooks or Sage, settle first whether you need
new software at all: outgrown QuickBooks, or outgrown your process.
§
The whole governance policy, in five lines
Chart governance is usually written as a twenty-page policy that is never reopened after sign-off. Five lines,
enforced by whoever closes the month, does the same work, because the enforcement is what governs.
- Nobody creates an account without naming the report line it feeds.
- Nobody creates a segment value without naming the report line it feeds.
- One named person owns each segment's value list and culls the unused values once a year.
- Every clearing and suspense account has a named owner and a target balance of zero at each month end.
- A clearing account not emptied for three consecutive months is an open finding, not an account.
Clearing discipline is what keeps a clean chart clean. A chart does not degrade through bad design. It degrades
one convenient account at a time, each one opened to park something for a month. That is failure by accretion
rather than by decision, which is the shape most of them take:
why implementations fail traces each mode back to the stage
where nobody was watching.
Before you redesign anythingIf you are not certain the business needs a new system at all, start with
the readiness check. Twenty scored statements, and it tells you when the honest answer
is no.