SAP IDoc Explained: Structure, Processing, EDI and Monitoring

A SAP IDoc has been one of the most important technical foundations for automated data exchange in SAP landscapes for many years. Purchase orders, order confirmations, despatch advices, invoices and master data can be exchanged in a structured manner between SAP systems as well as between SAP and external applications using IDocs.

Even with SAP S/4HANA, cloud integration, APIs and modern integration platforms, IDocs remain highly relevant. Current SAP S/4HANA documentation continues to include established IDoc basic types such as ORDERS05, INVOIC02 and DELVRY07. At the same time, SAP Integration Suite provides dedicated IDoc sender and receiver adapters and supports SAP IDoc as a type system in Integration Advisor. IDocs therefore remain particularly relevant for established asynchronous business processes and B2B/EDI scenarios.

However, the role of SAP IDoc is evolving. In modern integration architectures, organisations need to assess more carefully when an IDoc is the right choice and when APIs, events, SOAP, OData or other integration mechanisms may be more appropriate.

Key Facts About SAP IDoc

IDoc stands for Intermediate Document. SAP describes IDoc as the standard SAP format for electronic data exchange between different systems. An IDoc is neither a transmission protocol nor the same as EDI or EDIFACT. Instead, it is a structured message used to transport business data that can subsequently be processed by the target application.

Six points are particularly important for understanding the SAP IDoc fundamentals:

• An IDoc generally consists of a control record, data records or segments, and status information.
• The message type describes the business meaning, for example ORDERS or INVOIC.
• The IDoc basic type defines the technical structure of the message, for example ORDERS05 or INVOIC02.
• Partner profiles and ports determine with whom IDocs are exchanged and via which technical route.
• IDoc status information documents individual processing steps and errors.
• For EDI formats such as UN/EDIFACT, the IDoc is typically transformed into the external format—and vice versa—via middleware.

A SAP IDoc therefore provides a standardised interface between SAP application logic and an integration or communication layer.

Table of Contents

SAP IDoc Fundamentals: What Is a SAP IDoc?

A SAP IDoc is a structured data object used for message-based information exchange between application systems.

The term “Intermediate Document” reflects its function: The IDoc provides a standardised intermediate structure between a business process in the sending system and processing in the receiving system.

SAP describes three key objectives of the IDoc interface: exchanging business documents in a structured manner and posting them automatically, mapping different complex application structures to a standardised interface structure, and enabling detailed error handling before posting.

A SAP IDoc can, for example, transport information relating to the following business transactions:

Purchase orders, order confirmations, invoices, deliveries, despatch advices, material master data and other business information.

The receiving system must understand both the business meaning of the message and the structure being used.

Is an IDoc a File?

Not necessarily.

Within SAP, an IDoc initially exists as a specific IDoc instance in the database. When exchanged with an external system, this information can then be serialised into a transferable representation. Ecosio therefore makes a useful distinction between an IDoc instance within the SAP system and an IDoc file used for external data exchange.

This distinction is important for understanding SAP IDoc fundamentals: IDoc does not refer only to a physical file, but also to the message object stored in the SAP system, including its processing status.

Why Is SAP IDoc Still Relevant in 2026?

Modern SAP architectures increasingly use APIs, OData, events, SAP Integration Suite and cloud-based integration patterns. However, this does not mean that IDocs are generally obsolete or no longer supported.

Current SAP S/4HANA documentation for 2025 FPS01, for example, continues to describe ORDERS05 for purchasing and sales processes, INVOIC02 for invoices and DELVRY07 for delivery processes. Even SAP S/4HANA Cloud Public Edition documentation includes current IDoc structures for specific business scenarios.

At the same time, the current SAP Integration Suite provides both IDoc sender and IDoc receiver adapters. SAP Integration Advisor also supports SAP IDoc as a dedicated type system alongside standards such as UN/EDIFACT and ASC X12.

The right question is therefore not:

“Are IDocs being replaced by APIs?”

But rather:

“Which integration pattern is best suited to which business process?”

For established asynchronous transaction and B2B processes, a SAP IDoc can still be highly suitable. For new real-time scenarios or targeted data services, APIs or event-driven architectures may be more appropriate.

