IDoc status 65 — IDoc Status 65 Error in ALE Service

Status 65 is an inbound status. It is raised while the IDoc is still moving through the ALE service layer, the technical machinery that sits between the tRFC transport and the application inbound function module: distribution model check, segment filtering, IDoc type version conversion, and any ALE-level user exits. If any of these steps throws an error, the IDoc is parked at 65 and never reaches the point where an application posting is attempted. This distinguishes it clearly from statuses like 51, which mean the application function module ran and rejected the data. At 65, the application has not been called at all, so no partial document, no sales order, no material master change exists yet.

Because status 65 stops before any application posting, there is no document to reverse and no duplicate-posting risk from the IDoc's own data. The risk is different: reprocessing before the distribution model, partner profile, or version mismatch is corrected simply reproduces the same error on every retry, and if this IDoc is one of many queued behind a serialization group, retrying blindly can back up the whole group. Fix the actual configuration gap first: add or correct the BD64 model entry, align the filter object values, resolve the IDoc type version mismatch, or patch the failing exit. Once the underlying cause is confirmed fixed on a test IDoc or in a sandbox check, reprocess through BD87, selecting the affected IDoc or the full batch stuck at 65. Watch the resulting status; a clean run moves the IDoc to 53 or into application processing and possibly 51 if a genuine application error was hiding underneath the ALE fault.

The default reflex is to select every IDoc at status 65 in BD87 and mass-reprocess immediately, assuming it is a transient timing or lock issue. It is not; the ALE service failure is deterministic and configuration-driven, so the retry fails at exactly the same step every time. The visible cost is a flood of repeated failures in SM58 and SLG1 that obscures the original root cause, and on systems with serialization groups active, the retried IDocs can jam the queue further, delaying every IDoc behind them even after the real fix is eventually applied.

This is primarily an interface or Basis integration problem, since the fault lies in distribution model and partner profile configuration rather than business logic. Functional teams may need to confirm which filter values or organizational units should be valid, but the fix itself, correcting BD64 entries, partner profiles, or IDoc type versions, belongs to whoever owns ALE configuration. Hand over the IDoc number, the full status text, and the relevant distribution model entry when escalating.

Status 65 is frequently mistaken for an application data error because consultants jump straight to checking the business document fields, when the actual fault sits in technical ALE configuration that has nothing to do with the payload's business content. The status text is often generic and does not name the specific missing filter value, forcing a manual comparison between the distribution model and the IDoc's actual segment content. It can also appear intermittently for only some IDocs of a message type if the distribution model has multiple filter entries and only one combination is broken, which makes the fault look random until the filter values are checked systematically.