# SAP ERP Integration: Connecting S/4HANA and ECC to Everything Else

SAP ERP integration connects your core ERP, either S/4HANA or the older ECC, to CRM, ecommerce, logistics, and analytics systems. On modern S/4HANA you lean on OData and REST APIs plus the Integration Suite. On ECC you are often still on IDoc and BAPI/RFC. The variable that changes everything is cloud versus on-prem, because S/4HANA Cloud restricts some classic interfaces and forces a different design.

Most SAP ERP integration guides list the interfaces and stop there. The part that actually decides your architecture is which SAP edition you run, because that quietly removes options you may have assumed were on the table. A design that works fine against ECC can fail on day one against S/4HANA Cloud, and teams find out late.

So start with the edition, not the interface.

SAP ERP integration is how your ERP exchanges data with the systems around it. The ERP owns the records that run the business: the customer and material master, sales orders, deliveries, billing, inventory, and finance postings. Integration moves that data outward to CRM, ecommerce, and analytics, and pulls transactions back in.

In practice you connect the ERP to three kinds of systems:

1. CRM, so a closed deal in Salesforce becomes a sales order in SAP and the invoice status flows back to the account.

2. Ecommerce, so products, prices, and inventory stay current on the storefront and web orders land in the ERP.

3. Analytics and BI, so SAP transactional data reaches a warehouse or lake for reporting.

The method you use for each depends far more on your SAP edition than on the target system.

ECC, the older SAP Business Suite ERP, grew up on document-based and call-based interfaces: IDoc for structured document exchange, BAPI and RFC for function calls. These are mature, well understood, and deeply customizable, which is also their weakness. They assume you can reach the application server and, in many shops, that integration developers can add custom function modules.

S/4HANA moved the center of gravity to released OData and REST APIs, published in the SAP Business Accelerator Hub, with the Integration Suite as the recommended middleware. The interfaces are cleaner and API-first, but they are also governed. On the cloud editions you get the released APIs and little else.

Source: SAP interface availability per the SAP Help Portal S/4HANA integration guidance and the SAP Business Accelerator Hub. Verify each API against your exact release before you design against it.

Each interface family has a job it does well.

OData and REST are the default for anything new, especially on S/4HANA. They are HTTP-based, stateless, and easy to consume from a CRM, a storefront, or a serverless function. When you need real-time reads and writes against current SAP data, this is the path.

IDoc is document-based and asynchronous. It shines for high-volume, batch-style B2B and ERP-to-ERP document exchange like orders and invoices, where you want guaranteed delivery and a clear audit trail rather than a live request.

BAPI and RFC are function calls into SAP business logic. They are powerful for triggering an ERP process from outside, but they are tightly coupled and, on cloud editions, largely off the table.

There are two more worth knowing. SOAP web services still show up in older SAP landscapes and remain supported for many scenarios, so you will meet them on brownfield projects. Eventing, through SAP Event Mesh and event-driven interfaces, lets the ERP publish a business event (an order created, a delivery posted) that downstream systems subscribe to, which is closer to real-time than polling an API on a schedule. If your requirement is "tell the CRM the moment fulfillment changes," eventing beats a nightly IDoc batch.

Pro Tip

Rule of thumb: OData for real-time app integration, IDoc for high-volume document flows, eventing when you need push not poll, and BAPI/RFC only when you already run ECC or on-prem S/4HANA and need to call existing logic.

Here is the constraint that reshapes projects. On S/4HANA Cloud (public edition), SAP governs extensibility, so you cannot add arbitrary custom function modules and direct RFC access is restricted. You integrate through the released APIs and whitelisted communication scenarios, full stop.

If your original design assumed a custom BAPI or a direct RFC call, that design does not survive the move to cloud. You have to re-express the requirement against a released OData service, and if no released API covers your case, the integration waits until SAP ships one or you find a supported alternative.

