Designing a chart of accounts

What a chart of accounts is for

A chart of accounts is the list of buckets that every transaction in a business ends up in. It determines what your financial statements can say, what questions your reporting can answer, and how much manual work stands between a posted transaction and a useful number. It is the most consequential piece of configuration in any accounting system, and it is almost always designed in a hurry during implementation by whoever happened to be available.

The reason it deserves more care is asymmetric cost. Designing it well takes a few days of thought. Fixing it later costs the comparability of your history, a mapping exercise across every integration, and a conversation with your auditor. Nearly every business that has run one system for more than five years is carrying a chart of accounts it would not design again and cannot easily change.

The core design question is deceptively simple: what belongs in the account code, and what belongs somewhere else? Nearly every chart of accounts failure is an answer to that question that put too much into the account code. Understanding why requires being clear about what an account actually is.

An account answers the question what kind of thing is this. Rent expense. Trade receivables. Sales of goods. It describes the nature of the amount, and that is the only question it should answer. Where it happened, who it was for, which project, which department, which product line: these are all real questions and none of them is a question about the nature of the amount.

The proliferation failure

The most common chart of accounts in the world looks something like this. There is an account for rent. Then the business opens a second branch, so there is now rent for branch one and rent for branch two. Then someone wants to see rent by department, so each of those splits again. Then a new cost centre appears and every account in the operating expense range is duplicated for it. Within a few years there are four thousand accounts, most of which carry a balance in three months of the year.

This does not fail visibly. It fails by making things gradually impossible. Consolidated reporting requires summing hundreds of accounts, and every new branch requires the report to be rebuilt. Comparing branches means comparing different account codes, which no standard report does. Closing a branch leaves twenty dead accounts that cannot be deleted because they carry history. Adding a branch means creating twenty accounts and remembering to add them to every report, every budget, every mapping. Somebody eventually posts branch two rent to the branch one account and the error is invisible in the consolidated total.

The deeper cost is that the structure has hard-coded a fact about the business into the ledger. Branches, departments and product lines change. They merge, split, get renamed and get reorganised. Every time they do, a chart of accounts that encodes them structurally has to be rebuilt, and the history becomes incomparable at exactly the moment somebody wants to compare it.

The symptom to watch for is repetition. If you can look at your account list and see the same word repeated at intervals, rent, rent, rent, salaries, salaries, salaries, then that repeated concept is not a kind of expense. It is a dimension of the business that has been forced into the account code because there was nowhere else to put it.

Accounts versus dimensions

Almost every accounting system built in the last twenty years supports posting attributes alongside the account code, variously called dimensions, segments, analysis codes, tags, cost centres or tracking categories. A posting carries an account plus one or more dimension values, and reports can be produced by account, by dimension, or by both.

This changes the design problem completely. Rent is one account. Branch is a dimension with a value for each branch. Rent for branch two is not a separate account; it is the rent account filtered to branch two. Adding a branch adds one dimension value rather than twenty accounts. Closing a branch retires one value. Comparing branches is a standard report with a grouping, not a bespoke build. And the account list stays the size it should be, which for most mid-sized businesses is a few hundred accounts rather than a few thousand.

The test for whether something is an account or a dimension is whether it changes the nature of the amount or the context of it. Rent in Riyadh and rent in Jeddah are the same kind of cost in different places, so place is a dimension. Rent expense and salary expense are different kinds of cost, so they are different accounts. Applying this test consistently removes most of the proliferation before it starts.

Two warnings on dimensions. First, they are only useful if they are mandatory where they are meaningful, because a dimension that is populated on eighty per cent of postings produces reports with an unexplained remainder, and that remainder destroys trust in the report faster than having no report. Second, resist the temptation to define ten dimensions because the system allows ten. Every dimension is a field somebody has to populate correctly on every transaction, and an unpopulated dimension is worse than an absent one.

