Lesson 2 of 6
Inbound errors: 51, 56, 60, 64 and friends
9 min
Listen to this lesson
Inbound errors are the ones that reach the business fastest, because an inbound IDoc that does not post means no sales order, no order confirmation on a purchase order, no inbound delivery or no supplier invoice. Each error status points to a different layer, and knowing the layer cuts the investigation from hours to minutes.
Status 51: application document not posted
Status 51 is the most common inbound error and the most misread, because it says only that the application refused the IDoc. The reason is in the status message. Typical causes are master data (an unknown material or customer number), business rules (a blocked purchase order item, a closed posting period) or missing customizing (a tax code conversion, a confirmation control key). The fix is almost never in the IDoc itself.
Contoso example: on day two of hypercare, an inbound ORDRSP from Lakeside Components for purchase order 4500002210 sits in status 51. The long text says the confirmation control key is not maintained for item 10. Lakeside's 855 is fine; the buyer created the PO item without a confirmation control key, so SAP has nowhere to record the confirmed date and quantity. The fix is to maintain key 0001 on the PO item and reprocess the IDoc, not to edit the IDoc.
Status 56: IDoc with errors added
Status 56 means the IDoc was saved but SAP could not find how to process it. The classic cause is a missing or wrong inbound partner profile in WE20: there is no entry for the sender's partner number, partner type (LI for a supplier, KU for a customer, LS for a logical system) and message type, or the partner is inactive. A mismatch between what middleware writes into the control record and what WE20 contains has the same effect: Lakeside is maintained as supplier 17300001 with partner type LI in WE20, but the middleware writes partner type LS or a different partner number into the control record.
At Contoso, 56 appeared in CMQ after a client refresh for regression testing: the refresh copied production data into client 100, and nobody restored the test partner profiles. Every Lakeside invoice from the XQ1 test mapping landed in 56 until Theo's team reapplied the partner profiles from the test-system checklist.
Statuses 60 and 64: syntax and waiting
Status 60 (error during syntax check of IDoc, inbound) means the data records break the structure of the basic type or extension: a segment that does not exist in the type, segments in the wrong order, or a segment repeated more often than allowed. It is nearly always a middleware mapping error or an extension mismatch, for example a new Z1 segment sent before the extension is assigned in CMP. Status 61 (processing despite syntax error) appears when the partner profile tells SAP to continue despite syntax errors, which is a setting to avoid.
Status 64 is not an error. The IDoc is ready to pass to the application and is waiting, usually because the partner profile says Trigger by background program and a job running report RBDAPP01 processes the waiting IDocs. Status 64 becomes a problem only when the job is missing, failing, or too infrequent for the business. Also check for short dumps (ST22) and lack of free work processes if 64 IDocs pile up with immediate processing.
The rest of the inbound family
| Status | Meaning | First thing to check |
|---|---|---|
| 52 | Application document not fully posted | Which items failed; usually a partial master data problem |
| 63 | Error passing IDoc to application | Process code and function module assignment, authorization of the processing user |
| 65 | Error in ALE service | ALE settings such as the distribution model or conversion rules |
| 66 | IDoc is waiting for predecessor IDoc (serialization) | The earlier IDoc in the serialization group; it must post first |
| 68 | Error, no further processing | Who set it and why; the IDoc was deliberately closed, often by setting the deletion flag |
| 69 / 70 | IDoc was edited / original of an edited IDoc | Who edited what, and whether the edit was approved |
Other inbound statuses you will meet in production.
What would you do?
Ana in accounts payable reports that a Lakeside invoice for PO 4500002210 never appeared. In CMP you find its INVOIC IDoc in status 51 with the message that no tax code could be determined for the partner's tax data. What do you do?
Check your understanding · not graded
Lesson check
1. An inbound INVOIC from a new supplier lands in status 56. What is the most likely cause?
2. Inbound IDocs pile up in status 64 after go-live. Which check comes first?
3. Which status indicates the data records do not match the inbound IDoc type definition?
4. A status 51 ORDRSP says the confirmation control key is missing on the PO item. Who should fix what?