IDoc status 31 — IDoc Status 31 Outbound Error No Further Processing

Status 31 applies only to outbound IDocs. It sits after generation (status 01) but signals that processing has been stopped due to an error, and the IDoc will not progress to being passed to the port (status 03) or dispatched further. It differs from the more specific technical failure points such as a syntax check error or an ALE service error, both of which are raised automatically by the standard IDoc layer at a known point in the pipeline. Status 31 is frequently set explicitly, by a user exit, BAdI, or custom program that decided, based on a business condition, that the IDoc should not go any further. Because the trigger is often custom code rather than a standard check, the reason is not always obvious from the status record alone.

Read the status record text and any linked application log entry first, since status 31 is almost never self-explanatory from the status code alone. Identify the specific business condition that the exit or program checked and failed, then correct the underlying data or configuration: the missing partner detail, the incomplete master record, the wrong filter setting. Because status 31 typically means the IDoc never reached the port and no data left the system, the safest reprocessing route is usually to regenerate the IDoc by rerunning the output or distribution trigger from the source document, rather than forcing the existing errored IDoc forward. Before doing that, confirm through the output control record on the source document (or equivalent output history) that no partial or duplicate message was already sent, particularly if the custom exit ran after the source document was already committed. Only after the data fix is in place and verified should reprocessing be triggered, and it should be re-run through the same process that originally failed, not a generic status override.

The reflex fix is to treat 31 like a routine technical glitch and force it through reprocessing (for example resetting status and rerunning via the standard reprocessing report) without reading why it was stopped. Since 31 usually reflects a deliberate business-rule rejection in custom code, bypassing it skips the check that exists for a reason. If the reprocessing path re-triggers output determination on the source document, this can generate a second, separate outbound message alongside whatever was already sent, producing duplicate deliveries or duplicate postings at the receiver. It also guarantees the same block reappears on the next run since the underlying data was never corrected.

This belongs to the interface or functional team that owns the outbound scenario, since the status is usually the product of custom validation logic tied to a business rule rather than a basis or transport-layer fault. Development involvement is needed to read the exit or BAdI code that raised the status. Hand over the IDoc number, the exact status record text, any linked application log entry, and the source document number.

The status text is sometimes generic, such as a pointer to check the log, which gets mistaken for a stalled but otherwise healthy IDoc rather than a deliberate stop. Teams used to standard syntax or port errors sometimes only check the technical layer and miss that custom exit code, not the ALE framework, produced the status. Mass reprocessing tools are occasionally configured to skip IDocs in status 31 on the assumption that it is non-recoverable, which can create a false sense that the issue was handled when it was simply excluded from the run.