The CFO’s role in ERP selection and implementation
ERP projects are often finance projects rather than technology projects. The work the CFO should own, from selection to go-live.
ERP selection usually starts as an IT project, but its consequences fall hardest on the finance function. The chart of accounts, product costing, approval workflows, reporting and internal controls are all designed inside the ERP. Get them wrong and you live for years with manual corrections, spreadsheet exports and unreliable reports. That is why the CFO’s role in ERP selection and implementation goes far beyond supporting the IT team. In this article I walk through that role stage by stage, from requirements to go-live.
Why it is a finance project
Most of the data an ERP produces ends up as an accounting entry: sales invoices, stock movements, purchases, production costs, payroll, fixed assets. Whether those entries land in the right accounts, cost centres and periods depends on how the system is designed from the start. Much of internal control now also runs inside the system: who can do what, which amounts need approval, which fields cannot be changed. COSO’s internal control framework likewise addresses general controls over technology as one of its internal control principles.
Stage 1: Requirements
Before selection, the company’s finance requirements should be written down. At a minimum the analysis should answer:
- Which reports does management want to see, and by which dimensions (product, customer, branch, project)?
- How should costs be calculated: standard cost, actual cost, by project?
- How many entities and currencies, and which reporting frameworks (statutory, IFRS or local frameworks) must be handled?
- What approval workflows and authority limits are needed?
- Which integrations are required with banks, e-invoicing and statutory e-ledger systems, payroll and other applications?
Without these answers, the selection is driven by how impressive the demo looks. The real question is whether the system meets the company’s reporting and control needs without custom development.
Stage 2: Selection criteria
| Criterion | Why it matters for finance |
|---|---|
| Local compliance | Statutory e-invoicing, e-ledger and reporting requirements met as standard |
| Multi-entity and consolidation | Eliminating intercompany transactions and producing group reporting from the system |
| Costing flexibility | The company’s costing method can be modelled in the system |
| Reporting and data access | Management reports produced without manual intervention |
| Access rights and audit trails | Role-based access and changes traceable after the fact |
| Total cost of ownership | Licences, implementation, customisation, maintenance and internal time assessed together |
| Implementation partner experience | References for finance modules at similar scale and in a similar sector |
Total cost of ownership needs particular care. The licence fee is usually only part of the total; implementation consulting, customisation, data migration, training and the internal staff time devoted to the project often exceed it. The choice should be made on a five-year total cost basis.
Stage 3: Design — the chart of accounts and dimensions
The CFO’s most critical contribution to ERP design is the chart of accounts and the analysis dimensions (cost centre, product group, region, project). The principles of a good design:
- Keep the chart of accounts lean: meet analysis needs with dimensions, not by adding accounts. Rather than an account per customer or product, report the same account by different dimensions.
- Think about statutory and management needs together: build a clear mapping between the statutory chart and management reporting.
- Write the report before the design: draft the management report and budget format first, then configure the system to produce them.
Stage 4: Embedding controls in the system
An ERP implementation is one of the best opportunities to strengthen internal control. These controls should be built in at the design stage:
- Role-based access, with incompatible duties (such as creating suppliers and making payments) not combined in one user
- Amount-based approval workflows
- Blocking postings to closed periods
- Approval and audit trails for master data changes (bank account numbers, price lists)
- Three-way matching: an invoice is not released for payment until order, goods receipt and invoice match in the system
I discuss how to achieve segregation of duties in small teams in segregation of duties and compensating controls.
Stage 5: Data migration
Data migration is the most underestimated step in ERP projects. The data to migrate usually falls into three groups: master data (customers, suppliers, products, the chart of accounts), opening balances, and open items (open invoices, open orders, stock quantities). The CFO’s responsibilities at this stage:
- Clean the data in the old system before migration: close unused records and merge duplicate customers and suppliers
- Reconcile opening balances to the old system and keep a signed reconciliation file
- Time the cutover, where possible, to the start of a period (month or year)
Stage 6: Testing and parallel running
Before go-live, finance processes should be tested end to end: how a sale flows from order to cash, a purchase from requisition to payment, and a production order from material issue to cost. A trial close at the end of testing, with trial financial statements compared against the old system, is the most reliable check. If possible, run the first month’s close in both systems in parallel and explain the differences.
Common mistakes
- Moving existing processes to the new system without questioning them (“make it work like the old one”)
- Over-customisation: paying for custom development where standard functionality would do, which makes upgrades harder
- Involving the finance team too late
- Leaving user training to the last week before go-live
- Scheduling go-live at the same time as the year-end close and the external audit
Finance team roles in the project
The finance team’s contribution to an ERP project should not be limited to the CFO attending decision meetings. Throughout the project these roles should be clear on the finance side:
| Role | Responsibility |
|---|---|
| Finance project owner (usually the CFO) | Approving design decisions, scope and budget changes, the go-live decision |
| Key user (one per process) | Taking part in process design, writing and running test scripts, training other users |
| Data owner | Cleaning master data, preparing migration files, reconciling opening balances |
| Controls owner | Checking that the delegation of authority, approval workflows and audit trails match the design |
Key users need to be relieved of part of their day-to-day work during the project. When the finance team has no time for the project, the consultants end up designing the system and finance spends the months after go-live trying to bend it to its needs.
The first closes after go-live
Go-live is not the end of the project but the start of its riskiest period. In the first two or three closes these checks matter most: reconciliations between the sub-ledgers (sales, purchasing, inventory) and the general ledger, consistency of inventory valuation with the old method, accuracy of bank integrations and comparability of management reports with prior periods. Plan a fast support channel for errors found in this period and a weekly issue-tracking meeting.
Conclusion
ERP selection and implementation determine the efficiency and control quality of the finance function for years to come. The CFO’s role is to put requirements in writing, design the chart of accounts and the reports, embed controls in the system and make sure migrated data and opening balances are right. I covered how to structure the finance team in how to structure the finance team, and how e-ledger data can be used for analysis in what e-ledger data can reveal. You can read about my work on the financial management page.