What Is the Difference Between SAP IDoc, EDI, EDIFACT and ALE?

These four terms are often confused with one another. Technically, however, they describe different layers.

SAP IDoc

The SAP IDoc is SAP’s standardised document format for electronic data exchange.

It defines how the data to be transmitted is structured within an IDoc message. SAP explicitly states that IDoc is a format and not a communication channel or transmission medium.

EDI

EDI stands for Electronic Data Interchange and describes the structured electronic exchange of business documents between companies or systems.

EDI is therefore a broader integration concept. Purchase orders, despatch advices, invoices and order confirmations can be exchanged automatically.

EDIFACT

UN/EDIFACT is an international message standard for EDI.

An EDIFACT message is not a SAP IDoc. If, for example, an SAP system needs to send an EDIFACT message to a business partner, the internal SAP structure must be mapped to the external EDIFACT structure.

SAP Integration Suite supports exactly these types of B2B scenarios. Integration Advisor provides type systems for UN/EDIFACT and SAP IDoc and can generate mapping guidelines and runtime artefacts for transformation. SAP also provides templates for scenarios such as “EDI to IDoc” and “IDoc to EDI”.

ALE

ALE stands for Application Link Enabling and is an SAP technology for distributed applications and data exchange between logical systems.

ALE can use IDocs as the message format. SAP describes the distribution model in BD64, together with partner profiles, ports and message types, as central elements of ALE configuration.

In simplified terms:

IDoc = message format in SAP

EDI = electronic business document exchange

EDIFACT = external EDI message standard

ALE = SAP technology for distributed system communication

SAP IDoc Structure: How Is an IDoc Structured?

The SAP IDoc structure is one of the most important areas to understand from a technical perspective.

SAP distinguishes between three fundamental components:

1. Control Record

Every IDoc contains exactly one control record.

It contains administrative information about the message. This includes, for example, the sender, recipient, IDoc type, message type, direction and current processing status. SAP stores control record information in the EDIDC table.

Important fields include:

DOCNUM – unique IDoc number
IDOCTYP – IDoc basic type used
MESTYP – logical message type
SNDPRN – sender
RCVPRN – recipient
STATUS – current status

The control record therefore defines the technical context of the SAP IDoc.

2. Data Records and Segments

The actual business information is stored in the data records.

These data records are divided into segments. A segment represents a logically related group of fields, for example header, item, partner or date information.

SAP uses the EDIDD structure, among others, for data records. The SEGNAM field identifies the segment type, while SDATA contains the actual segment data. SAP documents a length of up to 1,000 bytes for SDATA.

Current data records are typically stored in the SAP database in EDID4.

3. Status Records

The third component of the SAP IDoc structure is the status information.

An IDoc can receive numerous status records throughout its lifecycle. This makes it possible to trace which processing steps were successful and where errors occurred.

Status records are stored in EDIDS. SAP explains that this status history does not necessarily form part of the actual message exchanged between systems, but documents the processing history within the respective system.

These status records form the basis for professional SAP IDoc Monitoring.

What Is the Difference Between an IDoc Basic Type, Message Type and Extension?

These terms are among the most common sources of confusion.

Message Type

The message type describes the business meaning of the message.

Examples include:

ORDERS for purchasing processes or INVOIC for invoice information.

The message type therefore describes what is being communicated.

IDoc Basic Type

The basic type, by contrast, defines the technical segment structure.

One example is ORDERS05. SAP currently documents this basic type for purchasing and sales documents. INVOIC02 also continues to be used as a standard IDoc structure for invoices.

A single basic type can be used for several message types. Ecosio, for example, shows that ORDERS05 can be used as the basis for ORDERS, ORDCHG or ORDRSP.

IDoc Extension

If a standard SAP IDoc does not meet all business requirements, the structure can be extended.

However, customer-specific extensions should be used carefully. The more Z-segments and custom mappings are introduced, the greater the maintenance, testing and migration effort.

For a modern integration architecture, the principle should therefore be:

Standard before extension.

Which Important SAP IDoc Types Are Available?

SAP provides a large number of IDoc structures for different processes.

Examples include:

