ERP implementations are almost universally approached as accounting projects. The project team designs the chart of accounts to satisfy the statutory reporting requirements. The configuration decisions are made by the implementation consultants with input from the Treuhänder or accounting function. The go-live produces a system that handles invoices, payroll, and bank reconciliation correctly and produces clean statutory accounts.
Six months later, the controller sits down to produce the management report and discovers that the system cannot produce it. There are no cost centres. The chart of accounts aggregates costs that need to be separate. The profit centre structure does not match how the business is actually managed. The budget module was never configured. Every management report has to be built manually from scratch every month.
This is not a failure of the ERP system. It is a failure of the implementation design. The accounting requirements were satisfied. The controlling requirements were never specified.
This article covers the controlling-relevant decisions that ERP implementations typically get wrong and how to get them right, whether you are in an implementation now or trying to fix a system that went live without proper controlling configuration.
The Governing Principle: Design for the Report You Need
Every configuration decision in an ERP implementation should start from the same question: what management reports does this business need, and what data structure is required to produce them?
This sounds obvious. It is almost never the starting point. Instead, implementations start from the accounting requirements, the available templates, or the consultant’s standard configuration package, and the management reporting needs are retrofitted onto whatever structure was chosen for other reasons.
The alternative is a reporting-first design process. Before the chart of accounts is built, produce a mockup of every management report the finance function needs to produce: the monthly management P&L by segment, the cost centre report by function, the cash flow statement, the KPI dashboard. For each report, identify the data dimensions it requires. The chart of accounts, cost centre structure, profit centre structure, and any other configuration dimensions then follow from those requirements.
Cost Centres: Design Them Before Go-Live
Cost centres are the primary management accounting dimension in most ERPs. They represent the organisational units that consume resources and are held accountable for costs.
The cost centre design should reflect how the business is actually managed and how management accountability is structured, not the legal entity structure or the org chart as it existed three years ago.
Two principles guide the design. First, every cost centre should have a named manager who is accountable for its costs. A cost centre with no clear owner is a cost that cannot be managed. Second, the cost centre hierarchy should aggregate to the levels at which management reviews and acts on cost information: team level, department level, business unit level, total company.
Common mistakes in cost centre design: too few cost centres, which produces aggregated costs that cannot be analysed; too many cost centres, which creates a maintenance burden and forces users to make judgment calls about which cost centre to use on every posting; and a structure that reflects the org chart at go-live and becomes obsolete within 18 months as the organisation changes.
The practical recommendation: design the cost centre structure for where the business will be in three years, not where it is today. Adding a cost centre is straightforward. Splitting a cost centre that has been in use for two years, while maintaining historical comparability, is painful.
Profit Centres: The Segment P&L Foundation
Profit centres are the dimension that enables segment-level P&L reporting: by product line, by geography, by business unit, by customer type, or by any other dimension that reflects how management thinks about the business.
The profit centre structure should match the segment structure of the management P&L. If the management report shows P&L by product line, there should be a profit centre for each product line. If it shows P&L by geography, there should be a profit centre for each geography. The two structures need to be aligned, or the profit centre report will not match the management report.
The critical configuration requirement is ensuring that every revenue and cost transaction in the system carries a profit centre assignment. This is achieved through a combination of automatic assignment rules (a specific customer is always assigned to a specific profit centre, a specific product is always assigned to a specific profit centre) and validation checks that prevent postings without an assignment.
A partial implementation, where some transactions carry profit centre assignments and others do not, produces a profit centre report with an “unassigned” column that makes the segment analysis unreliable. Getting the assignment coverage to above 95 percent before go-live is a more important quality metric than most implementation checklists include.
The Budget Module: Configure It Before the First Budget Cycle
The first budget cycle after an ERP go-live is typically chaotic if the budget module was not configured as part of the implementation. The team ends up loading budget figures into a spreadsheet and maintaining the budget-to-actual comparison outside the system, which defeats the purpose of having an integrated ERP.
Configuring the budget module before go-live requires three things: a plan version (a named budget cycle, such as “Budget 2025”), a budget entry structure that matches the cost element and cost centre/profit centre structure, and the report configuration that will show actual versus plan comparisons.
The plan version is the container for the budget. The ERP can hold multiple plan versions simultaneously: the original budget, a mid-year re-forecast, and a prior year actual can all be held as separate plan versions and compared in any combination. This capability requires the plan versions to be configured correctly before any data is loaded.
Budget entry in most ERPs can be done either through manual input screens or through a structured Excel upload. The Excel upload is almost always preferable for the initial budget load, as it allows the budget to be built outside the system (where it is easier to collaborate and review) and then loaded cleanly once it is approved.
Dimensions Beyond Cost Centres and Profit Centres
Depending on the business model, additional dimensions may be relevant and worth configuring at go-live.
Projects and internal orders are the right tool for tracking costs against a specific initiative, capital expenditure item, or client project. They allow budget and actual tracking at a finer level of granularity than cost centres, with automatic settlement to cost centres or assets when the project is complete.
Business areas are useful for companies operating multiple legal activities within a single legal entity that need separate statutory-looking P&Ls. They sit between the legal entity level and the profit centre level in the reporting hierarchy.
Functional areas allow costs to be classified by function (production, sales, administration) independently of the cost centre, which supports the functional P&L format often required for group reporting.
Not every business needs all of these dimensions. The selection should be driven by the reporting requirements, not by what the implementation consultant proposes as a default. Adding unnecessary dimensions creates complexity in transaction entry and maintenance. Each dimension should earn its place by enabling a specific report that matters.
The Most Expensive Mistake: Not Involving the Controller
The most expensive mistake in ERP implementations is treating the controlling configuration as an afterthought. The system goes live, the accountants are happy with the statutory outputs, and the controller inherits a system that was not designed for management reporting.
Fixing the configuration after go-live is significantly more expensive than getting it right before go-live, because live data is now in the system and any structural change affects historical comparability. Re-assigning cost centre hierarchies, splitting accounts that should have been separate from the start, and retroactively applying profit centre assignments to transactions that were not coded correctly all create data quality problems that take months to resolve.
The controller should be in the room when the implementation configuration is designed, with a clear specification of the management reports required and the data structure they depend on. That specification, reviewed and signed off by the controller before go-live, is the deliverable that protects the management accounting capability of the new system.
Need help getting better reporting from your ERP? Download professional Excel templates or book a free call.
Alessandro Ratzenberger is a fractional CFO and business controller based in Zurich, with 15 years of operational finance experience at Dufry Group and Bomi (UPS Group).
