SAP IDoc Status Codes: Understand the Flow Before Memorizing

A sender IDoc at 03 and its matching receiver IDoc at 51 can both be telling the truth. The sender has handed its IDoc to tRFC; the receiver has recorded that the application document was not posted. Each status describes a different part of the flow on a separate local IDoc. To interpret the number, you need its system and direction.

This guide helps SAP learners and junior integration specialists read eight IDoc status codes and choose the next observation. It covers classic on-premise ALE with tRFC and direct inbound application processing in SAP S/4HANA® 2025 FPS01 software. The technical sources are SAP’s IDoc Interface/ALE documentation for ABAP® platform 2025 FPS01, version 202510.001, build 915. It is a focused learning guide, rather than an exhaustive status reference or an operational repair procedure.

Independent, unofficial guide by Kirill Markin, with a companion deck contributed by Open Study Contributor. AI assisted the explanations, original diagram, and exercises; technical facts were checked against the version-pinned SAP sources linked below. No live SAP system was tested. This material is not affiliated with, sponsored by, or endorsed by SAP SE or its affiliates.

First locate the status in the flow

An IDoc carries application data in segments. Its status information records processing and errors, and SAP documents that this information is transferred separately from the IDoc itself. Read the sender’s and receiver’s status records in their own context. See IDoc Structure.

In this guide, tRFC means transactional remote function call. It carries the IDoc between systems; the receiving application’s posting is a later stage. SAP’s Distribution Using Message Types describes those separate stages.

The diagram below follows one sender-to-receiver relationship. A-100 and B-900 are invented local IDoc labels, not a shared IDoc number. The arrows show processing boundaries. The status annotations are examples of evidence at those boundaries, not a required sequence.

SYSTEM A — SENDER
  Sending application
          |
  ALE outbound / dispatch
  Local outbound IDoc: A-100
    03: handed to tRFC
    12: Dispatch OK, if confirmed by dispatch check
          |
          v
       tRFC communication
          |
          | transmission to receiving system
          v
SYSTEM B — RECEIVER
  Local inbound IDoc: B-900, stored in database
          |
          | Application transfer
          |   64: ready for transfer
          |   63: transfer error
          v
  Direct inbound application processing
    51: application document not posted
    OR
    53: application document posted

The labels show possible status evidence, not steps
that every IDoc must pass through. Sender 03 and 12
do not report B-900’s application-posting result.

SAP’s Distribution Using Message Types separates communication from receiver storage and application posting. Transfer to the receiving application can happen immediately or later in background processing. An IDoc being stored at the receiver therefore does not, by itself, establish that its application document was posted.

Successful dispatch information is not automatically returned to the ALE communication layer. SAP describes a separate dispatch check that can establish 12. A successful transmission therefore does not require an automatic 03 → 12 update, and the sender’s status cannot tell you the receiver’s posting result. Likewise, 64, 63, 51, and 53 identify different receiver states; they are not one required progression. See Setting Dispatch Status to Dispatch OK.

Eight codes, with the next question beside each

Read these meanings within the flow and release stated above. TID means transaction ID: the identifier available in the tRFC-port status display at 03. The last column gives the next evidence to inspect. Corrective decisions need the actual error and system context.

Code	Direction	Meaning in this scope	Next observation
03	Outbound	The IDoc has been handed to tRFC.	Read the TID and inspect the corresponding tRFC-call state when receiver arrival is unclear.
12	Outbound	The documented dispatch check confirmed sending to the receiving SAP system: Dispatch OK.	Identify the receiver IDoc and inspect its application evidence if the question concerns posting.
64	Inbound	Ready for transfer to the application.	Establish whether transfer is immediate or handled in background processing.
63	Inbound	Error passing the IDoc to the application.	Read the actual error message and available status long text.
51	Inbound	The application document was not posted.	Read application error detail in status records and an application log if one exists.
53	Inbound	The application document was posted in this direct inbound context.	Inspect an already linked application object, if present, for a specific business-document question.
69	Inbound history	Identifies an edited IDoc.	Read its history and distinguish the edited IDoc from the retained original.
70	Inbound history	Identifies the retained original of an edited IDoc, saved as a new IDoc record.	Keep that original distinct from the edited record.

