ERP with SAP Integration
SAP runs much of the upper German Mid-Market and almost all of the DAX-40 corporate centre. When a non-SAP system — a specialist CRM, a niche planning tool, an e-commerce platform, a recently acquired subsidiary's ERP — needs to exchange data with the SAP core, the integration architecture decisions are consequential and long-lived. SAP itself offers a layered integration stack, and the choice between the layers depends on the SAP product (ECC, S/4HANA on-premise, S/4HANA Cloud, Business One, Business ByDesign), the integration latency requirements and the organisation's broader cloud strategy. This page describes the practical patterns for SAP-to-non-SAP integration in the DACH Mid-Market context.
The SAP integration stack
SAP's on-premise integration heritage runs through SAP NetWeaver Process Integration (PI), renamed Process Orchestration (PO) in its more recent form. PI/PO is a Java-based middleware running adapters for IDoc, RFC, BAPI, file and REST; it remains the substrate for many older Mid-Market SAP estates. The cloud successor is SAP Cloud Platform Integration (CPI), now branded SAP Integration Suite as part of SAP Business Technology Platform (BTP). CPI offers pre-built integration content (iFlows) for SAP-to-SAP and SAP-to-third-party scenarios. For S/4HANA Cloud customers, CPI is effectively the only sanctioned integration path; for S/4HANA on-premise customers, most new projects favour CPI over PI/PO.
SAP API Business Hub and the API-first surface
SAP has invested substantially in publishing the S/4HANA API surface through the SAP API Business Hub, a public catalogue of OData and REST APIs covering the major business objects (business partner, sales order, purchase order, material, financial document). For non-SAP systems integrating with S/4HANA, the recommended pattern is to call these APIs directly via CPI or an external iPaaS rather than via legacy IDoc-and-RFC plumbing. The OData APIs are well-aligned with modern application integration patterns. Buyers should plan to use the published APIs as the primary surface and treat IDoc-and-RFC paths as a fallback for legacy scenarios only.
Big-Bang versus Coexistence integration patterns
Two-speed IT architectures are common in the upper Mid-Market: the SAP core handles finance, controlling and supply-chain processes, while specialist applications (e-commerce, HubSpot or Salesforce CRM, Mendix or OutSystems custom apps) handle customer-facing workflows. The Big-Bang pattern attempts to bring all data into the SAP core in real time; the Coexistence pattern accepts that some data lives outside the SAP core. Coexistence is the more common choice for new projects because it avoids stretching SAP's data model to absorb every new requirement. SAP's own "clean core" messaging supports this: keep S/4HANA standard and integrate via APIs to extensions on BTP or third-party systems.
DATEV, GoBD and OSS in the SAP context
SAP S/4HANA does not ship a native DATEV interface; the Mid-Market DATEV interface is typically supplied by a partner connector (for example Reisswolf, Compusoft, Universal Datenexchange) that runs as an add-on or as a CPI iFlow. The connector exports DATEV pro format files or uses the DATEV-API directly. GoBD-Verfahrensdokumentation for an SAP estate is more elaborate than for a small-business ERP because the data flow involves multiple modules (FI, CO, MM, SD, AA), several integration layers and frequently a separate archive system; SAP partners often supply a template Verfahrensdokumentation that customers complete and maintain. OSS reporting in S/4HANA is supported by the standard tax-determination framework, with country-of-consumption tagging at the tax-code level; the export to the OSS quarterly return filed via the German Federal Central Tax Office (BZSt) typically runs through the same DATEV connector or via a specialist tax-tech provider.
Related Topics
Frequently Asked Questions
Should we still use SAP PI/PO for new integrations?
For most new builds, no. SAP's strategic investment is in the SAP Integration Suite on BTP (CPI and adjacent services), and new integration content is being developed there. PI/PO remains supported but is gradually being positioned as a legacy on-premise option. Organisations with a substantial PI/PO estate continue to run it; new projects typically standardise on CPI even where the SAP core remains S/4HANA on-premise.
What is the role of SAP Business One and Business ByDesign in this picture?
Business One is SAP's product for small businesses (typically below 100 users); Business ByDesign is the cloud product for upper-SMB and lower-Mittelstand. Both have their own integration surfaces — Business One uses the DI API and Service Layer, ByDesign uses its own SOAP and REST APIs — rather than the S/4HANA stack. CPI can connect to both, but the integration patterns are different from S/4HANA, and partners with specific Business One or ByDesign experience are valuable when integrating these products with non-SAP systems.
How does the "clean core" principle affect integration design?
Clean core means keeping the S/4HANA core close to standard, with extensions running side-by-side on BTP or in external systems and integrating via published APIs. For integration design this discourages writing custom logic inside the SAP core (in classic ABAP user exits and modifications) and encourages exposing standard APIs and consuming external APIs through CPI. The benefit is that S/4HANA upgrades become substantially less painful; the cost is that some traditional SAP development patterns no longer apply.
Can iPaaS platforms outside SAP replace CPI?
Technically yes — MuleSoft, Boomi and Workato all have SAP connectors and can integrate S/4HANA with third-party systems. For Salesforce-centric organisations MuleSoft is often preferred; for organisations with an existing Boomi or Workato footprint, the same applies. The pragmatic test is whether the organisation expects to operate primarily inside SAP's integration content (in which case CPI is the natural fit) or primarily across a broad heterogeneous estate (in which case an external iPaaS may serve better).