IDoc status 61 — IDoc Status 61 Inbound Syntax Error

Status 61 is an inbound status and it is a terminal, closing status: processing despite syntax error. It applies when a syntax check performed during inbound function module processing found a discrepancy between the IDoc data and the segment definition being used, but processing continued anyway and the application document was created. The syntax error is logged but does not stop posting the way statuses 51 or 56 do. Because the wording contains syntax error it reads like a failure, but it sits alongside 53 and 51 as an end state where the application document usually already exists. The gap between the IDoc data and the definition may simply mean some fields never reached the posted document.

Ordered from most to least frequent, the underlying trigger is almost always a mismatch between what the IDoc carries and what the receiving system's segment definition or partner profile expects, not a hard data error.

Work from the status record outward before considering reprocessing.

Confirm first, from the status record or the linked object key, whether the application document already exists. If it exists and is complete, the fix belongs entirely on the definition side: activate or release the missing custom segment, correct the field length or domain causing the mismatch, and re-link the correct extended IDoc type in the partner profile so the next inbound IDoc parses cleanly. Do not reprocess the IDoc that already succeeded. If the document exists but is missing the data that triggered the syntax error, correct that document manually through its own maintenance transaction rather than through the IDoc, because reprocessing calls the creation logic again, not an update, and produces a second document. Reprocessing through BD87 is only appropriate in the rare case where the status record confirms the function module aborted before any commit and no document was created; in that case fix the segment or extension issue first and reprocess exactly once, then verify a single document resulted.

The reflex move is selecting the IDoc in BD87 and reprocessing because the phrase syntax error in the status text reads as a blocking failure comparable to status 51 or 56. In most cases 61 is not blocking; the inbound function module already committed the application document before or alongside logging the syntax error. Reprocessing calls the same creation logic again and produces a duplicate sales order, delivery, or accounting document, which then has to be manually reversed or deleted, turning a definition mismatch into a second incident.

The interface or middleware team owns the segment, extension, and partner profile configuration that caused the mismatch. The functional team owning the resulting document type owns verifying whether the posted document is complete and correcting it if fields were silently dropped. Development is pulled in only when a custom segment or user exit turns out to be the actual source of the discrepancy.

Monitoring dashboards that key off the word error in the status description frequently lump 61 in with genuine failures, inflating error counts and hiding that the document actually posted successfully. The status code alone does not tell whether the posted document is fully complete or is missing the field that caused the mismatch; only the plain-language status record text and a direct look at the document answer that. Extension segment gaps show up most often on custom or Z message types that were changed on one side and never re-tested end to end.