An IDoc (Intermediate Document) is SAP’s standard electronic document format for exchanging business data between SAP systems and between SAP and external systems. Whenever a purchase order, invoice, material master, or delivery needs to move electronically from one system to another, it usually travels as an IDoc.
IDocs sit at the center of ALE (Application Link Enabling) and EDI (Electronic Data Interchange) scenarios, and IDoc questions appear in many SAP ABAP and integration interviews.
The IDoc Concept in Plain English
Think of an IDoc as a structured envelope. Instead of two systems calling each other’s code directly, the sending system packs business data into a standard format (the IDoc), hands it to the communication layer, and the receiving system unpacks it and posts the corresponding application document. This decoupling is what makes ALE and EDI robust: each side only needs to understand the IDoc format, not the other system’s internals.
An IDoc is identified by a unique IDoc number and always belongs to a message type (what business meaning it carries, such as ORDERS) and an IDoc type (its exact technical structure, such as ORDERS05).
IDoc Structure: Control, Data, and Status Records
Every IDoc has three parts:
- Control record (EDI_DC40): the header. It carries the IDoc number, message type (MESTYP), IDoc type (IDOCTYP), sender and receiver partner information (SNDPRN/SNDPRT, RCVPRN/RCVPRT), and the port. This is how the system knows what the IDoc is and where it goes.
- Data records (segments): the payload. Data is organized into segments, each with a segment name (SEGNAM) and segment data (SDATA). For example, a purchase order IDoc has a header segment (E1EDK01), item segments (E1EDP01), and schedule line segments (E1EDS01).
- Status records (EDI_DS40): the tracking log. Every processing step appends a status record with a status code, timestamp, and message text — so you can trace exactly what happened to an IDoc from creation to posting.
Basic IDoc Types vs Extension IDoc Types
- Basic IDoc types are SAP-delivered structures such as ORDERS05 (purchase order) or INVOIC02 (invoice). They cover standard business scenarios out of the box.
- Extension IDoc types are customer-created enhancements of a basic type, built when the standard segments do not carry all the fields a business needs. They are developed with the IDoc type editor (WE30) and new segments (WE31), and their names follow customer naming conventions.
The rule of thumb: use the basic type whenever it fits, and extend only when a genuine business field is missing.
Common IDoc Message Types
| Message Type | Business Meaning | Typical IDoc Type |
|---|---|---|
| ORDERS | Purchase order sent to a vendor or another system | ORDERS05 |
| INVOIC | Invoice / billing document | INVOIC02 |
| DESADV | Delivery notification / advance shipping notice (ASN) | DESADV01 |
| MATMAS | Material master distribution | MATMAS05 |
| DEBMAS | Customer master distribution | DEBMAS06 |
| CREMAS | Vendor master distribution | CREMAS05 |
Master data messages (MATMAS, DEBMAS, CREMAS) are typically distributed via ALE to keep master records synchronized across systems, while transactional messages (ORDERS, INVOIC, DESADV) drive EDI scenarios with business partners. If you work with material master distribution, our complete list of SAP MM tables helps you understand what data MATMAS carries.
ALE vs EDI: Where IDocs Are Used
- ALE (Application Link Enabling): distributes data between SAP systems — for example, sending material masters from a central system to plant systems, or replicating purchase orders between an ECC backend and a satellite system. ALE uses logical systems, partner profiles, and distribution models.
- EDI (Electronic Data Interchange): exchanges business documents with external partners — for example, sending purchase orders to a supplier’s non-SAP system or receiving invoices. EDI typically converts the IDoc to an external standard (like EDIFACT or ANSI X12) at the port.
In both cases, the IDoc is the common language in the middle.
Inbound vs Outbound IDoc Flow
Outbound flow: an application document is created (for example, a purchase order) → the output/ALE configuration triggers IDoc creation → the IDoc gets status 30 (ready for dispatch) → it is passed to the port (status 03, data passed to port OK) → the subsystem or EDI converter picks it up (status 12, dispatch OK).
Inbound flow: the IDoc arrives at the port (status 50, added) → it is transferred to the application layer (status 64, ready for processing) → the application posts the document (status 53, application document posted) or fails with an error (status 51, application document not posted).
Monitoring these statuses is the core of IDoc support work.
Common IDoc Status Codes at a Glance
| Status | Meaning |
|---|---|
| 03 | Data passed to port OK (outbound) |
| 12 | Dispatch OK (outbound) |
| 30 | IDoc ready for dispatch via ALE |
| 50 | IDoc added (inbound received) |
| 51 | Application document not posted — fix the cause, then reprocess with BD87 |
| 53 | Application document posted successfully |
| 62 | Passed to port OK (inbound) |
| 64 | IDoc ready to be transferred to the application |
Statuses 51 and 53 are the two you will check most: 53 means success, while 51 means open WE02, read the error message, fix the root cause, and reprocess with BD87.
Key IDoc TCodes
| TCode | Description |
|---|---|
| WE02 | Display a single IDoc by number — control, data, and status records in full detail |
| WE05 | IDoc lists and search — find IDocs by message type, partner, date, or status |
| BD87 | Reprocess failed inbound IDocs (status 51) after fixing the underlying error |
| SM59 | Maintain RFC destinations — the technical connections IDocs travel over between systems |
Related configuration TCodes you will encounter: WE20 (partner profiles), WE21 (ports), WE30 (IDoc type development), and WE31 (segment development).
Example Scenario: Purchase Order via ORDERS
A buyer creates a purchase order in the SAP backend. The output configuration determines that this vendor receives orders via EDI, so the system generates an ORDERS05 IDoc with message type ORDERS. The control record identifies the vendor as the receiver; the data segments carry the PO header (E1EDK01), items (E1EDP01), and schedule lines (E1EDS01). The IDoc moves through statuses 30 → 03 → 12 as it leaves SAP, the EDI subsystem converts it to the agreed external format, and the vendor’s system imports it as a sales order. If anything fails on an inbound IDoc, the support team finds it in WE05 and reprocesses it with BD87.
Frequently Asked Questions
What is the difference between ALE and EDI?
Answer: ALE exchanges IDocs between SAP systems using SAP’s own protocols (typically RFC/tRFC), for example distributing master data between a head office and plants. EDI exchanges business documents with external, often non-SAP partners, usually converting the IDoc into an industry standard format at the port. IDocs are the common document format in both.
What is the difference between a basic IDoc type and an extension?
Answer: A basic IDoc type is SAP’s standard structure (for example, ORDERS05) delivered for a message type. An extension is a customer-built enhancement of a basic type that adds custom segments for fields the standard does not carry. Extensions are created with WE30/WE31 and are used when the business genuinely needs extra data.
Which TCode do I use to reprocess a failed IDoc?
Answer: BD87 reprocesses failed inbound IDocs (status 51). First fix the root cause — a missing master record, a locked document, a configuration gap — then select the IDoc in BD87 and reprocess it so the application layer attempts posting again.
What does IDoc status 51 mean?
Answer: Status 51 means “application document not posted” — the IDoc reached the application layer but posting failed. Common causes are missing master data, validation errors, or locked records. The status record’s message text (visible in WE02) usually names the exact error.
Can one IDoc type be used for multiple message types?
Answer: Technically an IDoc type defines structure while the message type defines business meaning, and the combination is what matters in configuration. In practice, each standard IDoc type is designed for a specific message type (ORDERS05 for ORDERS), so you configure and monitor them as pairs.
Conclusion
IDocs are SAP’s standard envelope for electronic business documents: a control record identifying the message, data segments carrying the payload, and status records tracking every step. Learn the key message types (ORDERS, INVOIC, DESADV, MATMAS), the status codes (30, 50, 51, 53, 64), and the four TCodes WE02, WE05, BD87, and SM59 — and you will be ready for IDoc questions in any ABAP or integration interview. Practice reading an IDoc in WE02 — control record first, then segments, then statuses — and the whole ALE/EDI topic clicks into place.