Implementing a New ERP or Finance System as an FC

Few projects a Financial Controller leads carry as much risk and as much potential reward as the implementation of a new finance system. Done well, a new ERP or finance system transforms the efficiency, reliability and capability of the finance function for years to come — faster closes, better data, automated processes, richer reporting. Done badly, it is one of the most disruptive and costly failures a business can experience, capable of disrupting the ability to invoice customers, pay suppliers, close the books and report reliably. The difference between these outcomes depends heavily on how the implementation is led, and the Financial Controller is usually at or near the centre of it.

This guide is written for Financial Controllers who are leading, or about to lead, the implementation of a new finance system. It covers how to approach the project, the critical decisions and where they go wrong, the practical realities of running an implementation alongside the day job, the role of data and process in determining success, and how to manage the transition so that the business keeps running throughout. It is written from the perspective of the finance leader responsible for the outcome rather than the technical implementer, because the most common causes of failure are not technical but managerial — and those are exactly what the Financial Controller is positioned to get right or wrong.

Why Finance System Implementations Are So Risky

Finance system implementations fail more often than they should, and understanding why is the first step to avoiding it. The risk arises from several sources. The finance system sits at the heart of the business’s operations, touching almost every process, which means a problem with it has wide consequences. The implementation is complex, involving data migration, process change, configuration, integration with other systems, and the retraining of users, any of which can go wrong. And the project competes for attention with the ongoing work of running the finance function, which does not pause for the implementation. The combination of high stakes, high complexity and divided attention is what makes these projects so prone to failure.

Crucially, most failures are not caused by the technology itself but by how the project is run. Inadequate planning, poor data preparation, insufficient testing, weak change management, unrealistic timelines, and the underestimation of the effort involved are the recurring causes — all managerial rather than technical. This is actually encouraging, because it means the factors that determine success are largely within the Financial Controller’s control. A Financial Controller who understands where these projects go wrong, and manages deliberately against those failure modes, dramatically improves the odds of a successful implementation. The technology, in most cases, works; it is the implementation that succeeds or fails.

Getting the Foundations Right Before You Start

The most consequential decisions in an implementation are often made before the project formally begins, in the selection of the system and the definition of what the implementation is meant to achieve. Choosing a system that genuinely fits the business — its size, its complexity, its sector, its growth trajectory — rather than one that is over-specified or under-specified, sets the foundation for everything that follows. So does being clear about what the implementation is for: whether it is about efficiency, capability, scalability, or replacing a system that has reached the end of its life, because that purpose should shape the decisions throughout.

A common and costly error is to treat the implementation as a like-for-like replacement of the old system, simply recreating existing processes in new software. This misses most of the value, because the opportunity of a new system is to improve the processes, not just to move them. The Financial Controller who approaches the implementation as a chance to redesign and improve how the finance function works — to question the existing processes rather than replicate them — captures far more value than one who treats it as a technical migration. This requires thinking about the processes before the configuration, which connects to the broader discipline of optimising the month-end close and the other core finance processes the new system will support.

Data: The Make-or-Break Element

Data migration is where finance system implementations most often founder, and it deserves disproportionate attention. The new system has to be populated with the business’s data — the chart of accounts, the historical balances, the open transactions, the master data for customers, suppliers and products — and the quality of this migration largely determines whether the new system works from day one. Migrating poor-quality data into a new system simply moves the problems and adds new ones; the new system is only as good as the data it contains.

The discipline that prevents data disasters is to treat data preparation as a major workstream in its own right, started early and given proper resource. This means cleaning the data before migration — resolving the duplicates, the errors, the inconsistencies that have accumulated in the old system — rather than carrying the mess across. It means mapping the data carefully from the old structure to the new. And it means testing the migration thoroughly, verifying that the data has come across correctly before the system goes live. A Financial Controller who invests in data quality and migration testing ahead of go-live avoids the most common cause of implementation failure; one who underestimates the data effort, as many do, discovers the problems at the worst possible moment, when the new system is live and the data is wrong.

Testing and the Discipline of Not Going Live Too Early

The pressure to go live — from the timeline, the budget, the impatience of stakeholders — is one of the most dangerous forces in an implementation, because it pushes toward going live before the system is genuinely ready. Thorough testing is what stands between an implementation and a live-system disaster, and cutting it short to hit a date is a false economy that frequently proves catastrophic. The system must be tested across the full range of processes it will support, with realistic data and realistic scenarios, until there is genuine confidence that it works.

The Financial Controller’s role here is partly to hold the line on readiness against the pressure to rush. Going live with a finance system that has not been adequately tested risks exactly the operational disruption — the inability to invoice, pay, close and report — that makes these failures so damaging. A delayed go-live is far less costly than a failed one, and the Financial Controller who insists on genuine readiness, even at the cost of the original timeline, is making the right call. This judgement — readiness over schedule — is one of the most important a Financial Controller makes in an implementation, and it is one that requires the confidence to resist the pressure to go live before the system is genuinely fit to.

