IDoc status 60 — IDoc Status 60 Inbound Syntax Error

Status 60 sits on the inbound side. The IDoc has already arrived through the port (tRFC, file, or middleware) and a control record and data records exist in the database, but before the assigned posting function module runs, the system checks the IDoc's segments against the IDoc type's segment definition: mandatory segments present, field lengths respected, data types correct, segment nesting valid. If that check fails, the IDoc is frozen at 60. It never reaches the functional processing stage that would move it to a success status such as 53 or 64, or to a functional error status such as 51 or 56. Nothing has been posted. The IDoc is, in effect, structurally rejected before the application layer ever sees it.

Fix the structural mismatch before touching the failed IDoc itself. That means correcting the segment definition or its transport status, aligning the partner profile's IDoc type and extension with what the sender transmits, or fixing the source mapping so the payload includes the mandatory segment or respects the field length. Reproduce the corrected structure with WE19 against a copy of the failed IDoc to confirm the syntax check now passes before touching production data. Once the definition is fixed, reprocess the original failed IDoc through BD87 mass processing, or the process function from WE05 detail view. Because status 60 means no application document was ever created, reprocessing this specific IDoc carries no duplicate-posting risk on its own. The risk appears when the source system, seeing the interface error, has already resent the same business transaction as a new IDoc. Check for a second IDoc covering the same document number or reference before reprocessing the original, or the business document ends up created twice.

Reprocessing the IDoc through BD87 without touching the segment definition, partner profile, or upstream mapping simply reproduces the same syntax error, sometimes as a different status if the retry hits an inconsistent definition mid-transport and throws a runtime dump instead of a clean 60. A more damaging habit is editing the failed IDoc's data manually in WE19 to force it past the syntax check and resend it. That creates a posted document that no longer matches the record in the sending system, and the discrepancy surfaces later as a reconciliation problem that is much harder to trace back to its origin.

This is primarily an interface or Basis problem since it concerns IDoc type and segment definitions rather than business data content. Hand over the exact segment and field named in the error, the IDoc type and extension in use, and confirmation of whether the partner profile matches the sender's actual version. Loop in the sending system's technical team when the mismatch traces back to their mapping or a version they have not yet aligned.

The error text on a status 60 IDoc names the segment and field but rarely states which system's definition is out of date, so teams waste time patching the wrong side. Segment versions that differ across development, quality, and production because a transport for a custom segment was only partially moved can make the same interface fail in one environment and work in another, which looks like a data problem but is a transport gap. Status 60 is also frequently confused with status 56, a functional error raised inside the posting logic; 60 happens strictly before that logic is ever invoked.