A manufacturer with eleven hundred people at head office buys an ERP that suits eleven hundred people. Then it acquires a twenty-person distributor in another country and tries to put them on the same system.
Eighteen months later the distributor is running the ERP badly and half their real work happens in spreadsheets they do not mention on calls.
The mismatch that causes it
Enterprise ERP encodes assumptions about scale. Separation of duties across several roles, formal approval chains, dedicated finance staff, someone whose job is master data. Those assumptions are correct at head office and absurd at a subsidiary where one person does purchasing, invoicing, and reconciliation.
Forced onto that system, the small entity has two options. Follow the process, which means one person clicking through approvals designed for four people and everything taking three times as long. Or route around it, which is what actually happens.
The cost is not only the licence. It is implementation for an entity that will never use most of it, training on workflows that do not match how they work, and a permanent tax on every transaction.
What two-tier actually means
Headquarters keeps its enterprise system — Tier 1 — for consolidated financials, group reporting, compliance, and the complexity that genuinely exists at group level.
Subsidiaries run something lighter — Tier 2 — sized to how they actually operate. Often cloud, often a different vendor entirely, chosen for fit rather than consistency.
The two are connected by a defined integration: subsidiary results roll up to the group system on a schedule, in an agreed format.
The insight is that consistency of system was never the goal. Consistency of reported data was, and those are separable.
Fig. — Standardise the data contract, not the software.
Where it fits
Acquisitions. A newly acquired company has a working system and people who know it. Migrating them onto the group ERP is a year of disruption during the period when you most want them focused on the business. Connecting their system to yours is weeks.
Geographic expansion. Local statutory requirements, tax rules, and languages are often better served by a local product than by configuring the global system for a market with four employees in it.
Divisions with different operating models. A manufacturing group with a services arm is running two different businesses. Forcing one process model on both makes at least one of them worse.
Speed. A new entity can be operational on a cloud system in weeks. Waiting for a group ERP rollout can take quarters, during which the entity improvises — and improvisation becomes permanent.
What it costs you
This is a trade, not a free win, and the costs are real.
Integration is ongoing. The connection between tiers needs building and maintaining, and it breaks when either side upgrades. Someone owns that, permanently.
Reconciliation returns, in a smaller form. Two systems means two sets of records that must agree. Better than eleven spreadsheets, worse than one system.
Chart of accounts discipline becomes critical. If subsidiaries define accounts freely, consolidation turns into a mapping exercise that nobody can audit. The group has to mandate a common structure even where it does not mandate a common system — this is the single most important governance decision in the whole approach.
Group-wide visibility lags. Real-time consolidated reporting is harder when data arrives on a cadence. Most groups accept daily or weekly, which is usually fine and needs stating explicitly.
More vendors. More contracts, more relationships, more upgrade calendars, and more renewal negotiations happening on different dates. Small individually, tedious in aggregate, and it lands on whoever manages supplier relationships rather than on IT.
Skills fragmentation. Nobody in the group knows every system, so support for a subsidiary's issue cannot come from head office. Either the entity is self-sufficient or you are paying the vendor for support, and the second option needs budgeting rather than discovering.
The political part
The technical case for two-tier is usually easy. The organisational one is where it stalls, and it is worth naming the objections directly.
Group IT often resists, and not unreasonably — they are accountable for systems they do not control, supporting a vendor they did not choose. That objection dissolves if the governance is real: a defined data contract, an approved shortlist, and clear ownership of each integration. It hardens if subsidiaries are simply left to do as they like.
Finance leadership worries about audit. Multiple systems sounds like weaker control, and it can be. The answer is that control lives in the data standards and the consolidation process, not in software uniformity — and a well-governed two-tier setup with mandated accounts is more auditable than one system that half the entities work around.
Subsidiary leadership usually wants this and rarely says so plainly, because arguing against head office standardisation reads as resistance. Ask them directly what percentage of their work happens outside the group system; the number is the argument.
The framing that lands: this is not about giving entities autonomy. It is about not paying to force complexity onto operations that do not have it.
Making it work rather than fail
Define the data contract before choosing any software. Which figures roll up, in what structure, on what schedule, in what currency, with what cut-off. Write it down. Every subsidiary system is then evaluated on whether it can produce that, which turns a subjective vendor choice into a requirement.
Mandate the chart of accounts and the master data standards. Customer and supplier identifiers, product codes, cost centre structure. Subsidiaries can be free about how they work internally; they cannot be free about how they label things that get consolidated.
Approve a shortlist rather than allowing free choice. Two or three vetted Tier 2 options, pre-integrated, that a new entity can adopt without a fresh evaluation. Complete freedom produces eleven vendors and eleven integrations.
Agree the close calendar across tiers. Subsidiaries need to know when their numbers are due, and group needs to know what happens when one misses. Without that, consolidation waits on the slowest entity every month and nobody can say whose fault it is.
Automate the rollup. Manual consolidation between tiers reintroduces exactly the reconciliation work you were trying to remove, and it is the most common way this approach quietly degrades.
And revisit the split as entities grow. A subsidiary that triples in size may genuinely outgrow Tier 2, and the decision should be reviewed on a schedule rather than defended out of habit.
Is it right for you
The question is not company size. It is variance.
If every entity operates similarly at similar scale, one system is simpler and simpler is worth a lot. If you have a large head office and small distributed entities, or you acquire regularly, or you operate across jurisdictions with genuinely different requirements, forcing uniformity costs more than it saves.
There is a timing dimension too. Companies that adopt two-tier deliberately, before the first painful rollout, get to design the data contract calmly. Companies that adopt it after forcing a subsidiary onto the group system and watching it fail arrive at the same place having spent a year and a good deal of goodwill. The approach is the same; the second route is simply more expensive and leaves the subsidiary distrustful of the next thing head office proposes.
A useful test: ask a subsidiary finance lead what percentage of their work happens outside the official system. If the answer is high, you are already running two tiers. The only question is whether the second one is a supported system or a folder of spreadsheets nobody at group level can see.
