In an ERP project, most decisions can be corrected later. You can adjust a purchasing workflow after three months, replace a report, revisit a VAT setting. The chart of accounts is different: once journal entries have been posted, budgets loaded and financial statements produced, changing it means reopening the foundations of a building while people are working inside.
Yet it is one of the topics projects tackle latest, often in a configuration workshop whose only input is an export of the old system’s chart of accounts. The result: years of accumulated clutter (accounts created for a one-off need, accounts per site, accounts per customer) get carried into a tool designed to work differently.
This article is for CFOs, financial controllers and finance project leads. It covers the design decisions to make before configuring: statutory and group charts of accounts, accounts versus dimensions, seven structural decisions, historical data migration, governance after go-live and common mistakes.
Why the chart of accounts is the most structuring decision
The chart of accounts is the shared vocabulary of finance. Everything depends on it:
- Statutory reporting: balance sheet, income statement, tax returns, VAT filings and, in France, the FEC accounting entries file, which reproduces your account numbers and labels exactly as they sit in the system. Other jurisdictions have their own equivalents, such as SAF-T in much of Europe.
- Management reporting: margin by business line, cost by department, budget tracking. If the information is not carried by the account or a dimension at posting time, it has to be rebuilt later with debatable allocation keys.
- Consolidation: every subsidiary must be able to map to a common structure.
- ERP automation: automatic posting of purchases, sales, inventory and fixed assets. These account determination rules point to specific accounts. A poorly thought-out chart multiplies rules and exceptions.
Why is it so hard to fix after go-live? Because three things freeze at the same time. Comparative history is stored in the old structure. Users have memorized their accounts and built spreadsheets around them. And reports, reconciliations and interfaces (payroll, bank, expense claims, billing) reference accounts by hard-coded values. Changing an account means changing all of this in a coordinated way.
The good news: an ERP project is the only window in which a redesign is realistic. Teams are mobilized, data is being cleansed, and management accepts that finance will change its habits. That window closes in the first month of production.
Statutory chart or group chart: one or two?
Every entity must keep books that comply with its local framework (local GAAP, such as the French PCG, the German SKR or UK FRS 102). The group, meanwhile, needs a consistent view, usually under IFRS or an internal management framework. Three models exist.
Model 1: a single chart, the local one. Each entity works on its statutory chart, and the group adjusts at consolidation, usually in a dedicated tool (see our article on group financial consolidation). It is the simplest model for a single-country SMB. Its weakness: the mapping to the group lives outside the ERP, and therefore outside posting discipline.
Model 2: a single chart, the group one. All entities post on a common structure, and local requirements are handled with additional accounts or attributes. Local statutory reports become a view of this common chart. It is elegant for a homogeneous group, but local constraints (mandatory numbering, required statements) can become heavy.
Model 3: two charts in parallel, with mapping. Each local account is linked to a group account, and the ERP maintains both views, depending on its capabilities. This is the most common model in multi-country groups, at the price of rigorous mapping work and ongoing maintenance.
The choice criterion is not primarily technical. It comes down to three questions: how many entities and countries, how much local autonomy, and who needs what (the local tax authority, the auditor, the executive committee, the banks). Then check what your vendor offers natively, because ERPs do not all provide the same mechanisms for parallel charts or alternate accounts.
The multi-country case
In a group present in several countries, two pitfalls keep coming back:
- Imposing the group chart everywhere without regard for local obligations: tax returns, statutory statements, filing formats. Subsidiaries then build parallel adjustments in spreadsheets, which is the opposite of the goal.
- Letting each country decide: the group ends up with as many charts as entities, and consolidation becomes a permanent project.
The reasonable path is a stable group core (classes, main balance sheet and P&L headings, intercompany accounts) to which each country maps its statutory accounts through a correspondence table maintained by an identified owner. This is the same logic as an international deployment template: a common core, controlled local extensions.
One point of attention for intercompany accounts: they should be identified separately, with a partner dimension (the counterparty entity), so that elimination at consolidation does not rely on manual matching. The topic is covered further in our article on multi-entity, intercompany and multi-currency (in French).
Accounts or dimensions: stop creating an account per cost center
This is the most profitable paradigm shift in a redesign, and the one legacy systems prepared you for the least.
The historical reflex. In many companies, the chart of accounts carries both the nature of an expense and its context. A common example: a series of expense accounts with one account per site, say a supplies account for the Manchester plant, another for the Rotterdam warehouse, a third for headquarters. For ten expense types and eight sites, that is eighty accounts instead of ten. Each new site adds ten more. Each reorganization forces you to close and open accounts.
The dimension logic. Modern ERPs separate these notions. The account says what it is (economic nature: supplies, professional fees, rent). Dimensions say where, for whom, for what (site, cost center, project, business line, customer). The same supplies account is then used everywhere, and the breakdown is read by crossing account and dimension.
Vendors implement this principle with their own mechanisms and vocabulary. For example: financial dimensions in Microsoft Dynamics 365 Finance, the segmented chart of accounts structure in Oracle Fusion Cloud, profit centers and cost centers in SAP. Exact capabilities (number of dimensions, combination rules, performance impact) vary by version and license: check them in your vendor’s documentation and with your integrator before freezing the design.
What you gain:
- a shorter chart, therefore more readable and easier to govern;
- the ability to open a site or a project without touching the chart;
- cross analyses (by site, business line, customer) without rework;
- reporting that survives reorganizations, since the dimension hierarchy can be changed without creating an account.
What you must manage: dimensions are not free. Each one has to be populated at posting time, which requires default values, validation rules and training. Too many mandatory dimensions slow users down and produce “dumping ground” values. We detail the mechanics of axes and cost centers in our guide to analytical accounting in ERP.
The 7 design decisions to make before configuring
Here are the seven decisions to settle, in this order, before the first configuration workshop.
1. Account number length and logic
Set the length of account numbers taking into account the constraints of your legal framework and your ERP, then reserve room for growth. Numbering that follows the structure of the local chart (classes, sub-classes) makes it easier for accountants and auditors to read. Avoid encoding in the number information that should be dimensions (site, business line): that is the trap described above. Document the logic on one page, with examples, so that future account creators understand it.
2. Level of detail
An account should exist if it meets an obligation (legal, tax, contractual) or a recurring management need that a dimension cannot carry. Test each account with two questions: who looks at this balance, and what decision do they take? No answer, no account. Conversely, do not merge what tax law distinguishes (for example, expenses with different VAT or deductibility treatment): you would lose the ability to produce statements without rework.
3. Control accounts and subledger accounts
For customers, suppliers and employees, the common practice is to keep a few control accounts and carry the detail in subledger accounts per third party, held in the ERP’s business partner master. Decide how many control accounts you want (for example, to separate group customers, export customers, bills receivable, fixed-asset suppliers) and how the control account is determined when a partner is created. A partner attached to the wrong control account distorts the aging report and the filings, and is hard to correct once entries are posted.
4. Mandatory dimensions
List the candidate dimensions (site, cost center, project, business line, product, customer, intercompany partner), then classify them: mandatory on all accounts, mandatory on certain accounts (for example cost center on all expenses, project only on project cost accounts), optional. Set the validation rule: an entry without the required dimension must be rejected at posting, not fixed at close. Limit the number of mandatory dimensions to those that really serve management, and provide defaults derived from context (the requester’s cost center, the store’s site).
5. Reporting hierarchies
Hierarchies are where flexibility lives. Plan at least: a statutory hierarchy (balance sheet, income statement), a management hierarchy (margin, contribution, overheads) and a group hierarchy if you consolidate. Built outside the account number, they let you change the presentation without touching entries. Check that they feed your reporting and BI tool directly: that is the subject of our guide to ERP reporting and dashboards. A hierarchy that exists only in a spreadsheet is not a hierarchy, it is a liability.
6. Closing and technical accounts
Period-end entries (provisions, accruals, deferred income, exchange differences, adjustments, current-year result) need dedicated accounts, reversal rules and identified journals. Define them at design stage, in line with the close calendar (monthly close and year-end close). Also plan suspense and transition accounts: indispensable during migration, they must be cleared and locked after go-live, otherwise they become a dumping ground.
7. Governance of account creation
Decide now who can request, approve and create an account or a dimension value, through which process and within what lead time. Without this rule, the chart turns back into what you just cleaned up within eighteen months. The detail is covered below.
Migrating history: mapping table, opening balances, comparatives
A chart redesign requires linking old and new. This is the direct point of contact with the ERP data migration workstream.
The old/new mapping table. This is the pivot document: for each old account, the target account or accounts and the dimension values to populate. Three cases arise:
- one to one: the account is simply renumbered;
- many to one: several old accounts merge (per-site accounts become a single account plus a site dimension);
- one to many: an old catch-all account has to be split, which requires a rule or a human decision.
The third case is the most expensive. Deal with it early, with the accountants, and keep a record of every decision.
Opening balances. Load them in the target structure, with their dimensions (for example, the balance of a prepaid expense account broken down by cost center if it was). For third-party accounts, load open items in detail (open invoices per partner) rather than as a global balance, so that matching and dunning work from day one. Reconcile: total of the source trial balance equals total of the target trial balance, account by account after applying the mapping table. Do this reconciliation at every migration rehearsal.
Prior-year comparatives. This is what finance departments forget most. Two options:
- load the previous year’s entries, converted through the mapping table, so comparatives can be produced in the new tool;
- keep the old system available for read-only access and produce comparatives outside the ERP for one financial year.
The first is more comfortable for users but requires careful conversion; the second is simpler but means maintaining the old tool and its access rights. Either way, decide before the final design, because it determines the granularity of the chart. Also consider accounting record retention obligations, covered in our article on the ERP audit trail.
Governance after go-live: who creates an account, and through which workflow
A well-designed chart of accounts degrades bit by bit if nobody owns it. Four elements are enough to stay on course.
An owner. One person, usually in general accounting or financial control, is responsible for the chart of accounts and dimension values. Not a faceless committee: a named person, with a deputy.
A request workflow. Every creation goes through a structured request: justification (obligation, management need), existing accounts or dimensions considered, impact on reporting hierarchies, impact on interfaces. The owner approves; the ERP administrator executes. Separate these two roles: the requester does not create, and the approver is not the one who enters. This segregation of duties ties in with the internal controls discussed in our article on ERP access governance.
A clear refusal criterion. The first answer to a request for a new account is: “wouldn’t a dimension do the job?” That single question prevents most unnecessary creations.
An annual review. Before the year-end close, review accounts with no activity, uncleared suspense accounts, obsolete dimension values and accounts not attached to a hierarchy. Block posting on what is no longer used rather than deleting it (deletion is generally impossible once entries exist, which is fortunate for the audit trail).
Common mistakes and countermeasures
| Common mistake | Consequence | Countermeasure |
|---|---|---|
| Copying the old ERP’s chart | Historical workarounds are migrated into the new tool | Redesign from requirements; use the old chart as input, not as a template |
| One account per site, project or customer | Chart grows with every opening, rigid reporting | One account per economic nature, context carried by dimensions |
| Encoding information in the account number | Unreadable numbering, hard to evolve | Reserve the number for the nature, use dimensions for the rest |
| Too many mandatory dimensions | Slow posting, catch-all values, user rejection | Limit to dimensions useful for management, defaults, validation at posting |
| Optional dimensions everywhere | Incomplete analysis, rebuilt through allocation keys | Make mandatory by account family, reject incomplete entries |
| Group/local mapping managed in a spreadsheet | Fragile consolidation, errors at every close | Build the mapping into the ERP or consolidation tool, with an owner |
| Forgetting prior-year comparatives | No comparison at the first reporting date | Decide early: converted history load or old system kept |
| Suspense accounts never cleared | Unexplained balances, audit risk | Dated clearing plan, locked after go-live |
| No owner for the chart | Drift within months | Named owner, request workflow, annual review |
| Designing without e-invoicing or statutory file constraints | Labels or structures that force rework at export, accounts that do not match expected types | Validate the design with the accountant and with e-invoicing and statutory file requirements |
Where to start
Chart of accounts design is prepared ahead of configuration, with three short deliverables: a principles note (one to two pages: chart model, numbering rules, list of dimensions and whether each is mandatory), a draft chart and hierarchies reviewed by accountants and financial control, and the old/new mapping table. Submit the note to the finance leadership before the first workshop: it is the cheapest decision in the whole project.
To go deeper into the management side behind the chart of accounts, read our guide to analytical accounting in ERP, then the article on management control and budget steering. To receive upcoming ERP design guides, subscribe to the newsletter. If you are preparing a chart of accounts redesign in an ERP project, contact DigitsLane to frame the design with you.
