IDoc vs EDI: what's the actual difference?

What is an IDoc?

An IDoc (Intermediate Document) is SAP's proprietary, fixed-format data container used to move business documents like purchase orders, invoices, and delivery notes into and out of an SAP system. It is not an EDI standard itself. It's the internal format SAP uses before (or after) a document gets converted to or from EDI.

If you've ever heard someone say "we exchange EDI with our SAP system using IDocs," that sentence is doing a lot of quiet work. IDocs is the standard exchange format for importing/exporting data in SAP systems, enabling exchange of master data, invoices, delivery notes etc with external or internal systems. It's SAP's internal passenger, not the vehicle that leaves the building.

Every IDoc, regardless of type, follows the same three-part structure:

• Control record (table EDIDC) — holds the IDoc number, direction (1 for outbound, 2 for inbound), sender and receiver partner data, message type, and the basic type. All Control Record data is stored in the EDIDC table, and it contains information like IDoc number, direction (inbound/outbound), sender, recipient information, channel in use, and port in use.
• Data record(s) — the actual payload, segment by segment. The Data Record contains application data such as employee header info, weekly details, client details, and so on, and all Data Record data is stored in tables EDID2 to EDID4.
• Status record — a log entry written at every processing milestone or error. A Status Record is attached to an IDoc at every milestone or when it encounters an error, all Status Record data is stored in the EDIDS table, and statuses 1–42 are for outbound while 50–75 are for inbound.

You can inspect any of this directly in the system using transaction WE02 or WE05, which is usually the first place an EDI analyst looks when a partner calls asking where their purchase order went.

IDoc vs EDI: what's actually different

EDI (X12, EDIFACT, TRADACOMS, VDA) is the external, cross-company standard your trading partners actually understand. IDoc is SAP's internal container, and it only becomes EDI after a separate piece of software converts it. Data exchange with other companies is referred to as EDI, and instead of the direct exchange of IDocs, data is first converted to a uniform exchange format such as UN/EDIFACT or ANSI ASC X12, with an EDI converter used for conversion between IDocs and the EDI format.

SAP does not ship that converter. The EDI subsystem transforms the IDocs into EDI formats and vice-versa, then sends or receives the EDI message to or from the trading partner, and SAP does not provide this subsystem within the SAP system itself — customers must find an outside EDI solution to implement it. That's why vendors like Cleo, SPS Commerce, TrueCommerce, and SEEBURGER exist in the SAP ecosystem at all. They're the box sitting between the IDoc layer and the AS2 or VAN connection to your supplier.

There's a sibling concept worth separating out, too: ALE (Application Link Enabling). The SAP term for data exchange with other in-house systems is ALE, and ALE communication may be synchronous or asynchronous. The clean way to remember it: if you send data to an external partner, you generally speak of EDI, while ALE is a mechanism to reliably replicate data between trusting systems to store a redundant copy of the IDoc data. Same IDoc structure, different destination, and technically a different transport too — ALE IDocs are communicated through memory buffers without intermediate files using transactional RFCs, while EDI IDocs are passed using an intermediate file.

Worked example: a purchase order from SAP to a supplier

Here's how ORDERS05, the basic IDoc type most SAP shops still use for outbound purchase orders, actually moves through a real flow:

1. A purchaser creates a purchase order in the SAP system using transaction ME21N.
2. The system then generates an ORDERS IDoc.
3. An Outbound IDoc is triggered through document message control in SAP to the EDI subsystem, which then converts the IDoc data into ANSI X.12, EDIFACT or an equivalent format and sends the data to the outside system via the internet. In practice this usually means an EDIFACT ORDERS message or an X12 850, carried over AS2 or a VAN connection, depending on what the supplier supports.
4. The supplier receives and processes the order automatically.
5. Upon shipment, a DESADV IDoc is sent back to the SAP system. An ORDRSP or an X12 855 order acknowledgment often comes back first, converted on the way in to an inbound IDoc that lands in SAP's purchase order history.

Notice what never happens in that list: SAP never writes raw EDIFACT or X12 to the wire. The IDoc is always the thing SAP produces and consumes. The converter is always the thing that speaks the trading partner's language.

Where this gets confused in practice

Most "IDoc errors" that land on an EDI team's desk aren't IDoc problems at all. They're partner profile or mapping problems that happen to surface as an IDoc status code. Two show up constantly:

• Status 56 — while processing an inbound IDoc, the system shows "Partner profile not available" and the IDoc changes to status 56 during processing. The fix is almost always in transaction WE20, checking that the sending partner, message type, and process code line up exactly.
• Status 51 — status 51 means the application document was not posted, showing the IDoc as received but not successfully processed. This is usually a field-level mapping mismatch between what the EDI subsystem built into the IDoc segments and what SAP's posting program expects, not a transport failure.

Non-SAP companies integrating with SAP shops run into this constantly during supplier onboarding: the partner's EDI VAN connection works fine, the AS2 handshake is clean, and the IDoc still bounces because WE20 wasn't updated for a new message type variant. This is exactly where an EDI/IDoc-aware mapping layer earns its keep, because debugging a status 56 without visibility into the SAP partner profile is close to guesswork.

When teams choose IDoc-native integration vs. a separate EDI layer

Large SAP shops generally keep native IDoc and ALE processing for SAP-to-SAP traffic between plants, subsidiaries, or group companies, since there's no conversion overhead and no external standard to maintain. But the moment a non-SAP partner, 3PL, or carrier enters the picture, you need either a dedicated EDI subsystem or an API layer sitting in front of it.

This is also where TMS and connectivity platforms differ quite a bit in how much IDoc-handling they build in natively versus leaning on a separate EDI provider. SAP TM obviously understands IDoc natively since it's SAP's own product. Platforms like MercuryGate, Descartes, and Transporeon have built out their own connector layers over the years to absorb IDoc and EDI traffic from shipper ERPs. Lighter-weight, carrier-connectivity-focused tools such as Cargoson take a different approach, sitting on top of whatever format a carrier or ERP already speaks so shippers aren't hand-mapping every new partner's IDoc or EDI quirks themselves.

FAQ

Is an IDoc the same as EDI? No. An IDoc is SAP's internal data container; EDI is the external standard (EDIFACT, X12) that a converter produces from that IDoc before it leaves the company.

Can IDocs be sent directly to a trading partner? Not in a usable way. A trading partner's system doesn't understand SAP's IDoc segment structure, which is why EDI subsystems are not provided within the SAP system and customers must find an outside EDI system solution to implement the conversion.

What's the difference between IDoc and ALE? They use the same IDoc structure, but ALE is for SAP-to-SAP data exchange inside one company, while EDI (via IDoc plus a converter) is for exchange with outside trading partners.

Do you need SAP to use IDocs? Yes. IDoc is an SAP-proprietary format; you won't find it in non-SAP ERPs, though some middleware tools can parse IDoc XML if they need to talk to an SAP system directly.

What replaces IDoc processing in S/4HANA? IDoc and ALE haven't disappeared, but SAP is pushing OData services and API-based integration (via BTP) for newer scenarios, which fits the broader API-vs-EDI hybrid pattern most supply chain IT teams are already managing for their non-SAP connections.