Two-tier ERP runs a tier 2 system in the subsidiaries while a tier 1 product keeps the corporate ledger. The case for it is cost and speed in the units. A tier 2 subsidiary program runs $300,000 to $3M and 6 to 18 months, against $500,000 to $5M or more and, in programs we have advised, 36 months for a single-region tier 1 rollout (SysGenPro). The number that decides whether two-tier pays off is neither of those. It is the consolidation interface and the chart of accounts, which is where the cost and the governance both sit.
Two-tier ERP fits small, fast, and different units, not the core
Two-tier ERP means the parent keeps SAP S/4HANA or Oracle Fusion Cloud ERP at corporate and puts a lighter product (Dynamics 365 Business Central, Oracle NetSuite, or Acumatica) in a subsidiary. The subsidiary posts its results up to the group ledger for consolidation. The parent gets one set of books; the unit gets a system it can afford and run.
The pattern earns its place in three situations. The first is a small or newly acquired unit that would take years to absorb onto the corporate template. The second is a subsidiary in a different industry from the parent, where the corporate configuration fits badly. The third is a unit that needs to move faster or cheaper than a tier 1 rollout allows.
The size gap is the reason. A tier 2 program for a 200 to 1,000 user unit runs $300,000 to $3M at 6 to 18 months. Extending the corporate tier 1 system to the same unit sits in the single-region enterprise band of $500,000 to $5M or more (SysGenPro). On a small unit the tier 1 rollout can cost more than the unit's annual profit.
Two-tier is the wrong answer for the core itself and for any unit large enough to need the corporate system's depth. This article does not re-open the single-tier decision for a large company; the broader budget question sits in the cost pillar. The narrower point here is the one most buyers get wrong: the saving is real, and the interface eats a large share of it.
The subsidiary licence is the small number
The subsidiary licence is the figure every proposal leads with, and it is the smallest number in the decision. Business Central lists at $70 to $80 per user per month (Essentials versus Premium), read on microsoft.com and reported by ERP Research. NetSuite runs about $999 a month plus $99 per user, a partner estimate published by ERP Research rather than an Oracle list price. Acumatica's published implementation range starts as low as $30,000 (ERP Research).
The real cost and the real governance line is the link back to the corporate consolidation. That link is a set of interfaces: a trial-balance feed mapped to the corporate chart of accounts, intercompany balances, and foreign-exchange translation. ERP Research puts each integration at $10,000 to $50,000 to build. A two-tier link usually needs three of them, so $30,000 to $150,000 before anyone adds the group consolidation setup and the master-data sync.
A worked illustration shows the proportion. Consider a $3B manufacturer running S/4HANA at the core that acquires a $120M distributor in another country, with 60 finance and operations users. Put Business Central in the unit at $80 per user per month: 60 x $80 x 12 is $57,600 a year in licence. Implementation at the pillar's 1x to 3x multiple is $57,600 to $173,000, and the published floor for a Business Central program is about $50,000.
Now the interface. Three integrations at $10,000 to $50,000 each is $30,000 to $150,000 to build, and run cost carries at 15 to 25% of that every year after go-live. The interface can equal or exceed the subsidiary implementation. The licence, the number the board asked about, is the part that barely moves the total.
| Cost line | Illustrative figure | Source basis |
|---|---|---|
| Business Central licence, 60 users | About $58,000 a year | $80 per user per month |
| Subsidiary implementation | $58,000 to $173,000 | 1x to 3x first-year licence |
| Consolidation interface (three integrations) | $30,000 to $150,000 to build | $10,000 to $50,000 each |
| Interface run cost | 15 to 25% of build a year | Annual run cost ratio |
| Extend S/4HANA to the unit instead | $500,000 to $5M or more | Single-region tier 1 range |
Nothing in that illustration happened to any company. It is arithmetic on published figures, and it makes the point: the two-tier saving against a tier 1 rollout is large, and the interface is where a chunk of it goes.
Each vendor pairing earns its place under set conditions
The subsidiary product should be chosen on fit and on how clean the link to the core will be, not on licence price alone. Each of the three common pairings has a case where it is the right answer, and each has a condition that has to hold.
Business Central is the natural fit when the parent already runs Microsoft, and strongest when the core is Dynamics 365 Finance and Supply Chain rather than SAP or Oracle, because the data model and the identity system are shared. It suits small distribution, services, and light manufacturing units. The condition is that the corporate finance team accepts Business Central's lighter depth in the unit.
NetSuite is the right answer when the subsidiary itself has several sub-entities to consolidate, since multi-entity consolidation is built into the product. It fits software, services, and distribution units, and its published 3 to 6 month timeline is the fastest of the three (ERP Research). It pairs with an Oracle Fusion or SAP core equally well, because the link is an interface in either case. The condition is that the parent governs NetSuite's flexible chart of accounts tightly.
Acumatica is the right answer when the unit needs a vertical edition or custom code that a tier 1 template would make expensive, and when user count is the cost driver, because its consumption-based licensing does not charge per named user. The condition is that the unit has the in-house capacity to own more of the configuration.
| Subsidiary product | Best fit | Typical speed | Condition that must hold |
|---|---|---|---|
| Dynamics 365 Business Central | Microsoft-standard parent, small distribution or services unit | 3 to 9 months | Finance accepts lighter depth in the unit |
| Oracle NetSuite | Unit with its own sub-entities to consolidate | 3 to 6 months | Parent governs the chart of accounts centrally |
| Acumatica | Unit needing a vertical edition or custom code, high user count | 3 to 9 months | Unit can own more of the configuration |
The core product rarely decides the subsidiary choice, because the two systems meet at an interface, not inside one database. An SAP S/4HANA core and an Oracle NetSuite subsidiary work together as readily as a matched pair, as long as the consolidation mapping is built and owned centrally.
An ungoverned subsidiary chart of accounts erases the saving
The chart of accounts is where two-tier programs quietly fail. The tier 2 products are flexible by design, which lets a local controller open accounts and dimensions that do not map to the corporate ledger. Every unmapped account becomes a manual journal at consolidation, and the manual work grows with each close.
The rule we recommend is that the corporate chart of accounts, the intercompany rules, and the master data for customers and suppliers are governed centrally and locked in the subsidiary system. The unit configures what sits below the group accounts, not the group accounts themselves. This is a governance decision made before the subsidiary system is configured, not a cleanup project after.
The cost of getting it wrong shows up as a program rescue. Deliberate Directions, writing about NetSuite rescues, puts the cost at 30 to 50% of the original budget. On a $400,000 subsidiary program that is $120,000 to $200,000, more than the interface that should have carried the mapping in the first place.
A further charge is the one per legal entity. CRM Layers, an advisory blog whose figure we treat as weak, puts the cost added per additional legal entity at 10 to 20% of implementation. The direction is right even if the number is soft: each entity you bring onto the two-tier model adds mapping, intercompany, and close work, so a scattered estate of tiny units can cost more to consolidate than it saves in licences.
When two-tier fails: weak governance and underestimated interface cost
Two-tier ERP fails for three reasons, and all three are decided before the subsidiary system goes live. The first is weak central governance, where the group lets each unit run its own chart of accounts and reporting calendar, and the monthly close turns into a reconciliation exercise. The second is an uncontrolled subsidiary chart of accounts, the specific form the first failure usually takes.
The third is the one that distorts the business case: underestimating the interface and consolidation cost. A proposal that compares a $58,000 subsidiary licence against a $1M tier 1 rollout and declares a $940,000 saving has left out the $30,000 to $150,000 interface build, its run cost, and the central team that owns the mapping. The honest comparison nets those out first.
Two-tier also stops paying off when the subsidiaries grow. A unit that will pass the point where it needs the corporate system's depth within the five-year window is better brought onto the core from the start, because the second migration costs more than the tier 1 rollout would have. The test is forward-looking: where will this unit be in five years, not where is it today.
The default we recommend is to run two-tier when the units are small, fast-moving, or different from the core, and to keep the chart of accounts and the consolidation interface under central ownership from day one. Treat the interface as the main line item in the business case, not a footnote under the licence.