• Branch, location, site or store: a dimension. The cost is the same kind of cost wherever it occurs.
• Department, cost centre or function: a dimension. It determines who is accountable, not what was bought.
• Project, job or contract: a dimension, and often the one that carries the most reporting value.
• Product line, service line or business segment: a dimension, and the basis of most segment reporting.
• Customer and supplier: not accounts at all. These belong in subledgers, behind a control account.
• Employee: not an account. Payroll detail belongs in the payroll system, summarised into the ledger.
• Legal entity: usually a separate ledger rather than a dimension, though some systems handle it as a segment.

Numbering

Account numbering is less important than dimension design and more argued about. What a numbering scheme has to do is make the account type obvious from the code, leave room to insert accounts without renumbering, and sort into a sensible statement order without a separate mapping.

The conventional structure groups by statement classification: assets, liabilities, equity, income, expenses, each with a leading digit or range, and sub-ranges within each for classes. Current assets separate from non-current. Cost of sales separate from operating expenses. Finance costs separate from both. The specific ranges matter far less than the fact that they exist and that the gaps in them are wide enough to insert into.

Account names deserve as much attention as numbers and get almost none. A name should describe what belongs in the account precisely enough that two people posting the same transaction choose the same account. Miscellaneous, sundry, general and other are names that guarantee they will not, and an account named General expenses will absorb anything anyone is unsure about, which is exactly the population you most need to see.

• Use a consistent length. Mixed-length codes sort unpredictably and break exports into anything that treats them as text.
• Leave gaps. Sequential numbering with no space forces either renumbering or an out-of-sequence account within a year.
• Group by statement classification first, so the account list sorts into report order without an extra mapping layer.
• Keep sub-ranges meaningful. If an account is in the current asset range, it should be a current asset, with no exceptions carried for historical reasons.
• Do not encode dimensions in the number. A code that means rent, branch two is a dimension in disguise.
• Do not renumber existing accounts. The cost falls on history, integrations and everyone who has memorised a code, and the benefit is cosmetic.

Control accounts and what must not be posted directly

Some balance sheet accounts summarise a subledger. Receivables, payables, inventory, fixed assets and usually tax each have a single ledger account whose balance should equal the total of a detailed listing held elsewhere. These are control accounts, and the design decision that matters is that they must not accept direct postings.

When a user can post a manual journal straight to the receivables control account, the control account and the subledger diverge, and the divergence is only discovered when someone reconciles. Making control accounts non-postable, or restricting direct posting to a small number of named people who are correcting a known error, converts a monthly detective control into a structural one. It is one of the cheapest improvements available in most implementations and it is very often not configured.

A related structural point is that not every account should be postable at all. A well-built chart has header or summary accounts that exist to group and to report, and postable accounts beneath them. Posting to a header defeats the hierarchy and produces a balance that appears in a total but not in any of its components, which is one of the more confusing things a report can do.

Clearing accounts need the same explicit design. Goods received not invoiced, payroll clearing, intercompany clearing, stock in transit and gateway settlement should each be defined at the point the chart is designed, with a stated normal balance and a named owner, rather than being created ad hoc later by whoever first needed somewhere to put something. Accounts created ad hoc are the ones that never get reviewed.

Designing for the statements you have to produce

A chart of accounts should be designed backwards from the outputs it must feed. There are usually four: the statutory financial statements, the management accounts, the tax returns, and whatever the parent or lender requires. Each of these imposes a level of detail, and the chart has to hold the finest of them.

IAS 1 requires certain line items to be presented on the face of the primary statements and permits aggregation of immaterial items, with further detail in the notes. That is a presentation requirement rather than a chart of accounts requirement, but it drives one: any line the statements or the notes must disclose separately has to be separately identifiable in the ledger, either as an account or as a dimension. Depreciation, employee benefit costs, finance costs and impairment losses are common examples, and a chart that lumps them into general categories cannot produce the disclosure without an analysis exercise every year.

