Case study
An acquisitive professional services group, buy-and-build, adding entities faster than its finance system could absorb them. The system had been the right choice at five entities. It was well past that.
Board packs were late, every month, and the board had run out of patience. The cause was not the finance team’s diligence — it was that consolidating a system never designed for that many entities meant a manual, spreadsheet-heavy exercise every close, with each acquisition arriving with its own chart of accounts, its own quirks and a different ownership structure.
And when the numbers did land, they gave a group view but could not show where the group was winning, where it was losing, or whether the businesses that had been bought were performing as the papers said they would. Two problems, and only one of them was reporting.
The brief was six months to fix the board reporting and replace the ERP underneath it. Not one or the other, and not sequentially.
The work that mattered was the work the vendor does not do. An implementation team configures the system, runs the workshops and turns up to the steering meetings; extracting data from a dozen legacy entities, cleaning it, mapping it and migrating it sits entirely with the business. Charts of accounts had to be aligned before anything could be mapped. Open invoices are a moving target, so they needed revisiting as the go-live date moved. IT support was needed, and the bank’s, before the systems would talk to each other.
The second decision was pace. An ERP switch is a moving target: the longer it runs, the more the business changes underneath it — another acquisition completes, another entity needs folding in, another reporting requirement shifts — until the data requirements scoped at the start are not the ones needed at the end. Speed is not a preference on these projects. It is what stops the goalposts moving.
The benefit case was never complicated. A modern ERP that plugs into a data warehouse consolidates automatically instead of by hand, and a good chunk of routine reporting runs itself rather than consuming an analyst’s week every month. The finance team stops being data wranglers and starts being analysts, and that changes both what the board pack contains and how quickly it arrives.
The honest part: the business and the team were not ready when the work started. Month-end does not pause while the systems underneath it are redesigned, and the expectation that the existing team absorbs a transformation of this size on top of the day job is the single most common reason these projects stall. That is a finding, not a failure — and it is the reason this work belongs outside BAU, with its own objectives, owner and timetable, known to everyone before it begins.
What this would cost as a Fraci brief — a worked example
3 days a week for the first 8 weeks, then 2 days a week for 16 weeks — 56 days
£900–£1,100 a day
£50,400 – £61,600
Against a permanent hire you would still be paying after the project ended, and a team you would be taking off the close to deliver it. This is an example, not a quote. Rates vary by band, sector and urgency, and every engagement is scoped and priced before it starts.
Tell us the problem, the days and the timeframe. We will come back with people who have done it before.
This is exactly what we read a CV for. Free to join, and always free to the Fraci.