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.

Häufig gestellte Fragen

Which data is synchronised between the ERP and SAP?

Typically, master data (contacts, companies, products) and transactional data (orders, invoices, payments) are synchronised. Which fields are actually transferred depends on the chosen connector and the master system. In most setups the ERP is the source for financial data and product master data, while SAP is the source for sales or operations data. A clean field-mapping table should be documented before go-live.

How is the sync frequency typically configured?

Common frequencies are real time (webhook-based), 5-15-minute intervals (polling) or nightly batches. Real time is state of the art for sales cases, while batches are sufficient for reporting data. The choice depends on the business process and the API load on both sides. With SAP, API rate limits should be checked early on — otherwise exceeding them leads to data gaps.

What interface options are available for the SAP integration?

There are three typical routes: native connectors from the ERP or SAP vendor, iPaaS platforms (Workato, Make, Zapier, Celigo), or custom REST/SOAP integrations. Native connectors are the fastest to set up, iPaaS offers the most flexibility, and custom integrations adapt to special cases. Which option is best depends on volume, complexity and budget — see the interface overview. A technical pre-analysis saves a lot of effort later on.

What is the master system in an SAP integration?

The master system holds the leading source of truth for a data object. For finance and accounting data the ERP is usually the master, while for sales and marketing data it is often SAP. This assignment should be documented in writing for each data object, otherwise inconsistencies arise with bidirectional synchronisation. A documented mapping is also important for GoBD-compliant traceability.

Which typical sources of error should be planned for?

Classic errors include unmapped mandatory fields, differing format standards (date, currency, tax rates) and missing conflict resolution for bidirectional sync. Just as critical are API limits, token expiry and unstructured error handling. A production-grade integration needs monitoring, alerting and a clear reprocessing path for errors. For the SAP integration, a dedicated test tenant in both systems is recommended.