Tax adds its own requirements, and they differ from accounting ones. Expenses that are disallowable for tax, entertainment being the usual example, are far easier to identify if they were posted to their own account from the start than if they have to be extracted from a general account annually. The same applies to input tax that cannot be recovered, and to any category that carries a different tax treatment.

Management reporting usually wants the opposite of statutory reporting: less structure, more dimensions. It wants gross margin by product line, cost by department, and contribution by branch, none of which the statutory statements care about. This is precisely why the split between accounts and dimensions is the right architecture. Accounts serve the statutory view, dimensions serve the management view, and both come from the same postings without a second set of books.

Multi-entity and consolidation

Where a group has several legal entities, the strongest position is a single group chart of accounts used by all of them, with entity-specific accounts added only where local law genuinely requires it. Consolidation then becomes a matter of summing like accounts and eliminating intercompany balances, rather than a mapping exercise that has to be maintained and re-verified every period.

The usual objection is that entities differ, and they do, but less than expected. A trading company and a service company use largely the same expense structure. What differs is which accounts they use, not what the accounts mean. Unused accounts in an entity cost nothing; divergent account meanings between entities cost a reconciliation every month and produce consolidated numbers that nobody can decompose.

Where entities have inherited different charts, and most groups acquiring companies will, the mapping layer that translates them is a permanent liability. It has to be maintained when either chart changes, it has to be verified, and it is invisible in the consolidated output, so an error in it produces a consolidated number that is wrong in a way that no reconciliation of either entity would detect. Converging to a common chart is expensive once and cheaper thereafter.

Intercompany accounts should be explicit and paired: a separate receivable and payable account per counterparty entity, not a single intercompany account holding a net balance with everyone. Elimination on consolidation depends on knowing which entity each balance is with, and a net balance in a single account cannot be eliminated without a further analysis that somebody has to do by hand.

How to actually design one

The method is short and the discipline is in following it rather than skipping to the account list, which is what usually happens.

The sixth step is the one that finds the design errors, and it is the one most often skipped because it feels like duplicated effort. It is not. Producing a real statutory statement, a real management pack and a real tax computation from a real month of transactions will reveal, in an afternoon, the three things you cannot report on. Finding them then costs nothing. Finding them in month four costs the change described below.

• List the outputs first: statutory statements, tax returns, management reports, lender or parent requirements. These define the minimum detail.
• Identify the dimensions. Walk through the business and name every way somebody will want to slice a number. Each one is a dimension unless it changes the nature of the amount.
• Only then write the account list, working from the statement structure downwards, and stopping at the level where a further split would answer a dimension question rather than a nature question.
• Mark control accounts and header accounts as non-postable, and define every clearing account deliberately with a normal state and an owner.
• Write the posting rules: which account each transaction type maps to, since this mapping layer is where audit trails are actually lost.
• Test it against last year. Take a period of real transactions and post them into the new structure, then produce all four outputs from the result.
• Write it down. An account list without a document saying what belongs in each account will be interpreted differently within a year.

What changing it later costs

Charts of accounts do change, and the cost is not the change itself. Creating accounts is trivial. The cost is everything attached to the old structure, most of which is not visible from the account list.

For that reason, most changes should be additive rather than structural. Adding an account, splitting one account into two prospectively from the start of a financial year, or introducing a dimension alongside the existing structure are all manageable. Renumbering the whole chart, merging accounts with history, or changing the meaning of an existing account are not, and the last of those is the worst because nothing visibly breaks; the report simply becomes wrong.

The right moment for a structural change is the start of a financial year, planned, with the old and new structures documented, a mapping retained permanently, and the first period after the change reconciled both ways. Doing it mid-year to solve an urgent reporting problem produces a year of accounts that nobody can compare to anything.