Business Process	Message Type / Context	Example Basic Type
Purchase Order / Sales	ORDERS	ORDERS05
Order Confirmation	ORDRSP	e.g. ORDERS05
Invoice	INVOIC	INVOIC02
Delivery	Delivery Interface	DELVRY07

The specific combinations depend on the business process, SAP product, release and Customizing. SAP continues to document ORDERS05, INVOIC02 and DELVRY07 in current S/4HANA documentation for 2025 FPS01.

Transaction WE60 is particularly relevant for documentation of available IDoc types and segments.

How Does Inbound and Outbound SAP IDoc Processing Work?

A distinction is generally made between outbound and inbound processing.

Outbound – Sending SAP IDocs

In the outbound process, the IDoc is generated from a business transaction within the SAP system.

A typical example is a purchase order. Once the corresponding business document has been created or released, output control or application logic can generate the message.

The partner profile, message type, basic type and recipient port are then determined. The IDoc is created and transferred to the defined communication route.

In simplified terms, the process is:

SAP business document → output control / application logic → IDoc → port → middleware or target system

Partner profiles define, among other things, the message type, IDoc type, recipient port and transmission mode.

Inbound – Processing SAP IDocs

In the inbound process, the SAP system receives an IDoc from another system or middleware.

The IDoc interface first analyses the technical information. If the document can be processed formally, it can be transferred to the application logic.

The process code stored in the partner profile determines which processing logic or function module is called.

Successfully processed inbound IDocs typically receive status 53. If a business or technical error occurs during posting, status 51 may result. IDocs with status 64 are ready to be transferred to the application.

Configuring SAP IDoc: Which Components Are Required?

If you want to configure a SAP IDoc, you should not start with individual transactions. Instead, first define the end-to-end process.

Depending on the scenario, several configuration elements are relevant.

Partner Profiles – WE20

Partner profiles define which messages are exchanged with which partner and how they are processed.

For outbound processes, this includes, for example, the message type, IDoc basic type, recipient port and transmission mode.

For inbound processes, the message type and process code are defined, among other parameters.

Ports – WE21

Ports describe the technical handover point or communication method.

SAP documents WE21 as the central transaction for ports in IDoc processing. Depending on the architecture, RFC-based or file-based scenarios may be relevant.

RFC Connections – SM59

If RFC-based connections are used, the corresponding RFC destinations must be configured and tested.

Message Type and Basic Type – WE81 and WE82

WE81 is used to manage logical message types.

WE82 is used to maintain the assignment between a message type and an IDoc type.

Process Codes – WE41 and WE42

Process codes define the processing logic.

WE41 is used for outbound process codes and WE42 for inbound process codes.

ALE Distribution Model – BD64

In ALE scenarios, the distribution model defines which messages are distributed between which logical systems.

Configuration always depends on the specific process. There is no single general IDoc Customizing procedure that is identical for every interface.

Sending SAP IDocs: How Does the Outbound Process Work in Practice?

To send a SAP IDoc, both technical and business settings must work together.

First, the business transaction that triggers the message must be defined. The system must then be able to determine the business partner and the correct message type.

The partner profile contains the relevant outbound parameters. These typically include the message type, IDoc basic type, recipient port and whether IDocs are transmitted immediately or in batches.

For certain ORDERS scenarios, for example, SAP documents the combination of message type ORDERS, basic type ORDERS05 and a defined recipient port.

In a middleware architecture, however, business processing does not end at the SAP port. Middleware may also need to transform, route, technically transmit and monitor the SAP IDoc.

Processing SAP IDocs: How Does the Inbound Process Work?

When processing SAP IDocs, two levels must be distinguished:

technical receipt of the message and business posting.

A technically successfully received IDoc does not automatically mean that a business document has been successfully posted.

After receipt, the IDoc interface analyses the message. Depending on the partner profile and processing settings, it is transferred to the application either immediately or at a later point in time.

SAP describes the following typical sequence, for example:

50 → IDoc added

64 → IDoc ready to be passed to application

62 → IDoc passed to application

53 → Application document posted

If an error occurs during business processing, status 51 is frequently generated.

The status model therefore provides a very precise view of the current stage of processing.

SAP IDoc Monitoring: How Can IDocs Be Monitored?

Professional SAP IDoc Monitoring is essential for productive EDI and integration processes.

