top of page

Growth Has a Habit of Exposing What Your Business Was Getting Away With

Writer: John Bell
John Bell
Oct 5
8 min read

Growth is generally treated as one of those problems you're not supposed to complain about. More customers, more people, new locations, another company joining the group or a new investor coming on board are all signs that something is going well.

The awkward bit is that growth has a habit of exposing everything the business was getting away with when it was smaller.

A process that works perfectly well when there are 30 people in the company can become a complete pain when there are 300. The spreadsheet that one Financial Controller managed perfectly well suddenly has six contributors. The monthly management pack that took half a day now takes four days because information is being pulled from different systems, entities and departments.

Nothing necessarily "broke".

The business just got bigger.


The business can outgrow its operating model before anybody notices

Most businesses don't wake up one morning and discover their systems have suddenly stopped working.

It happens gradually.

Transaction volumes increase. Another person joins finance. A new product is launched. The business opens another site. Someone introduces a separate system because the existing one doesn't quite do what they need. Finance builds a spreadsheet to bridge the gap between the two.

Then another spreadsheet appears to reconcile the first spreadsheet.

You know how this goes.

For quite a while, good people compensate for poor processes and systems through sheer effort. They work a bit later at month-end, perform another reconciliation, manually move some information between systems and create another report because management can't get what it needs from the core platform.

I've spent enough time working in finance to know how good finance teams are at making things work.

Sometimes too good.

Because the workaround works, the underlying problem doesn't get fixed.

Eventually the Financial Controller has effectively become the integration layer between five different systems and nobody has actually written that responsibility into their job description.

That's usually a sign the operating model hasn't kept pace with the business.


Acquisition makes everything more interesting

Organic growth normally introduces complexity gradually. Acquisition can introduce it at 9am on completion day.

The deal gets done, everyone has a glass of something fizzy and then somebody in finance has to work out how these businesses are actually going to operate as a group.

Company A uses one finance system. Company B uses another. The acquired business has a completely different chart of accounts. Supplier records are structured differently. Customer information is held differently. One business closes in five working days and another considers the 15th to be pretty good going.

Then you get into revenue recognition, approval processes, intercompany balances, reporting structures, expenses, purchasing and the slightly alarming spreadsheet used to create the group consolidation.

Acquisition integration isn't simply about connecting two bits of software.

The real question is how you take two or more businesses that have evolved independently and create enough consistency for them to operate, control and report as a group without destroying everything that made the acquired business successful in the first place.

That's a business challenge before it is a technology challenge.

Technology can make it considerably easier, but only after somebody decides what the future operating model should actually look like.


PE investment changes the expectation

Private equity investment can create a different type of pressure.

The business may already have been growing successfully before the investment. The difference afterwards is often the speed and level of expectation.

Management information needs to be better. Forecasting becomes more important. Cash and working capital receive greater attention. Board reporting evolves. The growth plan becomes more ambitious and there may be further acquisitions, new entities or international expansion on the horizon.

That's not a criticism of PE. Quite the opposite. Investment is normally there because everybody believes the business can become substantially bigger or better.

But a finance function designed for the business as it looked before investment may not be equipped for the business everyone is now planning to create.

If the strategy says the group is going to double in size over the next three years, completing every month-end through a collection of exports, lookups and manual reconciliations probably isn't the long-term answer.

You can keep hiring people to compensate for that complexity.

For a while.


The warning signs are normally fairly obvious

You don't need a six-month transformation assessment to spot many of the warning signs.

Month-end is getting longer despite the finance team getting bigger. Reporting requires information to be manually extracted from several systems. Management meetings occasionally descend into discussions about whose number is correct rather than what the number actually means.

New entities take months to incorporate into group reporting. Information is being rekeyed between systems. Senior finance people spend too much of their time preparing information rather than analysing it.

And, of course, spreadsheets start appearing everywhere.

I don't have a problem with Excel. Excel is brilliant. I've been an accountant long enough to know that trying to take Excel away from finance entirely would probably result in some form of organised uprising.

The problem comes when spreadsheets stop being a useful analysis tool and start becoming the glue holding the operating model together.

If Excel is acting as your consolidation system, integration platform, workflow engine, reporting database and repository of knowledge known only to Dave, you probably have a different problem.


Don't just digitise the problem

This is where technology transformation can either genuinely improve the business or simply make the existing mess more expensive.

Replacing an old system with a modern one while recreating every existing process isn't necessarily transformation.

Sometimes it's just relocation.

One of the first questions I think businesses should ask during any technology project is why a process works the way it does today.

Was it deliberately designed that way because it gives the business an advantage or satisfies an important control requirement?

Or does it work that way because the finance system bought 12 years ago couldn't do something, somebody created a workaround in 2018 and everyone has been faithfully following it ever since?

Those are very different things.

