What Is an IDoc in SAP? Structure, Processing, and Status Monitoring

An IDoc, or Intermediate Document, is a structured data container used to exchange business information between SAP systems and external applications. It supports asynchronous integration, so the sending and receiving processes can run independently while SAP records the document and its processing status.

IDocs are common for orders, invoices, deliveries, master data, and other business objects. The exact content depends on the message type, the basic type, the partner configuration, and any extensions used by the integration.

01What an IDoc contains

An IDoc has three logical parts: a control record, one or more data records, and status records. Together, these parts identify the exchange, carry the business payload, and show what happened during processing.

The control record describes the IDoc as an integration object. The data records contain hierarchical segments such as header, partner, item, and schedule information. Status records are appended as the IDoc moves through technical and application processing.

02IDoc structure and terminology

A basic type defines the technical segment structure available to an IDoc. A message type gives the business meaning, such as a sales order or invoice exchange. An extension adds customer-specific segments to a basic type while retaining the standard structure as its foundation.

The structure usually follows a hierarchy. A header segment can have child segments, and item segments can have their own dependent segments. The receiving process interprets the segment sequence and field content according to the configured message and basic type.

For a broader overview of how SAP products and components fit together, see SAP modules overview. This context helps when an IDoc crosses an MM, SD, FI, or other application boundary.

03Inbound and outbound IDoc processing

An outbound IDoc is created in the sending system and passed to a receiver. The sender determines the business event, message type, partner, and technical destination. The receiver then accepts the IDoc and starts inbound processing through the configured process code or application logic.

An inbound IDoc enters the receiving system and is processed by an inbound function or related application mechanism. Successful processing creates or updates the intended business document. A failed IDoc remains available for analysis and reprocessing after the underlying problem is resolved.

IDocs and remote function calls solve different integration needs. A remote function call guide provides useful context when deciding whether an interface should exchange a queued document or invoke a remote function synchronously.

04How to monitor IDoc status

Use transaction WE02 or WE05 to search IDocs by number, date, direction, message type, basic type, partner, or status. Open the result to inspect the control record, data records, and status history.

Common operational status categories include:

• Successful processing: the receiving application completed its work.
• Ready for dispatch or processing: the IDoc is waiting for the next technical or application step.
• Error: processing stopped and requires investigation.
• Processing: a background or communication process is currently handling the IDoc.

The status history is chronological. Start with the first status that indicates a failure, then inspect its message text and timestamp. Later statuses often describe the consequence of the original problem rather than a separate root cause.

For a group of failed inbound IDocs, transaction BD87 provides a practical reprocessing view. Resolve the configuration, master-data, authorization, or application issue first, then reprocess only the affected documents and verify the resulting status.

05IDoc troubleshooting workflow

Use this sequence when an IDoc does not complete:

1. Identify the document in WE02 or WE05 using the IDoc number, partner, message type, or time range.
2. Confirm the direction and inspect the control record for sender, receiver, message type, and basic type.
3. Read the earliest error status and capture the complete message text.
4. Inspect the data records for missing, invalid, or inconsistent business values.
5. Check configuration for the partner profile, port, process code, message type, and any required output settings.
6. Check application prerequisites, including master data, posting periods, organizational assignments, and authorizations.
7. Correct the cause in the responsible system or configuration.
8. Reprocess the IDoc with BD87 or the relevant operational function.
9. Verify the final status and confirm that the expected business document exists.

For outbound failures, inspect the destination and dispatch path as well as the application output that created the IDoc. For inbound failures, inspect the process code, application function, payload values, and business prerequisites.

06Partner and interface configuration

Partner profiles in WE20 define how a partner exchanges messages. Depending on the direction, the profile contains inbound or outbound parameters such as message type, processing settings, port, and dispatch options.

Ports in WE21 describe the technical route used to exchange the IDoc. The port configuration must match the communication method and destination expected by the interface.

The message type connects the business meaning to the interface configuration. The basic type controls the segment structure, while an extension supports additional fields where the integration requires them. Process codes connect inbound or outbound processing to the relevant application logic.

Keep configuration changes traceable across the SAP landscape. A SAP client guide explains the client concept that affects where interface configuration and test data are maintained.

07Safe IDoc reprocessing

Reprocessing is a business operation as well as a technical action. Before starting, determine whether the original attempt created a partial document, posted an accounting document, or triggered a downstream message. The correct recovery action may be a controlled restart, a reversal, or a new business transaction instead of a simple retry.

Use the original IDoc number and status history as the audit trail. Record the error, correction, operator, and outcome. After reprocessing, verify both the final IDoc status and the business result so that a technically successful status does not conceal duplicate or incomplete processing.

08Practical IDoc checklist

When handing an IDoc issue to another support group, provide:

• IDoc number and creation timestamp
• Direction, message type, and basic type
• Sender and receiver partner
• Current status and earliest failure status
• Complete status message text
• Relevant segment and field values
• Whether reprocessing has already been attempted
• Expected business document and observed result

This information lets application, integration, and technical teams begin with the same evidence instead of repeating the initial search.

09Summary

An IDoc is a structured, asynchronous SAP integration document. Its control record identifies the exchange, its data records carry the payload, and its status records provide the processing history. Effective support starts with WE02 or WE05, follows the earliest failure status, checks partner and interface configuration, and reprocesses only after the underlying cause is understood.