Most reporting problems get blamed on the report. The board pack takes too long, departmental figures don't reconcile, and every new question from the executive needs a spreadsheet.
In many organisations the real cause sits further back, in the chart of accounts structure the ledger was built on, often years ago and by people who have since moved on.
A chart of accounts decides which questions your finance system can answer without manual work. Get it right and reports come straight out of the ledger. Get it wrong and the finance team spends every month re-coding, re-mapping and explaining.
This guide is written for finance directors and financial controllers in mid-market and multi-entity organisations. It covers what a well-structured chart of accounts looks like, how to separate nominal codes from analysis dimensions, the failure patterns to watch for, and how to redesign without losing year-on-year comparability.
A chart of accounts is the structured list of codes an organisation uses to record every financial transaction in its general ledger. Each code represents an income, expenditure, asset, liability or equity account. Together, those codes decide how transactions are grouped, and so which reports the finance system can produce directly.
Most finance teams think of the chart of accounts as an accounting matter: which nominal code does this invoice go to? It is also a reporting design decision. Every report you produce is, in effect, a query against the way the ledger was coded. If the coding can't separate a cost, the report can't either.
That is why two organisations of the same size, on the same software, can have very different month-ends. One produces its management accounts straight from the system. The other exports to Excel, re-maps a few hundred lines and adds manual adjustments before anyone sees a number.
A well-structured chart of accounts keeps nominal codes few, stable and focused on the nature of a transaction (what was bought or earned). Everything else, such as who spent it, where, on which project and in which entity, belongs in separate analysis dimensions. Codes should sit in logical numeric ranges that map cleanly to your statutory accounts.
In practice, a good structure has four characteristics:
The numbering convention matters less than its consistency. One common pattern looks like this:
Notice what is missing from that list. There is no "Marketing department – printing" code and no "Leeds site – utilities" code. Department and location are not types of transaction, so they don't belong in the nominal code.
A nominal code records what a transaction is, such as stationery, salaries or tuition fee income. An analysis dimension records the context around it: the cost centre, department, project, fund, site or entity it belongs to. Keeping the two separate lets you report any combination without creating a new code for each one.
The difference is easiest to see with an example. Take a £400 printing invoice for the marketing team's open day campaign.
With the second approach, the same transaction answers several questions. How much did we spend on printing across the organisation? What did the marketing cost centre spend? What did the open day cost in total, across every team involved? None of those needs a spreadsheet.
Typical dimensions for a mid-market or multi-entity organisation include:
Resist adding dimensions for the sake of it. Each one is a field someone has to code correctly on every transaction. If nobody will report on a dimension, it is a data-quality cost with no return.
Charts of accounts rarely fail through one bad decision. They drift. Each new code solves a real problem on the day it is created, and nobody is responsible for the shape of the whole. Three patterns account for most of the damage.
The nominal ledger grows to hundreds or thousands of codes, many unused, many near-duplicates. Staff pick whichever looks closest, so similar spend lands in different places. Reports become long, budget holders lose trust in them, and the finance team spends time reclassifying rather than analysing.
A quick test: export a year of transactions and count how many nominal codes carry fewer than ten postings. If it is a large share of the list, you have sprawl.
This is the printing example above, repeated across the ledger. When departments, sites or projects are built into nominal codes, every reorganisation means new codes, and history stops lining up. A department that merges or splits breaks your year-on-year comparisons overnight.
In a group, each entity often grows its own chart of accounts. One subsidiary codes agency staff to 7100, another to 7350, a third splits it three ways. The figures are correct in each set of books, yet the group can't compare like with like.
Consolidation then depends on a mapping spreadsheet that one person understands. Every month, that spreadsheet becomes the real chart of accounts, sitting outside the system and outside any audit trail.
A multi-entity group should use one shared chart of accounts across every entity, with entity recorded as a dimension rather than built into the codes. Local variation is allowed only where a statutory or regulatory requirement demands it, and even then it should roll up to a common group code.
A shared structure delivers three practical benefits:
The hard part is governance, not design. Subsidiaries that joined through acquisition, or academies and colleges that merged into a group, often have finance teams attached to their own codes. Agree the group structure centrally, explain the reporting it will make possible, and give entity teams a clear route to request changes.
This is also where the finance system matters. In bluQube, for example, entities can share a common chart of accounts managed centrally, with entity and other analysis held as dimensions, so group reporting and consolidation run from the same coding rather than from a mapping spreadsheet. For more on the reporting side, see Simplifying Financial Reporting for Multi-Entity Organisations and How To Prepare Group Consolidated Accounts: A Comprehensive Guide.
Redesign your chart of accounts when routine reports need manual re-mapping, when new entities or departments keep forcing new codes, or when the board asks questions the ledger can't answer. The most practical moment is a finance system change, because data is already being cleansed, mapped and migrated.
Warning signs worth taking seriously:
Replacing a finance system without restructuring the chart of accounts means paying to migrate the old problems. Every code you carry across becomes a code you have to map, test and train people on. If you are moving systems anyway, the extra effort of restructuring is modest, and the payback lasts as long as the new system does.
The opposite mistake is just as common: treating the migration as a chance to redesign everything at once, under go-live pressure. Decide the structure early in the project, before data mapping starts, and keep it deliberately simple.
The fear that stops most redesigns is losing history. It can be managed with a disciplined approach:
Keep the mapping table as a permanent record. Auditors may ask for it, and it answers the question someone will raise in three years' time about why a historic figure moved.
There is no right number, but fewer is usually better. A mid-market organisation that holds analysis in dimensions can often run on a few hundred nominal codes or fewer. If your list runs into thousands, it is likely that codes are carrying analysis that belongs elsewhere.
No single chart of accounts is mandated for UK companies. Statutory accounts must follow prescribed formats, so your codes need to roll up to those lines, but the codes themselves are your choice. Some sectors publish recommended structures, which are worth following where your sector body or funder expects them.
You can, but it complicates reporting for that year because comparisons span two structures. Adding the odd code mid-year is fine. A full restructure is best timed for the start of a financial year, ideally alongside a system change.
The financial controller or a nominated member of the finance team should own it, with clear rules for when a new code or dimension value is justified. Without a named owner, codes get added to solve local problems and the structure drifts.
A cost centre is an analysis dimension that identifies the part of the organisation responsible for income or spend, such as a department, faculty or team. It sits alongside the nominal code rather than inside it, so the same nominal code can be reported by any cost centre.
Good reporting is decided at the coding level, long before anyone opens a report writer. A sound chart of accounts structure keeps nominal codes few and stable, holds analysis in dimensions, and uses one shared structure across every entity in a group. Do that, and most of your management and group reporting can come straight from the ledger.
If your current structure has drifted, you don't need to fix it all at once. Start with a simple diagnostic this month:
Those three lists will tell you whether you need a tidy-up or a redesign. If a finance system change is on the horizon, put the redesign on the project plan from the start, because it is the cheapest moment you will get.
We use cookies to enhance your browsing experience, serve personalised ads or content and analyise our traffic. By clicking accept all, you consent to our use of cookies. Cookie policy.