The practical IDoc-to-OData migration decision looks like this. On ECC you might have sent sales orders in by IDoc for years. Moving to S/4HANA Cloud, you check whether a released OData API for sales order creation covers your fields and behavior. If it does, you rebuild the inbound flow as OData calls through the Integration Suite. If it does not, you either stage the data and use a supported bulk pattern or hold the interface until the API gap closes. The lesson from doing this work: confirm API coverage against your target release before you commit a timeline, because the gap between "SAP has an API for that" and "SAP has a released API for that on my edition" is where schedules slip.

ERP to CRM. S/4HANA exposes customer and order APIs; the CRM reads account and order status and writes new orders back. On ECC this same flow often runs on IDoc and BAPI. We map the CRM side of this in the Salesforce ERP integration guide.

ERP to ecommerce. Products, prices, and inventory sync outward to the storefront, and web orders come back as sales orders. Inventory latency is the metric that matters, because stale availability leads to overselling.

ERP to BI. Transactional and master data replicate to a warehouse or lake for reporting, typically through extraction or replication rather than live API calls, to avoid loading the ERP.

For choosing the connection style across these, the trade-offs in native integration vs. iPaaS and our Salesforce integration patterns and best practices apply directly.

A short path that keeps projects out of trouble:

1. Pin the edition first. ECC, on-prem S/4HANA, or S/4HANA Cloud. This decides your interface menu before anything else.

2. Map each requirement to a released interface. For every data flow, find the exact OData service, IDoc type, or BAPI, and confirm it exists on your release. Note any gaps early, because gaps become timeline risk.

3. Pick the pattern per flow. Real-time reads and writes lean OData; high-volume documents lean IDoc; near-real-time notifications lean eventing. You do not have to use one method for the whole project.

4. Decide where the logic lives. Point-to-point for one stable flow, Integration Suite or other middleware once you have several flows or need monitoring and guaranteed delivery.

Get the edition and the API-coverage check done before you commit dates, and most SAP ERP integrations stop surprising you.

What is SAP ERP integration? SAP ERP integration is the practice of connecting an SAP ERP system, either S/4HANA or ECC, to other applications such as CRM, ecommerce, logistics, and analytics. It uses interfaces like OData and REST APIs on modern S/4HANA and IDoc, BAPI, and RFC on ECC to exchange master data, orders, invoices, and inventory.

How do you integrate with S/4HANA? On S/4HANA you integrate primarily through released OData and REST APIs published in the SAP Business Accelerator Hub, usually orchestrated by SAP Integration Suite. On-prem S/4HANA also supports IDoc, BAPI, and RFC, while S/4HANA Cloud limits you to released APIs and governed communication scenarios.

What's the difference between ECC and S/4HANA integration? ECC relies mostly on IDoc, BAPI, and RFC and allows custom function modules, giving broad but tightly coupled options. S/4HANA is API-first with released OData and REST services and the Integration Suite. The cloud editions of S/4HANA restrict classic interfaces and custom extensions, so some ECC-era integration patterns must be redesigned.

Does S/4HANA Cloud support IDocs? S/4HANA Cloud favors released OData and REST APIs and governs extensibility, so classic direct-IDoc and custom RFC patterns are restricted compared to ECC or on-prem S/4HANA. For inbound documents you typically use a released API or a supported bulk pattern. Always confirm the specific scenario against your release, because coverage changes over time.

About the author. Sunny Chauhan is the founder of appnigma.ai, where we build native Salesforce apps and integrations without glue code: direct, observable connections instead of a stack of hand-maintained callouts. He's a Salesforce-certified Platform Developer II who spent the better part of a decade building integrations and managed packages, including work at Zennify and Salesforce, before founding appnigma. On ERP integration the edition question comes up first, because it decides which interfaces you even get to use.

Which SAP edition are you integrating against, and did you confirm the API coverage before you set the timeline?

<!-- Related reading: /blogs/salesforce-erp-integration-guide /blogs/salesforce-integration-patterns-and-best-practices /blogs/native-integration-vs-ipaas-mulesoft-boomi-zapier -->