Two-Tier ERP: Running S/4HANA Public Cloud in the Subsidiary While Headquarters Keeps Its ERP

TL;DR: A subsidiary does not have to wait for the group ERP. With two-tier ERP it runs S/4HANA Public Cloud as a complete local ERP while headquarters keeps ECC or S/4HANA private edition. It works if you settle four questions first: where the tier boundary sits, who owns which master data object, how intercompany actually posts, and who owns the interfaces at 2am.

A conversation we have roughly once a month. The Swiss subsidiary has outgrown what it is running: maybe an old ECC the group no longer invests in, maybe a local ERP the parent tolerates, occasionally a spreadsheet estate that would frighten an auditor. They want to move. And then someone in Stuttgart or Milan says the group is not touching its ERP before 2030.

At first sight this looks like a stalemate. It is not. It is the textbook case for two-tier ERP, and the textbook has been quietly working for years.

What two-tier ERP actually means

Tier one is headquarters. ECC, S/4HANA private edition, whatever the group has invested a decade in. It keeps the group ledger, the consolidation, usually the vendor master and the global material master.

Tier two is the subsidiary, running S/4HANA Public Cloud. It runs the local business end to end: local sales, local procurement, local stock, local statutory books.

The two are connected for a deliberately short list of processes. Intercompany buying and selling. Group reporting. The master data objects the group genuinely owns. That is close to all of it. SAP describes the deployment models (headquarters and subsidiary, central services, supply chain ecosystem) and the prepackaged integration content on its two-tier ERP topic page for S/4HANA Public Cloud.

The point people miss is what two-tier is not. It is not a satellite system feeding the mothership. The subsidiary has a complete, closing, auditable ERP of its own. It simply does not carry the group’s twenty years of modifications with it.

Why it fits the Swiss case in particular

Switzerland produces this constellation more than most markets, for boring structural reasons. A lot of Swiss entities are the profitable, awkward, non-euro subsidiary of a larger DACH or Italian group. They are big enough to have real ERP needs and small enough that the group roadmap does not prioritise them.

Add the local requirements that the group system usually handles badly anyway: QR-Rechnung, ISO 20022 payment files against a Swiss bank, VAT at Swiss rates, a payroll boundary that is nothing like the German one. A Swiss entity on a German ECC typically has a small pile of local workarounds around exactly these things, maintained by one person who is nearing retirement.

Two-tier turns those workarounds into standard scope in a system that ships a Swiss country version, including QR-bill processing. That is often the real motivation, and it is a good one.

The four decisions that decide the outcome

Everything else is implementation detail. These four are where projects are won or lost, and all four are business decisions wearing technical clothes.

1. Where the tier boundary sits

Not “which modules”, but which processes end at the boundary. Write it down per process, with a name against it.

The version that works: the subsidiary owns order to cash, procure to pay, stock, and its own statutory close. The group owns consolidation, group treasury, and the master data objects it genuinely governs.

The version that fails: the group keeps “just pricing” or “just the customer master” because someone is attached to it, and then every local sales order needs a round trip to a system in another country with a different maintenance window. We have seen versions of this where order entry in the subsidiary depended on a nightly job in the parent’s data centre, so a customer created on Tuesday afternoon could not be invoiced until Thursday. Nobody designed that. It accumulated.

2. Who owns each master data object

One owner per object, replicated read-only the other way. Write the table, agree the table, and then do not negotiate it again every quarter.

A boundary that works in most groups:

Object	Owner	Direction
Vendor master (group suppliers)	Tier 1	Down, read-only in tier 2
Finished goods material master	Tier 1	Down, local extension fields in tier 2
Local customers	Tier 2	Local only
Local pricing and conditions	Tier 2	Local only
Chart of accounts	Tier 1	Down, mapped
Cost centres, local	Tier 2	Up for reporting

The rule underneath the table: nothing is bidirectional. The moment an object is maintained in both tiers you have built a race condition into your month-end, and it will surface as a rounding difference nobody can explain three quarters later.

3. How intercompany actually posts

