IDoc status 29 — IDoc Status 29 Error in ALE Service

Status 29, Error in ALE service, is an outbound status only. It is set during the phase where the application document has already triggered IDoc generation and the ALE layer takes over to determine the receiving system, apply the distribution model, run segment and IDoc-type filtering, apply reduction, and execute any ALE outbound exits. If any of that fails, the IDoc is written with status 29 and processing stops there. It never reaches port determination, syntax check, or the communication layer, so status 29 problems are configuration or exit problems inside ALE distribution, not RFC or network problems.

Fix the ALE configuration or exit before touching the stuck IDoc. If the distribution model entry is missing or wrong, correct it in BD64 and verify the filter values match real data. If a reduction or field filter is stale, either update it to match the current segment structure or remove the filter if it is no longer needed. If a custom exit is failing, correct the exit logic and retest with WE19 using the same payload before reprocessing anything in production. Once the underlying cause is fixed, reprocess the IDoc from WE02 or BD87 using outbound reprocessing rather than recreating the source document. Do not recreate the sales order, delivery, or other source document to force a new IDoc, because the original document has already been posted in the source system and a second document creation duplicates the business transaction. Reprocessing status 29 replays only the ALE and communication steps, it does not touch the application document again, which is why it is the safe route once configuration is corrected.

The instinctive fix is to mass-reprocess every IDoc stuck at 29 immediately, assuming it is a transient glitch like a stuck queue. Because status 29 is a configuration or exit failure, not a timing issue, reprocessing without changing anything produces the identical error on every retry, and repeated reprocessing attempts clutter the monitor with duplicate status records that make root-cause analysis harder. Worse, if someone works around the block by recreating the source document instead of fixing ALE, the business transaction gets duplicated downstream once the configuration is eventually corrected and the original IDoc also reprocesses successfully.

This sits with the integration or ALE configuration team, since the root cause is almost always in the distribution model, filter setup, or an outbound exit rather than in the source application module. Hand over the IDoc number, the full status record text, and confirmation of whether other IDocs of the same message type are affected, since that scope detail tells the integration team whether this is a one-off data issue or a configuration regression.

Status 29 is often mistaken for a communication or RFC problem because it looks similar to later-stage outbound failures, but nothing has actually left the local system yet, so checking SM58 or the destination system wastes time. The status text can be terse when the failure originates in a custom exit, showing only a generic exception class rather than the real business reason, which pushes investigation toward ABAP debugging earlier than expected. A distribution model that looks correct for one receiver can still fail for a second receiver added later if the filter object type was not extended to include it.