IDoc status 37 — IDoc Status 37 Added Incorrectly

Status 37 is an outbound-only status and it fires very early in the chain, at the point the IDoc record itself is being written to the database, before status 01 generation is considered clean and long before dispatch to a port. Where statuses like 26 or 29 indicate a syntax check or ALE service failure on an IDoc that otherwise exists in a coherent form, status 37 means the create step itself failed partway through, so the resulting IDoc can be structurally incomplete: a segment may be missing, duplicated, or built against the wrong definition. The control record often exists but the data record content cannot be trusted. It is one of the least common statuses in day-to-day monitoring, which is part of why it gets mishandled when it does appear.

Named causes ordered by frequency observed in support work.

Work from the IDoc outward to the definition, not from the definition down.

Do not attempt to dispatch a status 37 IDoc as it stands. First establish whether the IDoc type and segment definitions are actually consistent in the current system; if a segment change was not regenerated, regenerate the IDoc type before touching the failed record. Once the definitions are confirmed correct, the broken IDoc itself is normally not repairable in place because its content was written against a wrong or incomplete structure. The safer route is to mark the flawed IDoc as obsolete or delete it through the standard IDoc administration tools, then regenerate the outbound IDoc from the source application document, using the same trigger that originally created it: reissue the output type, rerun the change pointer, or re-execute the distribution program. Before regenerating, confirm the source document has not already been processed through an alternate path, since re-triggering output on a sales document, delivery, or master data change that was already handled manually elsewhere causes a duplicate downstream posting on the receiving side. Coordinate the reissue with the receiving system owner if the interface partner already flagged a missing or malformed message.

The reflex is to select the IDoc in the monitor and force it through outbound processing again, treating it like a communication failure. Because the underlying record is structurally wrong, this either fails again with a different status or, worse, succeeds in pushing a malformed message to the receiving system or subsystem, which may accept it and create incorrect master data, a document with missing line items, or a partner acknowledgment mismatch that surfaces days later as a much harder reconciliation problem.

This is a development or interface build problem first, not a functional master data issue, since it almost always traces back to an IDoc type or segment inconsistency, a custom exit, or a transport gap. Hand the specific IDoc number, the segment where content stops, and any related short dump to the ABAP or integration development team; involve the functional consultant only to confirm whether the source document needs to be reissued.

Status 37 is easy to mistake for a syntax check failure such as status 26 because both point at structural problems, but 26 implies the IDoc passed the add step and failed a later check, while 37 means the add itself did not complete cleanly. Standard IDoc monitoring alerts are frequently tuned around the common statuses like 51 or 29 and miss 37 entirely because it is rare, so these IDocs sit unnoticed unless someone runs a broad status query across the outbound queue.