This is why I am a big believer in challenging the status quo during ERP and technology projects. That doesn't mean arriving with a consultant's badge and telling people who have worked in the business for 20 years that they're doing everything wrong.

It means being curious enough to ask why.

Which parts of the current process still add value? Where are people moving information manually? Where are approvals creating control and where are they simply creating delay? Which spreadsheets exist because somebody genuinely needs flexible analysis and which are compensating for missing functionality elsewhere?

Most importantly, what happens to all of this if the business doubles again?


Technology should be designed for where the business is going

A sensible technology strategy should reflect the future business rather than simply solving today's irritation.

If acquisition is part of the strategy, how easily can another legal entity be incorporated? Can the business standardise enough of its chart of accounts, data and reporting structure that the next acquisition doesn't create another six-month consolidation project?

If international expansion is planned, can the current landscape handle additional currencies, tax requirements and entities?

If transaction volumes double, do they require twice as many people to process them?

If management wants faster information, is that information already available in the underlying systems or does finance need five working days to manufacture it?

Those questions are much more useful than starting with, "Which software should we buy?"

The software comes later.

First understand what is stopping the business scaling efficiently.


Where ERP fits

For businesses reaching this point, a modern ERP can form an important part of the answer.

Bringing finance and relevant operational processes into a more joined-up environment can reduce rekeying, improve controls, standardise processes, automate parts of the close and make multi-entity reporting substantially easier.

Platforms such as Oracle NetSuite are designed for exactly this type of complexity, particularly where businesses are dealing with multiple entities, acquisitions, international growth and disconnected finance and operational processes.

But NetSuite isn't automatically the answer because a company is growing.

Neither is any other ERP.

I've written previously that complexity matters more than turnover when deciding whether a business genuinely needs ERP, and I still think that's one of the most useful ways of looking at it.

A £20m business with ten entities, multiple countries, complicated billing and several disconnected systems may have a much stronger need for ERP than a £100m single-entity organisation with a very straightforward operating model.

The technology has to be proportionate to the problem.

Otherwise you've just swapped operational complexity for software complexity, which isn't much of a win.


The people still have to change

There is another uncomfortable part of technology transformation that tends to get less attention during the software demonstrations.

The business has to change as well.

You can implement a platform capable of automating a process, but if users continue maintaining the old spreadsheet "just in case", you've now got two processes instead of one.

You can create group-wide controls, but if every acquired company insists its existing approach is special and absolutely cannot change, standardisation becomes difficult very quickly.

You can build brilliant management reporting, but if the underlying data isn't owned properly, the reports simply allow you to see bad data faster.

Technology can enable change. It cannot force adoption.

That is why process design, data, ownership, communication, training and change management matter just as much as the system itself.

A successful transformation shouldn't leave the business with a shiny new platform and exactly the same habits.




Growth should make the business stronger, not just busier

One of the interesting things about growth is that the problems it creates are normally evidence of success.

The company has more customers. More transactions. More people. More entities. More opportunity.

The challenge is recognising when the systems and processes that helped the business get here aren't the ones that will help it get where it wants to go next.

I've seen finance teams compensate for that gap for years through effort, spreadsheets and an impressive ability to remember processes that apparently exist nowhere else on earth.

Eventually, though, the business has to make a choice.

Keep adding people and workarounds around the existing operating model, or use the next stage of growth as an opportunity to simplify, standardise and build something capable of scaling with it.

Technology can play a big part in that.

But the starting point shouldn't be the technology.

It should be understanding what the business has become, what it wants to become next, and what needs to change to get there without finance becoming progressively better at working around its own systems.

Growth is a good problem to have.

It just doesn't mean you have to keep all the problems that came with it.


5 actions you can do right now.


  1. Month-end and management reporting Look at how long it takes to close the month, how much manual intervention is involved and how many spreadsheets are needed before management gets a reliable view of performance. If finance spends more time assembling the numbers than understanding them, that is usually a warning sign.

  2. Manual handoffs and duplicate entry Identify where people are moving information between systems, rekeying data or relying on exports and uploads. These are often the first areas where growth creates unnecessary admin, errors and dependence on specific individuals.

  3. Entity, acquisition and consolidation readiness Ask how easy it would be to add another company, location or country tomorrow. If a new acquisition would mean another chart of accounts, another reporting process and another consolidation spreadsheet, the operating model probably needs attention before the next deal lands.

  4. Processes that exist because “we’ve always done it that way” Review approvals, purchasing, billing, expenses, reporting and other core processes. Work out which genuinely add value and which were created years ago to work around a limitation in an old system. Growth is a good opportunity to challenge those processes rather than simply scale them up.

  5. Whether the current systems can support the next stage of growth Don’t just ask whether the systems work today. Ask whether they will still work if transaction volumes double, headcount increases significantly, another entity is added or the business expands internationally. The important question is not “Is the system broken?” but “Will it still work for the business we are becoming?”

 
 
bottom of page