• History. Old transactions sit in old accounts. Either you remap history, which alters posted periods, or you accept that comparatives cross a discontinuity and every year-on-year report needs a bridge.
• Mappings. Every integration, every posting rule, every bank feed rule, every recurring journal and every import template references account codes and has to be found and updated.
• Reports. Financial statement layouts, management packs, budgets, dashboards and any spreadsheet that pulls a trial balance by code all break, and they break silently, by omitting a new account rather than by failing.
• Budgets and forecasts. A budget built on the old structure cannot be compared with actuals on the new one without a mapping that is itself a source of error.
• People. Everybody who codes an invoice has memorised codes, and the transition period generates mispostings that then need correcting.
• Audit. The auditor needs to understand the change, satisfy themselves that the restated comparatives are consistent, and test the mapping. This is a conversation to have in advance rather than in the field.

Signs the design is wrong

Most businesses do not review their chart of accounts because there is no event that forces them to. These are the signals that it is costing you, all of which are visible without a project.

None of these is fatal on its own. Several together mean the structure is encoding facts about the business that have since changed, and every report built on it is carrying that cost quietly.

• The same word appears repeatedly across the account list, which means a dimension is being carried in the account code.
• A large share of accounts have no transactions in the current year, which means the structure has outlived the organisation it described.
• Producing the management pack requires a spreadsheet that maps accounts to report lines, maintained by one person.
• A general or miscellaneous expense account carries a material balance, which means people cannot tell where things belong.
• Answering a routine question, such as cost by branch or margin by product line, requires a data extract rather than a report.
• Opening a new branch or department is a configuration project rather than adding one dimension value.
• Two people asked where a given cost is posted give different answers.

Governance

A chart of accounts degrades through small decisions made under time pressure. Someone needs an account for a new cost, creates one, names it after the supplier, and posts to it. Five years later there are two hundred such accounts, and the structure that was designed carefully has been diluted by things nobody decided.

The control is ordinary and effective: creating or changing an account requires approval by a named person against a written definition of the structure, and the change is logged. That approver asks one question, which is whether the new thing is a different kind of amount or a different context for an existing one. Most requests are the second, and the answer is a dimension value rather than an account.

Skyline Nexus carries branch and location on the transaction itself, and every ledger line links back to the document that produced it, so a view by branch is a join to the source rather than a structure rebuilt out of account codes. It is worth asking of any system, including this one, exactly which dimensions the ledger LINE stores and which are only present on the source document: the difference decides whether a dimensional report is a direct read or a reconstruction, and whether it survives when a document type changes. That describes what a system holds. It does not decide your design, and no system prevents a chart of accounts that encodes in account codes what should have been a dimension.

• A written chart of accounts document stating what belongs in each account, kept current.
• Account creation and amendment restricted and approved, with a logged reason.
• An annual review of accounts with no activity, and of any account absorbing miscellaneous items.
• Posting rules and mappings reviewed whenever a source system changes, since this is where trails are lost.
• Dimension values governed the same way as accounts, since an uncontrolled dimension list becomes its own proliferation.

A reasonable default

For a business without an unusual reporting requirement, the following shape works and is worth deviating from only for a stated reason. A few hundred accounts, grouped by statement classification with wide gaps. Accounts split only where the nature of the amount differs or a statutory or tax disclosure requires it. Three to five dimensions, of which branch or location, department or cost centre, and project are the usual set. Control accounts and headers non-postable. Clearing accounts defined and owned. And a written definition of what belongs where.

That structure will produce statutory statements, a management pack sliced several ways, and a tax computation, from one set of postings and without a mapping spreadsheet. It will survive a new branch, a reorganisation and an acquisition without a restructuring project. And it will keep the account list small enough that the person coding an invoice can find the right account, which is, in the end, the constraint that determines whether any of the rest of it works.

The chart of accounts is the one part of a finance system where an hour of design saves a year of work, and where the consequences of getting it wrong appear slowly enough that nobody connects them back to the cause. If you are implementing a system, spend the days. If you are already live and recognise the symptoms above, plan the change for a year end rather than living with it, and make it additive wherever you can.