The definitions come from Check the tRFC Status for 03, Dispatch OK for 12, Posting IDocs in Parallel for 64, Error Handling for 51/63, Testing Inbound Processing for 51/53, and IDoc Display for 69/70, TIDs, and the conditional logs and object links. The inbound test documentation supplies the posting definitions used here; this guide uses those meanings for observation, without a test-tool procedure.

For 69 and 70, the learning task ends at recognizing editing history. Neither number alone supplies a reason to change or process anything.

Collect evidence before naming a cause

Start an observation note with system, client/context, local IDoc number, and direction. Then record the sender, recipient, and IDoc type from the control record. When comparing both sides, identify each local IDoc separately. IDoc Display describes the control, data, and status records available in the individual display.

For a selected IDoc, read the numeric status and its text, then the relevant status records and available long text. Traffic-light assignments can be customized, so a remembered color is a weak substitute for the code and message. See Edit Status Groups.

A useful observation note has room for the following:

System / client / local IDoc / direction:
Sender and recipient / IDoc type:
Relevant numeric status and message:
Available status long text:
TID and corresponding tRFC-call evidence, if relevant:
Receiver IDoc evidence, if identified:
Application log or linked object, if present:
Question still unanswered:

Use a bounded monitor selection. SAP’s Status Monitor for ALE Messages documents filters such as IDoc number, dates, status, partner system, and message type; it recommends change date, status, and message type together for performance. From a grouped result, inspect the individual IDoc to see its records. BD87 also supports manual processing, so an observation exercise must stay within display functions.

An application-log link depends on the application having written a log. An application object must already be linked to appear in the documented object relationships. If either link is missing, record that limit and inspect the available status records: they can also contain application errors. See IDoc Display and the inbound status explanation.

Worked examples: what the code establishes

These are constructed teaching cases, with invented labels and no claimed production results.

Sender 03, receiver not yet identified

You have outbound A-100 at 03. A colleague says, “The receiving document must already be posted.” Your receiver search has not identified a matching inbound IDoc.

What is established: A-100 reached the tRFC handoff. SAP explicitly describes a sender at 03 whose IDoc has not yet arrived at the receiving system because the tRFC call has not executed. The number supplies no receiver posting result.

Next observation: read the TID from the tRFC-port/03 status display. Inspect the corresponding tRFC-call state in SM58, using the relevant selection context. Record what you find and keep receiver identification as an open question. A search that found no matching receiver IDoc has not, by itself, established that nothing arrived. This observation combines Check the tRFC Status with the TID detail in IDoc Display.

Sender 12, receiver 51

For this case, the local records have been correlated: sender A-200 is at 12, while receiver B-400 is at 51.

What is established: dispatch was confirmed on the sender; the application document was not posted on the receiver. Those statements are compatible. Transport and application posting are separate stages, as described in Dispatch OK, Distribution Using Message Types, and Error Handling.

Next observation: inspect B-400’s error message in the status records and any available long text. Read the application log if one was written and is available. The number 51 alone does not identify a particular missing field, master-data issue, or other system-specific cause. Give the responsible operator the receiver identity, actual message, and context. The available displays are described in IDoc Display and the status monitor.

Receiver 64, with timing still unknown

Inbound B-500 is at 64. The only supplied description is “It’s waiting.”

What is established: the IDoc is ready for application transfer. SAP documents immediate and background transfer arrangements. This number alone does not establish that the wait is a fault. See Posting IDocs in Parallel and Transfer Control.

Next observation: establish whether this IDoc is expected to pass to the application immediately or through background processing. For background processing, identify the responsible owner and record the IDoc and timing context for them. This gives the owner evidence to assess the wait; the exercise ends before choosing or executing a job.

Receiver 53, with a broader business question