The classic SAP tools remain important.

WE02

WE02 is used to display individual IDocs and enables analysis of the control record, segment data and status history.

WE05

WE05 displays IDocs in list form and is suitable for selecting larger volumes of IDocs.

BD87

BD87 is a central status monitor and, depending on the status, also enables IDocs to be reprocessed. SAP explicitly refers to BD87 in current troubleshooting documentation for reprocessing failed IDocs.

WE19

WE19 is a testing tool for IDocs. The transaction is suitable for testing and analysis, but should not be confused with standard productive reprocessing.

WE60

WE60 provides technical documentation for IDoc types and segments.

WLF_IDOC and Application-Specific Monitors

SAP S/4HANA also provides application-specific and more modern monitoring approaches. SAP documents, for example, IDoc monitors for incoming orders, despatch advices and delivery schedules, as well as WLF_IDOC for specific processing scenarios. The exact functionality depends on the application and release.

For hybrid architectures, SAP IDoc Monitoring in the backend alone is not sufficient. Middleware should also be monitored so that the complete path from the sender through mapping and transport to final posting remains traceable.

What Do SAP IDoc Status Codes 51, 53 and 64 Mean?

These three status codes are among the most important status indicators for inbound IDocs.

Status 51 – Application Document Not Posted

Status 51 means that processing in the application was not completed successfully.

Possible causes include:

Missing or incorrect master data, inconsistent Customizing, invalid values, incorrect process codes or locking conflicts.

SAP documents, for example, that locking issues or inconsistent inbound configuration can lead to status 51.

The correct approach is not to immediately restart the IDoc. The underlying cause should first be understood and resolved.

Status 53 – Application Document Posted

Status 53 means that the application document was posted successfully.

The business-related inbound processing is therefore generally complete. SAP explicitly assigns status 53 to “Application document posted”.

Status 64 – Ready to Be Passed to Application

Status 64 means that the IDoc is technically available and ready to be processed by the application.

This is not automatically an error.

Depending on the partner profile, processing may deliberately be scheduled for later or run in the background. SAP refers, for example, to report RBDAPP01 for this purpose.

If unusually large numbers of IDocs remain permanently in status 64, job scheduling and inbound processing settings should be checked.

How Can Failed SAP IDoc Messages Be Reprocessed?

When an error occurs, the cause should first be analysed.

A sensible sequence is:

1. Check the status and error message.

Open the IDoc in WE02, WE05 or BD87 and analyse the status information.

2. Check segment data.

Determine whether mandatory information is missing or invalid values have been transmitted.

3. Check master data and Customizing.

Many status 51 errors are not caused by the IDoc framework itself but by the application.

4. Check partner profile and process code.

An incorrect process code may cause the wrong inbound function module to be called. SAP explicitly documents such error scenarios.

5. Resolve the root cause.
   
6. Reprocess the IDoc.

Depending on the status and scenario, BD87 or an appropriate background processing mechanism can be used.

Direct manual changes to productive IDoc content should only be made in a controlled manner and with due consideration of authorisations, auditability and business responsibility.

SAP IDoc EDIFACT: How Are IDoc and EDIFACT Related?

For the secondary keyword SAP IDoc EDIFACT, one clarification is particularly important:

A SAP IDoc is not an EDIFACT document.

UN/EDIFACT is an external B2B message standard. IDoc is SAP’s own message format.

A classic scenario may, for example, look like this:

SAP → IDoc → Middleware → Mapping → EDIFACT → Business Partner

For inbound processing:

Business Partner → EDIFACT → Middleware → Mapping → SAP IDoc → SAP Application

The middleware performs the transformation between the two data models.

SAP Integration Advisor currently supports both UN/EDIFACT and SAP IDoc as type systems. Companies can use these to create Message Implementation Guidelines and Mapping Guidelines and generate runtime artefacts for Cloud Integration.

Current SAP documentation also describes standardised integration flow templates for EDI to IDoc and IDoc to EDI.

For a modern SAP IDoc EDIFACT scenario, technical mapping is therefore only one aspect. Partner profiles, EDIFACT versions and subsets, qualifiers, code lists, communication protocols and end-to-end monitoring must also be considered.

