Stack or Switch: What Happens When You Outgrow Xero (And What Doesn't Actually Require an ERP)
If you run finance for a multi-entity business on Xero, you've probably had the thought.
Usually it arrives at the worst possible moment, halfway through a messy month-end or after a board member asks a consolidation question you can't answer in real time: maybe we've outgrown Xero.
Here's what's interesting about that thought. When you actually sit down and ask finance leaders to explain why, the answer is rarely a definitive reason. It's more often a feeling, a sense that surely a business this size, with this many entities, can't still be running on the same platform a five-person startup uses. Xero even acknowledged this at their most recent roadshow, unveiling a new concept aimed squarely at businesses having this exact thought, built on the idea that most of them don't actually need to leave.
That's the gap this post is trying to close. Not "Xero is always enough" and not "you definitely need an ERP." A framework for telling the difference, because the two paths cost wildly different amounts of money, time, and organisational pain, and a lot of businesses take the expensive one without checking whether the cheap one would have worked.
The rough ceiling, and why it isn't a hard wall
There's a reasonably well-established rule of thumb among accountants who work with growing multi-entity groups. Product-based businesses tend to run comfortably on Xero up to somewhere around £5 to £10 million turnover. Service-based businesses, with simpler inventory and cost-of-sales structures, can often run to £15 to £20 million before real friction sets in.
Past that point, most businesses do eventually need something more than Xero on its own. But "something more than Xero on its own" and "a full ERP migration" are not the same thing, and this is where a lot of finance teams jump straight to the expensive conclusion.
A migration to a full enterprise ERP platform like Sage Intacct or NetSuite is a genuinely big undertaking. It's not just cost, though the subscription and implementation fees are substantial. It's the loss of the thing that made Xero good in the first place: the app ecosystem. Xero's real strength for a growing business isn't the core ledger, it's how easily specialist tools plug into it. Booking platforms, AP automation, debt chasing, month-end automation, all connecting at the click of a button.
Move to a monolithic ERP and you generally trade that flexibility for a handful of built-in features you may only need for one or two specific problems, like intercompany consolidation or heavier reporting, while everything else about how your team works has to be relearned from scratch, on a system your team has no existing muscle memory for.
What actually forces the move, versus what feels like it should
In practice, the businesses that do need to leave Xero are being pushed by a small number of specific, structural problems, not a general sense of scale.
True intercompany complexity. This means dozens of entities with genuine cross-charging, multi-level consolidation, and elimination requirements that go well beyond what a bolt-on tool can handle cleanly. There's a real difference between "we recharge costs between three subsidiaries" and "we need automated eliminations across forty entities with different functional currencies." The first is a solved problem with the right specialist tool. The second starts to genuinely strain what any add-on layer can do.
Statutory reporting complexity that a stack of specialist apps genuinely can't produce, regardless of how well configured they are. This is rarer than finance teams assume. Most statutory and management reporting requirements, even fairly sophisticated ones, are achievable with a good reporting or dashboard tool sitting on top of Xero. The businesses that hit a genuine wall here tend to have unusual regulatory or industry-specific reporting obligations, not standard group consolidation.
A finance team that has simply run out of tools to add. Every layer of the stack is already covered, well-configured, and working, and there's still a structural gap that only a single unified system can close. This is the rarest category of all, and it's usually the last one a team reaches, not the first excuse they reach for.
Notice what's missing from that list. Accruals and prepayments aren't on it. Deferred revenue recognition isn't on it. Missing-bill tracking isn't on it. These are the things finance teams most often cite as "why we're thinking about moving," and they're almost always solvable with the right point solution, not a platform migration. If your reason for considering an ERP is "our month-end adjustments are a mess," that's a stack problem, not a switch problem.
Building the stack instead of switching
The businesses that stay on Xero successfully at scale tend to do one thing well: they treat Xero as the ledger, the engine, and build a deliberate set of specialist tools around it rather than trying to force one platform to do everything.
A reasonably complete modern Xero stack for a multi-entity business tends to cover four layers:
Capture and AP processing. Tools like Dext, Apron or Hubdoc read invoices, extract data, and increasingly use their own AI to make coding decisions, cutting the manual data entry that eats up a finance team's early-month hours. The strongest tools in this category can also read line-level detail well enough to feed cleanly into the next layer down.
Month-end automation. This is where accruals, prepayments, deferred revenue, and missing-bill accruals get handled. It's also the layer most commonly, and wrongly, assumed to require an ERP. Spread is one option built specifically for this, designed to run continuously through the month rather than in one big batch at month-end, so the close itself becomes a final check rather than a two-day scramble. Whichever tool you choose, this layer alone resolves most of the "our numbers are always late and wrong" problems that get blamed on Xero itself.
Intercompany and consolidation. For businesses with real cross-entity complexity, a dedicated intercompany tool can close the gap that used to be the strongest argument for an ERP. Look for one that handles automated cross-charging, balance reconciliation between entities, and group-level consolidation, since these are the specific features that used to only exist inside a full platform.
Reporting and dashboards. Tools like Syft or Fathom sit on top of the whole stack, giving you the board-level view and group consolidation reporting without needing it baked into the core ledger.
Each of these is a deliberate choice, solving one specific problem well, rather than one platform trying to be everything at once and doing most of it adequately.
What a stack actually looks like in practice
Take a hypothetical hospitality group, a dozen boutique properties, roughly £12 to £14 million combined turnover, currently running on an older desktop accounting package with most of the real work happening in spreadsheets outside it.
The honest starting instinct for a business like this is often "we need proper software," which quietly becomes "we probably need an ERP" somewhere in the planning conversation, mostly because nobody has mapped out what a modern stack on Xero would actually look like for their specific pain points.
In practice, the mapping tends to look like this. Booking and EPOS data flows into Xero directly through existing integrations, so sales invoices need no manual entry at all. An AP tool like Dext or Apron handles supplier bills and receipts, reading dates and descriptions well enough that most invoices need no human touch before posting.
A month-end automation layer picks up deferred revenue on advance bookings, prepayments on annual insurance and subscriptions, and accruals for bills that haven't landed yet, running continuously through the month rather than in one big batch.
Because the group has genuine intercompany recharges (shared marketing costs, a central finance function billing out to each property), a dedicated intercompany tool handles the cross-charging and reconciliation that used to be the strongest argument for moving to something bigger. A reporting layer like Syft or Fathom on top gives the board a consolidated monthly view across all twelve entities.
None of that requires leaving Xero. It requires four deliberately chosen tools, each solving one part of the problem, connected to a ledger the team already knows how to use. The total monthly cost across all four layers is very likely still a fraction of a single ERP implementation fee, before any ongoing licensing is even factored in.
The real cost comparison
This is usually where the decision actually gets made, once the two paths are priced honestly side by side.
Stack approach | Full ERP migration | |
Typical setup cost | Little to none, most tools are self-serve or a short guided setup | Often five to six figures in implementation fees alone |
Typical ongoing cost | Priced per organisation, usually tens of pounds per tool per month | Substantial licensing uplift versus Xero, often per user |
Time to value | Days to weeks per tool | Months, sometimes over a year for a full multi-entity rollout |
Team retraining | Minimal, most tools sit alongside familiar Xero workflows | Significant, an entirely new system to learn |
Flexibility | Swap or drop individual tools as needs change | Locked into one vendor's roadmap and pricing |
Best suited to | Businesses with specific, nameable pain points | Businesses with genuine cross-cutting complexity a stack can't solve |
A quick framework for deciding
Before assuming you need to switch, work through these in order.
Name the specific problem. Not "we've outgrown Xero," but the actual operational pain. Late close? Inconsistent accruals? Can't consolidate intercompany balances? Each of these has a stack-layer answer before it has an ERP answer.
Check whether a specialist tool already solves it. For close speed and manual adjustment work, that's month-end automation. For consolidation, that's an intercompany tool. Very few named problems survive this step still requiring a full platform switch.
Total the real cost of both paths, using the comparison above as a starting point rather than a guess. Stack tools are typically priced per organisation per month, in the tens of pounds. ERP migrations involve licensing, implementation, data migration, and retraining, usually running into five or six figures before the business has processed a single transaction on the new system.
Only escalate to ERP once you've named a problem that genuinely has no stack-layer answer. If you get there, it's usually intercompany complexity at real scale, or a reporting requirement no combination of apps can produce.
Frequently asked questions
What turnover means a business has outgrown Xero?
There's no fixed number. Product-based businesses tend to hit friction somewhere between £5 and £10 million turnover, service-based businesses more often between £15 and £20 million, but turnover alone rarely tells the full story. Entity count, intercompany complexity, and reporting requirements matter more than revenue on its own.
Is Xero building its own answer to this?
Xero has publicly acknowledged that multi-entity businesses sometimes outgrow the platform, and has talked about a new stack-focused concept aimed at keeping growing businesses on Xero rather than losing them to an ERP migration. As of publication this is a concept Xero has discussed rather than a fully shipped product, so it's worth watching rather than planning around just yet.
Can Xero handle proper intercompany accounting?
Not natively at real scale, which is exactly why a dedicated intercompany tool exists as one of the four stack layers. For businesses with a handful of entities and straightforward cross-charging, this is usually a solved problem. For businesses with dozens of entities and complex elimination requirements, this is the area most likely to be the genuine reason for an eventual ERP move.
How long does it take to build a stack like this, compared to an ERP migration?
Most individual stack tools can be connected and configured within days, sometimes a single afternoon for the simpler layers. A full ERP migration for a multi-entity business more commonly takes several months from planning to live, and considerably longer for larger, more complex groups.
What's the biggest mistake growing businesses make in this decision?
Treating "we've grown a lot" as the diagnosis, instead of naming the specific operational problem first. Most businesses that migrate unnecessarily could have solved their actual pain point, whatever it was, with one well-chosen tool at a fraction of the cost and disruption.
The bottom line
Xero isn't a platform you're guaranteed to outgrow at a fixed revenue number. It's a platform you can outgrow in specific, nameable ways, and most of those ways have a specialist tool built to answer them directly. The businesses that end up migrating unnecessarily are usually the ones that treated "we've grown a lot" as the diagnosis, instead of asking which specific piece of their finance operation actually stopped working.
Before you start pricing up an ERP migration, it's worth spending an afternoon mapping your actual pain points against the stack layers above. More often than not, the fix costs a few hundred pounds a month, not a six-figure implementation project.
If month-end close is the piece of your stack that's still broken, that's exactly the layer Spread is built for. Worth a look before you assume the answer is a bigger platform.
Comments