Inbound B-600 is at 53. Someone asks whether a particular business document now has the expected content.

What is established: the application document was posted in this direct inbound context. To check its expected content, you still need to inspect the particular application document.

Next observation: inspect an already linked application object if one is available, keeping the actual business question in view. The posting definition and object relationships support those two distinct observations. Status 53 alone is not a guarantee that every wider business objective has been completed.

Practice without the table

Answer from memory before reading the explanations. Include the system, direction, or next observation wherever the question needs it.

1. Sender A-700 has 03 and its correlated receiver B-800 has 51. Are the records contradictory?
2. Sender A-710 has 12. Does this establish receiver application posting? Where would you look next?
3. Which inbound code explicitly identifies an error passing the IDoc to the application: 51 or 63? What should you read before naming a cause?
4. Receiver B-810 has 64. What processing context is missing before you label the wait an error?
5. Receiver B-820 has 51 but no application-log link. What evidence can still contain application error detail?
6. Receiver B-830 has 53. What does that establish, and what could help answer a question about its particular application document?
7. You encounter inbound records at 69 and 70. Which identifies the edited IDoc, and which identifies the retained original?
8. A monitor shows a reassuring traffic-light color. What should you read before interpreting the processing result?

Answers and explanations

1. No. Sender 03 records tRFC handoff; receiver 51 records that the application document was not posted. They belong to different local IDocs. Inspect the receiver’s error evidence to investigate non-posting; the sender number does not explain its cause. Sources: tRFC status, Error Handling.
2. No. Status 12 confirms dispatch in the documented check. Inspect the receiver IDoc and its application evidence to establish posting. A sender dispatch result cannot supply that separate application result. Sources: Dispatch OK, Transfer Control.
3. 63. It identifies the error in passing the IDoc to the application. Status 51 identifies an application document that was not posted. Read the actual error message and available status long text before assigning a cause. Sources: Error Handling, status long text.
4. Immediate versus background transfer. Establish the arrangement and relevant process ownership. Status 64 means ready for transfer; it does not, by itself, prove a processing fault. Sources: background processing, Transfer Control.
5. The status records, including available long text. Application errors can be recorded there. An application-log link is conditional on the application writing a log, so its absence does not erase those other records. Sources: inbound error display, IDoc Display.
6. Application document posted, within this direct inbound scope. An already linked application object, if present, can help answer the specific document question. Keep the recorded posting result separate from a claim that all business objectives are complete. Sources: posting status, object relationships.
7. 69 identifies the edited IDoc; 70 identifies the retained original saved as a new IDoc record. Inspect the history and relationship between them. Recognition of either status is not a processing instruction. Source: IDoc Display.
8. The numeric status and its message. Traffic-light assignments can be customized. Use the individual status records and available long text when the question needs more detail. Sources: status groups, individual display and long text.

Practise the distinction as well as the number

Draw the two systems from memory, then place 03 and 12 beside the sender and 64, 63, 51, and 53 beside the receiver. Explain each label without drawing a mandatory chain through the codes. Keep 69/70 in a separate editing-history pair.

When you miss a question, identify the kind of miss. Forgetting “63 means error passing to application” needs a short definition prompt. Treating sender 12 as receiver posting needs a boundary question. Those are different retrieval tasks; a single large “explain all IDoc statuses” card hides the difference. The guide to making better flashcards gives more examples of focused front-and-back questions.

The companion English SAP IDoc status-code deck offers practice with these eight meanings, sender/receiver distinctions, and nondestructive next observations. All answers needed for the exercises above are already on this page.

Regular recall practice makes you produce an answer before checking it. Spaced review returns to that material across later sessions; research on retrieval practice and spacing supports their use for longer-term retention. Neither provides a guarantee of permanent memory or one fixed review schedule for everyone. Practise explaining the evidence boundary, then use system-specific documentation and the responsible operator’s judgment for actual corrective decisions.

SAP, SAP S/4HANA, and ABAP are trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.