Further reading: SAP Integration Suite

Where Can SAP IDoc Be Used?

IDocs are particularly well suited to structured, message-based and often asynchronous processes.

Typical areas of application include Procurement, Sales, Logistics, Finance, master data distribution and EDI partner communication.

A classic example is a purchase order: An SAP system generates an ORDERS IDoc, middleware transforms the message into the format required by the supplier and transmits it. The order confirmation or despatch advice can then be processed back into SAP using the reverse path.

Invoice processes can also be integrated using IDocs. SAP continues to document INVOIC02 as a standard IDoc structure for invoices.

However, in modern statutory e-invoicing scenarios, companies should assess whether IDoc serves only as an internal integration format while regulatory processing is handled through solutions such as SAP Document and Reporting Compliance.

Further reading: E-Invoicing with SAP

What Role Does SAP IDoc Play in SAP S/4HANA?

SAP IDoc remains relevant in SAP S/4HANA, but it must be considered in the context of the specific application and output framework being used.

SAP S/4HANA Output Control supports electronic communication via the EDI channel. Depending on the specific business scenario, this can transmit IDocs or SOA messages. At the same time, SAP points out that the standalone IDOC channel within this Output Control framework is intended only for certain purposes, particularly Intercompany Billing.

This distinction is important:

It does not mean that IDocs in SAP S/4HANA can only be used for Intercompany Billing. It describes the specific scope of the IDOC output channel within SAP S/4HANA Output Control.

Other applications and integration frameworks can continue to provide IDoc-based interfaces.

For an S/4HANA project, existing SAP IDoc interfaces should therefore be analysed individually. Basic types, segments, extensions, output control, middleware mappings and downstream processes must be checked against the target release.

SAP IDoc and SAP Integration Suite

SAP Integration Suite clearly demonstrates that IDocs can also form part of modern hybrid architectures.

SAP currently provides both an IDoc sender and IDoc receiver adapter. These adapters enable message exchange between SAP Integration Suite and systems that support the relevant IDoc communication via SOAP Web Services.

Integration Advisor also enables modelling and transformation between different B2B standards.

For example, a company can:

receive a SAP IDoc from SAP, validate and transform it within Integration Suite, convert it into EDIFACT or another partner format and forward it using the appropriate B2B communication method.

IDoc is therefore not disappearing from modern architectures. Instead, its role is changing: from a standalone point-to-point mechanism to a message format within a more centralised integration platform.

SAP IDoc or API – Which Approach Is Better?

There is no universal answer.

IDocs are particularly strong for established asynchronous business documents and large B2B/EDI process landscapes. APIs, on the other hand, are often better suited to targeted synchronous queries and real-time transactional interactions.

Events are particularly useful where loosely coupled systems need to react to business events.

For a new integration scenario, organisations should therefore ask several questions:

Does communication need to be synchronous? Is an immediate response required? Is a complete business document being transmitted? Is there already a stable SAP IDoc standard? Are business partners connected via EDI? Which integration interface does SAP strategically provide for the specific S/4HANA scenario?

The Clean Core principle does not mean that IDocs should generally be eliminated. Instead, it promotes the use of standard interfaces, minimising customer-specific modifications in the ERP core and encapsulating integration logic in a controlled manner.

Best Practices for SAP IDoc

Use Standard IDocs Before Custom Development

First check whether an existing basic type and message type already cover the process.

Clearly Distinguish Between Message Type and Basic Type

The business meaning belongs to the message type, while the technical segment structure belongs to the basic type.

Document Middleware Mappings

For SAP IDoc EDIFACT or other B2B scenarios, every relevant mapping should be documented transparently and version-controlled.

Establish End-to-End Monitoring

A green status 53 in SAP does not automatically prove that the complete partner process has been completed successfully. Conversely, successful transmission in middleware may still be followed by an error during SAP posting.

SAP IDoc Monitoring and middleware monitoring should therefore be linked.

Avoid Unnecessary Custom Segments

Every extension increases dependencies during S/4HANA transformations, release changes and partner mapping.

Process Large Volumes in a Controlled Manner

For high-volume scenarios, package sizes, parallelisation, locking behaviour and background jobs should be deliberately configured. SAP points out that parallel inbound processing can cause locking conflicts.

