What Is SAP? A Look at the ERP Behind So Many EDI Integrations, and How the Two Connect
If NetSuite and Epicor show up constantly in mid-market EDI work, SAP is the name that dominates the enterprise end of the spectrum. It’s one of the most widely deployed ERP platforms in the world, and understanding how it’s structured, and how EDI actually plugs into it, makes a real difference when you’re mapping transactions into or out of an SAP environment.
What Is SAP?
SAP was founded in 1972 by five former IBM employees, and over five decades it grew from single-tier mainframe software into one of the largest enterprise software companies globally. Its flagship platform today is SAP S/4HANA — the successor to the long-running SAP ECC (ERP Central Component) built on the SAP HANA in-memory database to deliver real-time analytics, a simplified data model, and the modern Fiori user interface. S/4HANA serves organizations across dozens of industries worldwide and functions as what SAP calls the “digital core” of a business, unifying finance, procurement, manufacturing, supply chain, and more into a single connected system.
S/4HANA comes in several deployment flavors, and which one an organization runs matters more for EDI than it might seem:
- Public Cloud — standardized, SAP-managed, fastest to deploy, generally aimed at organizations wanting best-practice processes with minimal customization
- Private Cloud — more room for customization and custom code, often chosen by companies migrating from an existing ECC environment
- On-premise — full infrastructure control, still common among large enterprises with long-standing SAP investments and heavy customization
How EDI Actually Connects to SAP
This is where SAP diverges meaningfully from cloud-native platforms like NetSuite. SAP doesn’t process EDI documents directly — it communicates internally through its own proprietary data format, the IDoc (Intermediate Document). Every purchase order, invoice, delivery note, or piece of master data moving in or out of SAP gets translated into an IDoc structure, using message types like ORDERS05 for purchase orders or INVOIC02 for invoices.
A few core building blocks show up in nearly every SAP EDI integration:
- IDocs — the standardized SAP-native document format that carries business data in and out of the system
- ALE (Application Link Enabling) — SAP’s framework for distributing IDocs between SAP systems, or between SAP and external systems, including port configuration and partner profiles that define who exchanges which message types
- SAP PI/PO (Process Integration/Process Orchestration) — the traditional middleware layer that sits between SAP and the outside world, translating external EDI formats (X12, EDIFACT) into IDocs and back again
- SAP Cloud Platform Integration (CPI) — SAP’s more modern, cloud-based alternative to PI/PO, capable of handling EDI formats directly through B2B library add-ons
In practice, most SAP-to-trading-partner EDI flows follow a similar pattern: an EDI document arrives from a VAN or AS2 connection in standard X12 or EDIFACT format, passes through middleware (PI/PO, CPI, or a third-party EDI provider) that maps it into IDoc structure, and is then posted into SAP through ALE. Outbound documents reverse the same path: SAP generates an IDoc, middleware translates it into the EDI format a trading partner expects, and it transmits out through a VAN or direct connection.
A Critical Detail: Not Every SAP Deployment Supports IDocs the Same Way
This is worth flagging explicitly, because it trips up teams working with newer SAP environments: IDocs are not available in S/4HANA Cloud Public Edition. Public Cloud’s standardized, SAP-managed architecture doesn’t expose the same IDoc/ALE interfaces that on-premise and Private Cloud deployments do. Organizations on Public Cloud typically need to rely on SAP’s API-based integration approach (via SAP Business Technology Platform) instead of the traditional IDoc route — a meaningfully different integration strategy than what most legacy SAP EDI documentation assumes.
Before assuming a mapping approach that worked for one SAP customer will transfer to another, it’s worth confirming which deployment model, and therefore which integration architecture you’re actually working with.
Why This Matters for EDI Practitioners
IDocs aren’t EDI, even though they carry the same data. An IDoc is SAP’s internal representation of a business document, not an X12 or EDIFACT transaction set. Every SAP EDI integration involves a translation step, and understanding where that translation happens (PI/PO, CPI, or a third-party VAN with SAP connectivity) is essential to troubleshooting when something breaks.
Partner profiles and message types drive everything. Unlike some ERPs where trading partner setup lives primarily in a vendor master record, SAP’s ALE layer requires explicit partner profile configuration for every combination of trading partner and message type. A missing or misconfigured partner profile is a common, SAP-specific source of failed transactions that has no direct equivalent in simpler ERP architectures.
Deployment model changes your entire integration strategy. As covered above, a Public Cloud customer and an on-premise customer may need fundamentally different technical approaches for the same trading partner relationship, even though the underlying business data is identical.
SAP’s enterprise scale means more customization to account for. Large, long-running SAP implementations often carry years of custom ABAP code and configuration. Two companies on “the same” SAP version can have meaningfully different IDoc structures and business logic, so a mapping built for one doesn’t necessarily transfer cleanly to another without validation.
SAP’s relationship with EDI is more layered than most other ERPs, precisely because SAP speaks its own internal language rather than processing EDI formats natively. For EDI practitioners, that means the real integration work often isn’t the X12 or EDIFACT mapping itself, but the translation layer connecting that mapping to SAP’s IDoc and ALE architecture. Understanding that structure, and knowing which deployment model you’re working with, is what separates a smooth SAP integration from one spent troubleshooting a partner profile nobody remembered to configure.
EDI Academy is a vendor-neutral EDI training and certification provider helping healthcare, retail, supply chain, finance, and IT teams build practical skills for accurate transactions and smoother operations.