This is the one that gets waved through in workshops and then eats eight weeks in testing.

The group sells to the subsidiary, or the subsidiary sells onward to the group’s customers, and both sides need matching documents, matching transfer prices, matching tax treatment and matching timing. Public Cloud ships good standard intercompany content. It ships it with opinions about how the process should run, and those opinions will not match the group’s twenty-year-old bespoke process.

Settle in design, not in test: who issues the invoice, at what transfer price and who maintains it, which currency and which rate, how the elimination happens at group level, and what an intercompany return does. Write the reconciliation report before you write the interface. If you cannot describe how you would prove the two sides agree at month-end, you are not ready to build.

4. Who owns the interfaces at 2am

The organisational one, and the one that gets skipped because it is not fun.

The tier boundary runs directly along an org chart line. Group IT owns tier one. Local IT or a partner owns tier two. The interfaces sit exactly on the seam, which means at 2am on the last working day of the month, when the intercompany invoice batch has not arrived, it is nobody’s incident.

Name one owner for the integration layer, with monitoring, alerting and an escalation path that reaches a human on both sides. SAP Integration Suite gives you the tooling and the two-tier content. It does not give you an on-call rota. That you have to write yourself.

What it costs

I will not quote you a number, because any number without your scope is theatre. But the shape is consistent across the projects we have run.

Public Cloud licensing for a subsidiary is modest against a group ERP footprint, and the implementation is genuinely shorter than a tier-one project, because standard scope is the whole idea. Where two-tier costs more than a naive estimate is the integration layer and the intercompany process design. Budget those as a real workstream with a real owner, not as a line item at the end.

The other honest cost: you now run two ERPs. Two release cycles, two test cycles, two sets of master data governance. Public Cloud receives two major releases a year whether the group is ready or not, which is a feature, and also a commitment. If nobody in the organisation wants to own that rhythm, two-tier will be unhappy regardless of how well it is built.

When two-tier is the wrong answer

Three cases where we say so.

The group is already committed to S/4HANA within about eighteen months with the subsidiary in scope. Then two-tier is a detour: you build a boundary, run it briefly, and dismantle it.

The subsidiary is not really a separate business. If it shares customers, pricing, stock and people with the parent to the point that the “boundary” would cut through daily operations, you are not designing two tiers, you are designing a fault line.

Nobody local owns it. Two-tier needs a subsidiary that can carry its own ERP, including the half-yearly update. If the local team is two people who already have day jobs, be honest about that in the business case rather than discovering it in month nine.

Where CX fits, because this is usually the same conversation

Most subsidiaries that come to us for this are not only asking about ERP. They are asking because the sales team cannot see stock, or the service team cannot see the order. Two-tier is a good moment to settle that, since you are defining the boundary anyway.

Sales Cloud V2 connects to tier two, not to the group system. The subsidiary’s reps look at the subsidiary’s stock, prices and orders, which is what they actually sell against. The alternative, pointing the CRM at the group ERP across the boundary, reintroduces exactly the latency you built tier two to escape.

This is the seam we spend most of our time on, and it is also where we see two-tier projects quietly succeed or quietly disappoint. The ERP boundary and the CX boundary have to be the same boundary. When they are not, you get a sales team working from one version of the truth and a finance team closing on another. We set out why the integrated SAP stack of S/4HANA Public Cloud and Sales Cloud V2 pays off, and why it matters that one partner delivers both the ERP and the CRM side.

Where to start

Do not start with a system selection. Start with the process list and the master data table above, in a room with both the group and the local side present. Two days, honestly done, tells you whether two-tier is your answer and roughly what it will cost. It also surfaces the political questions early, which is the point.

If you want that structured, our S/4HANA readiness assessment is five days and fixed price, credited against the transformation if you commission it. And if the group question is still open, the transformation overview sets out the target architecture we work towards.

The thing worth saying plainly: waiting for the group is a decision too, and it is rarely the cheap one. Every year the subsidiary spends on a system nobody invests in is a year of workarounds that someone will eventually have to unpick.