Managing the Transition and the Business Continuity

The cutover from the old system to the new is the moment of maximum risk, and managing it carefully is essential to business continuity. The business must continue to operate throughout — customers invoiced, suppliers paid, the books kept — even as the underlying system changes, and a poorly-managed cutover can disrupt all of this. Planning the transition in detail, with a clear sequence, fallback options, and the resource in place to handle problems, is what allows the business to keep running through the change rather than grinding to a halt.

This is also where change management matters most. A new finance system means new processes and new ways of working for the people who use it, and the human side of the transition is as important as the technical side. Users who are properly trained and supported through the change adopt the new system effectively; users who are left to work it out for themselves struggle, make errors, and resist. The Financial Controller who invests in training and support — who recognises that the implementation is a change for people, not just a change of software — gets a smoother transition and faster realisation of the benefits. Neglecting the human side is a common and costly error, because the best-configured system fails if the people using it cannot or will not use it properly.

After Go-Live: Stabilisation and Realising the Benefits

Going live is not the end of the project but the beginning of a new phase. New systems almost always have a stabilisation period in which problems emerge and are resolved, processes are refined, and users become proficient. Managing this period — responding to the issues that arise, supporting the users, refining the configuration — is part of delivering a successful implementation, and a Financial Controller who plans for stabilisation rather than expecting the system to work perfectly from day one navigates it far better.

Beyond stabilisation lies the realisation of the benefits, which is the whole point of the implementation and the phase most often neglected. The faster closes, the better reporting, the automated processes, the richer data that justified the investment do not materialise automatically; they have to be pursued deliberately once the system is stable. The Financial Controller who drives the realisation of these benefits — who uses the new system’s capabilities to genuinely improve how the finance function works, rather than settling for replicating the old processes in new software — is the one who delivers the value the implementation promised. This is where a well-led implementation pays off, transforming the finance function for years to come, and it is the measure by which the project should ultimately be judged.

Governance, Resourcing and the Project Team

A finance system implementation is a major project, and like any major project it needs proper governance and resourcing rather than being squeezed in around everyone’s day job. The implementations that fail are frequently those that were under-resourced — where the people responsible were expected to deliver the project on top of their full-time roles, with predictable consequences for both the project and the day job. The Financial Controller who secures proper resource for the project, whether through backfilling roles, bringing in interim support, or dedicating team members to the implementation, gives it a far better chance of success.

Governance matters too. A clear project structure — with defined roles, a steering group that makes the significant decisions, clear accountability for the workstreams, and a mechanism for surfacing and resolving issues — keeps the project on track and ensures that problems are addressed rather than allowed to fester. The Financial Controller is often the business owner of the project even where external implementers do the technical work, and owning it properly means ensuring the governance is in place, the decisions are made by the right people, and the project is genuinely managed rather than left to drift. The combination of proper resourcing and clear governance addresses two of the most common causes of implementation failure, both of which are entirely within the business’s control.

Working With Implementers and Managing Scope

Most implementations involve external partners — the software vendor, an implementation consultancy, technical specialists — and managing these relationships is part of the Financial Controller’s role. The key is to be an informed, engaged client rather than a passive one: to understand enough about what is being done to challenge it where necessary, to hold the implementers to account for the quality of their work, and to retain ownership of the decisions that shape the outcome rather than abdicating them to the external party. The implementers bring the technical expertise, but the Financial Controller brings the knowledge of the business and the accountability for the result, and both are needed.

Scope management is a particular discipline. Implementations are prone to scope creep, where additional requirements accumulate during the project, extending the timeline and inflating the cost; and to the opposite problem, where the scope is cut to hit a date or budget in ways that compromise the outcome. The Financial Controller who manages scope deliberately — being clear about what the implementation must deliver, resisting unjustified additions, and refusing to cut the things that genuinely matter — keeps the project on track toward a successful outcome. This requires the judgement to distinguish the requirements that are essential from those that are merely desirable, and the firmness to hold that line against the pressures that push scope in both directions.

Building Controls and Reporting Into the Design

An implementation is the ideal moment to build a strong control environment and good reporting into the finance function, because both can be designed into the new system from the start rather than retrofitted later. The Financial Controller who thinks about controls during the configuration — the authorisation workflows, the segregation of duties, the validation rules that prevent errors at the point of entry — embeds control into the system itself, which is far more robust than controls layered on afterward. Designing the controls into the new system, rather than recreating the old manual controls, is one of the genuine opportunities a fresh implementation presents.

The same applies to reporting. A new system is a chance to design the reporting the business actually needs rather than inheriting the constraints of the old one, and the Financial Controller who specifies the reporting requirements during the implementation gets a system that delivers good management information from go-live. Neglecting this — focusing on getting the transactional processing working and leaving the reporting and controls as afterthoughts — is a common error that wastes much of the opportunity the implementation presents. The Financial Controller who treats the implementation as a chance to build a well-controlled, well-reported finance function, not just to move the transactions to new software, captures far more of the value the project can deliver.