How to Set Up Two-Tier ERP Integration: Subsidiary on Cloud ERP, HQ on S/4HANA

Subsidiary on SAP Cloud ERP (Public Edition), headquarters on SAP S/4HANA

Two-tier ERP sounds simple on a slide: HQ keeps its big S/4HANA, subsidiaries run a lighter Cloud ERP, and an integration layer keeps them in sync. In practice, "keeping them in sync" is where all the work is.

This guide walks through a complete, working example — an intercompany purchase-to-pay / order-to-cash flow — and the steps to build it with SAP BTP Integration Suite and SAP Event Mesh, using only SAP standard APIs.

1. What is two-tier ERP, and when does it make sense?

Typical triggers: acquisitions or carve-outs that need an ERP fast, joint ventures that may be sold later, regional expansion, small subsidiaries running scattered local systems, and regulatory / data-residency requirements.

The typical architecture:

• Tier 1 — HQ: SAP S/4HANA (private cloud or on-premise): consolidation, global chart of accounts, master data authority.
• Integration layer — SAP BTP: API-based and event-driven integration.
• Tier 2 — Subsidiary: SAP S/4HANA Cloud Public Edition: standard processes, local compliance, fast onboarding.

2. The example scenario: subsidiary buys from HQ

The subsidiary purchases goods from headquarters. Six documents, three automatic hand-overs:

SUBSIDIARY (Cloud ERP)              BTP                 HQ (S/4HANA)
1 Purchase Order   ──────────────►  map  ──────────►  2 Sales Order
4 Goods Receipt    ◄──────────────  map  ◄──────────  3 Delivery + Goods Issue
6 Supplier Invoice ◄──────────────  map  ◄──────────  5 Billing Document

Partial deliveries work naturally: if HQ ships 70 of 100 pieces, the subsidiary receives a GR for 70, and the invoice follows the billed quantity.

3. Standard APIs used

All available on the SAP Business Accelerator Hub (api.sap.com) with their schemas:

On the Public Edition side, inbound APIs are opened through communication arrangements. The Business Accelerator Hub page of each API tells you which communication scenario it belongs to.

4. Step-by-step setup

Step 1 — Agree the business design first

Integration can only automate a process that is already designed. Before any iFlow:

• Intercompany relationship: HQ is a supplier in the subsidiary; the subsidiary is a customer in HQ.
• Document types: a dedicated PO type in the subsidiary and order type in HQ make monitoring easier.
• Pricing: whose price is the truth — the PO price or HQ's pricing? Decide, then map accordingly.
• Field mapping table: customer ↔ supplier numbers, material numbers, plants, storage locations, units of measure, sales area. Own it as a business document, not only inside the code.

Step 2 — Prepare BTP

• A BTP subaccount with Integration Suite (Cloud Integration capability) and Event Mesh.
• Credentials and certificates for both systems (OAuth or basic authentication; trust certificates).
• If HQ is on-premise, a Cloud Connector for secure connectivity.

Step 3 — Prepare the subsidiary (Cloud ERP)

• Communication user, communication system (representing BTP) and communication arrangements for the inbound APIs: goods receipt (material document) and supplier invoice.
• Output management for the PO: configure the purchase order output so that, for the HQ supplier, it is sent electronically to BTP instead of printed or e-mailed.

Step 4 — Prepare HQ (S/4HANA)

• Expose the APIs you need (sales order create; delivery and billing read).
• Event enablement: publish business events from S/4HANA to Event Mesh when the outbound delivery's goods issue is posted and when a billing document is created.
• Alternative: instead of events, an output type on the delivery (e.g. an advance shipping notification) can push a message through a SOAP proxy. Events are cleaner when you only need a trigger and will read the details via API anyway.

Step 5 — Build the integration flows (iFlows)

Four artifacts cover the whole scenario:

a. PO → SO Receive the PO payload → Message Mapping (PO schema → Sales Order schema, both imported from the API Hub) → call the Sales Order API.

• JSON over HTTP needs a CSRF token fetched first; the OData adapter handles this for you. Both work — it's a design choice.

b. Event Router One iFlow subscribes to the Event Mesh queue (AMQP adapter), reads the event type and status, and routes:

• delivery event with goods issue completed → GR flow;
• billing event → supplier invoice flow;
• anything else → ignore. Keeping the routing logic in one place means the business flows don't each need to understand events.

c. Goods Issue → Goods Receipt The event is only a trigger — it doesn't carry everything you need. So:

1. Read the delivery via the Delivery API.
2. Split the items; for each item read the HQ sales order to find the customer reference = the subsidiary's PO number.
3. Gather the items back, map to the material document structure, post the GR in the subsidiary against the original PO.

d. Billing → Supplier Invoice Same pattern: read the billing document, find the PO reference, map, and create the supplier invoice referencing the PO (so three-way matching works).

Flows (c) and (d) are called from the router via ProcessDirect (fast internal calls between iFlows in the same tenant).

Step 6 — Test end to end

• Full delivery, partial delivery, multiple items, and a cancellation.
• Check the accounting: the GR posts inventory against the GR/IR clearing account; the supplier invoice clears it.
• Check traceability: the HQ sales order's customer reference = subsidiary PO number; the PO history shows GR and invoice.

Step 7 — Monitor and handle errors

• Use Monitor → Integrations and APIs in Integration Suite to see the source payload, the posted payload and the result for every message.
• Decide who watches failures and how messages are reprocessed — this is an operations process, not just a technical setting.

5. Lessons from building it

• Don't hard-code organizational values. Plant, storage location, movement type and similar values are tempting to hard-code in a demo. In a real project, use value mapping or an external parameter table, so a new plant doesn't require changing the iFlow.
• Unit-of-measure mapping bites. A classic error: a unit code ("PC") lands in a numeric field. Map quantities and units separately and test with every unit you use.
• Business errors look like technical errors. A GR fails because the PO is already fully received, or the period is closed. Your monitoring must show the business message, not just "HTTP 400".
• Prevent duplicates. If an event is delivered twice, you must not post two GRs. Check whether the document already exists before posting.
• Integration is a process, not a project. Both systems get upgraded on different schedules; keep regression tests for the interfaces.
• Master data governance decides success. If material numbers or partner numbers drift apart, every interface breaks. Decide who owns which master data and how it's distributed (for larger landscapes look at SAP Master Data Integration).

6. Further reading (official)

• SAP Business Accelerator Hub — API specifications and pre-packaged integration content.
• SAP Help Portal — SAP Integration Suite (Cloud Integration) and SAP Event Mesh documentation.
• SAP's two-tier ERP resources for S/4HANA Cloud Public Edition.