Do’s & Don’ts for SAP IDoc

Do

Define the business process first and the technical interface second. Use SAP standard basic types wherever possible, document partner profiles and mappings, establish automated SAP IDoc Monitoring, and test both technical and business error scenarios.

Don’t

Do not automatically equate IDoc with EDI or EDIFACT. Do not manually modify productive IDocs without proper controls. Do not use WE19 as a replacement for controlled reprocessing. Do not migrate existing ECC interfaces to SAP S/4HANA without reviewing them first, and do not develop Z-segments before fully evaluating standard functionality.

Step by Step – Configuring SAP IDoc

Step 1 – Define the Business Process

Determine which business document is to be exchanged between which systems.

Step 2 – Select the Integration Pattern

Decide whether IDoc is genuinely the right interface for the scenario or whether an API, event or another standard interface would be more appropriate.

Step 3 – Select the Message Type and Basic Type

Review the available SAP standard types using SAP documentation and WE60.

Step 4 – Define Sender and Recipient

Configure logical systems or business partners in accordance with the scenario.

Step 5 – Configure the Port

Define the technical communication route in WE21 and, where required, the relevant RFC destination in SM59.

Step 6 – Configure the Partner Profile

Maintain the required inbound and/or outbound parameters in WE20.

Step 7 – Configure Processing Logic

Review process codes, function modules, output control and, where applicable, ALE distribution models.

Step 8 – Integrate Middleware

For EDI processes, mapping, routing, technical communication and partner parameters must be configured.

SAP Integration Advisor can, for example, be used to create Mapping Guidelines between SAP IDoc and UN/EDIFACT and generate runtime artefacts for Cloud Integration.

Step 9 – Perform End-to-End Testing

Do not test only the happy path. Also consider missing master data, incorrect partner profiles, mapping errors, locking situations, duplicate messages and technical connection failures.

Step 10 – Establish Productive SAP IDoc Monitoring

Define responsibilities, alerting, restart procedures, SLAs and escalation paths.

What Role Do IDocs Play in E-Invoicing?

IDocs can continue to serve as an internal integration mechanism in invoice processes. INVOIC02, for example, is still documented in current S/4HANA releases.

However, a modern statutory e-invoicing architecture should distinguish between the internal message structure and the regulatory exchange format.

An IDoc is not automatically an XRechnung, Peppol BIS Invoice or another legally relevant invoice format.

For international e-invoicing and reporting requirements, SAP Document and Reporting Compliance supports the creation, processing and monitoring of electronic documents. For operational inbound invoice processing, solutions such as SAP Invoice Management by OpenText may also be relevant.

Further reading: SAP Document and Reporting Compliance

Further reading: Receiving E-Invoices in SAP

Conclusion – Why SAP IDoc Remains Important

A SAP IDoc is far more than a historical exchange format from the traditional SAP ERP world.

It continues to provide an important interface for structured, automated and asynchronous business processes. Current SAP documentation for SAP S/4HANA continues to include established basic types such as ORDERS05, INVOIC02 and DELVRY07. SAP Integration Suite also provides IDoc adapters and support for SAP IDoc within Integration Advisor.

However, successful use depends on understanding the SAP IDoc fundamentals. Organisations must clearly distinguish between the message type, basic type, segment structure, partner profile, port and process code.

End-to-end SAP IDoc Monitoring is equally important. Status codes 51, 53 and 64 are not merely technical codes but provide essential information about the state of a business process.

A clear distinction is also necessary when it comes to SAP IDoc EDIFACT: IDoc is the internal SAP format, while EDIFACT is an external B2B standard. An integration platform performs the mapping between the two structures.

With SAP S/4HANA and cloud technologies, the integration landscape continues to evolve. Companies should therefore neither eliminate IDocs automatically nor continue using them by default for every new interface.

The right strategy is to select the most appropriate integration pattern for each process: IDoc and EDI for robust document-based B2B processes, APIs for targeted real-time communication, and events for loosely coupled, event-driven architectures.

This allows SAP IDoc to remain an important building block within a modern, standardised and well-monitored integration architecture.

Frequently Asked Questions About SAP IDoc