Part of the Outgrowing your finance systems series.
The most expensive finance system a growing group can buy is one implemented before it has fixed its process. The system does not resolve the underlying confusion - it encodes it, surrounds it with licences and change-control procedures, and makes it significantly harder to unpick later. If you are a CFO under board pressure to 'get a system in' ahead of a funding round or acquisition, the most valuable thing you can do in the next four weeks is separate the problems you actually have.
How do I tell whether I have a process problem or a system problem?
A process problem is one you could resolve - at least temporarily - with a clear decision, a written rule, and a spreadsheet. A system problem is one where the right decision and the right rule exist, but the infrastructure cannot execute them at the scale or speed you now need. The test is simple: if you gave your team a perfect tool tomorrow, would the confusion go away? If the honest answer is 'no, because we don't actually agree on how intercompany eliminations work' or 'no, because each entity controller uses a different chart of accounts', that is a process failure. The system would inherit every one of those disagreements and surface them as reconciling items, workflow exceptions, or corrupted hierarchies.
Run this diagnostic across the office of the CFO row by row. In planning and budgeting: is the problem that the tool cannot handle the driver model you want, or that no agreed driver model exists? In group month-end close: is the bottleneck the system's journal workflow, or the fact that three entities have different cut-off policies? In consolidation: is it that the software cannot eliminate intercompany balances, or that those balances are not being recorded consistently in the first place? In forecasting: is it a calculation limitation, or a governance gap about who owns the number? The answers tell you where to spend the next ninety days.
What happens when you automate an unresolved process?
Automating an unresolved process does not accelerate the process - it accelerates the production of wrong outputs. The system becomes a vehicle for propagating the error faster and at greater scale. More specifically, three things happen.
First, the process flaw becomes structural. A manual workaround is easy to change; a configured workflow, a hard-coded mapping table, or a reporting hierarchy baked into a system's metadata layer is not. Every subsequent entity acquisition, chart-of-accounts change, or reporting requirement then has to fight against the original bad design rather than simply adopting the corrected one.
Second, the symptoms become invisible. In a spreadsheet environment, a process failure tends to produce a visible, ugly reconciling item or a formula error that someone catches. Once the same failure is inside a system with green-light dashboards, the appearance of control replaces the reality of control. Auditors and acquirers - precisely the audiences a pre-funding or pre-acquisition finance function is performing for - are now looking at well-formatted nonsense.
Third, remediation cost compounds. Fixing a process before system selection costs meeting time and some consulting resource. Fixing it after go-live costs that, plus a system reconfiguration project, plus potential data migration or restatement work, plus the distraction of a team that is simultaneously trying to close the books on new infrastructure.
What genuinely cannot be fixed by process alone as the group grows?
Process discipline has real limits, and honest sequencing requires acknowledging them. Three categories of demand genuinely outgrow what a well-run manual or spreadsheet environment can sustain.
Entity count and intercompany volume. Below a certain entity count, a disciplined spreadsheet consolidation is defensible. As entity count rises - particularly through acquisition - the number of intercompany relationships grows non-linearly. The elimination logic becomes too complex to govern reliably in a manual environment, and the month-end close timeline lengthens in ways that cannot be recovered by process improvement alone. This is a real system limitation, not a process failure.
Multi-standard statutory reporting. A group operating across multiple jurisdictions, preparing accounts under different local GAAP standards alongside a group IFRS consolidation, faces a data management and translation problem that process discipline cannot fully address. The parallel ledger and adjustment layer logic required is a legitimate system function.
ESG data consolidation and CSRD-aligned reporting. Finance-owned ESG reporting - the consolidation-meets-CSRD problem - introduces new data sources, new entity-level collection requirements, and new assurance demands that sit awkwardly on top of financial consolidation spreadsheets. The volume and heterogeneity of non-financial data is a system-scale problem once reporting obligations become material.
The honest CFO position is: fix process first, then let the residual system limitations - the ones that survive a clean process - define the specification you take to market.
How do I sequence this so the system lands on foundations rather than creating them?
Sequencing is straightforward to describe and hard to execute under board pressure. The stages are these.
Stage one: stabilise the chart of accounts and entity hierarchy. Every system implementation that has failed to deliver has a version of the same root cause: the group's structural data was not agreed before configuration began. Agree the chart of accounts, the legal entity hierarchy, the intercompany matrix, and the currency treatment before a single vendor is selected. These decisions take weeks; they should not be made inside a system implementation under time pressure.
Stage two: document the process as it should work, not as it does work. Write the close timetable, the consolidation instructions, the journal approval policy, and the forecast submission rules as if the system already existed and was perfect. The gaps between that documented ideal and current practice are your process remediation list. Work through it. What survives that remediation is your genuine system requirement.
Stage three: define the minimum viable reporting pack for the funding round or acquisition. Boards and acquirers need a Finance Value Score that is credible and consistent - a clear picture of how finance runs today, and a costed view of where it is going. That is a better use of the next ninety days than a system go-live on unstable foundations.
Stage four: select and implement against a clean specification. Now the system lands on something real. Configuration decisions have answers because the underlying process decisions were made first. The implementation is shorter, the data migration is cleaner, and the post-go-live reconciliation items are system issues, not process issues dressed up as system issues.
The board wants confidence in the finance function. A rushed system implementation does not create that confidence - it creates the appearance of it, briefly, and then creates a very visible remediation project at exactly the wrong moment. Fix the process. Then buy the system.
Common questions
How do I know if my finance problems are process failures or system limitations?
The clearest test is to ask whether a perfect tool, implemented tomorrow, would resolve the problem. If the answer is no - because underlying rules, policies, or data definitions are not agreed - the problem is a process failure, not a system limitation. System limitations are those that survive a clean, well-governed process: typically high entity counts, multi-standard statutory reporting, and ESG data consolidation at scale.
Why does implementing a system on top of a broken process make things worse?
Automating an unresolved process encodes the flaw into the system's configuration - mapping tables, workflow rules, and reporting hierarchies - making it structurally harder to correct later. The failure also becomes less visible: well-formatted system outputs can obscure the same reconciling errors that a spreadsheet would have surfaced as an obvious formula problem. Remediation after go-live costs significantly more than remediation before selection.
What process work should a CFO complete before selecting a finance system?
At minimum: agree a single chart of accounts and legal entity hierarchy, document intercompany policies and elimination logic, write close timetables and forecast governance rules, and define the reporting pack the business actually needs. These decisions take weeks and should not be made inside a system implementation under time pressure - every one of them will be required as configuration input regardless.
What genuinely requires a system rather than better process discipline?
Three demands reliably exceed what a disciplined manual environment can sustain: a high and growing entity count with complex intercompany relationships; multi-jurisdiction statutory reporting requiring parallel ledger logic; and finance-owned ESG data consolidation under CSRD-aligned reporting obligations. These are legitimate system requirements once they reach material scale - but they should be confirmed as system needs, not assumed to be, before a procurement begins.
How should a CFO handle board pressure to 'get a system in' before a funding round?
The most effective response is to reframe what the board actually needs: confidence in the finance function's credibility and forward trajectory, not a system go-live date. A clean, documented process with a clear business case for system investment - showing the gap between current maturity and where the function needs to be, costed in pounds - is more persuasive to an acquirer or investor than a rushed implementation on unstable foundations.