IDoc status 12 — IDoc Status 12 Dispatch OK

Status 12 belongs to the outbound leg of IDoc processing. It is set after the IDoc has been passed through the communication layer and the transactional RFC (or equivalent transport) call used to deliver it has returned without a technical error. In an ALE scenario between two SAP systems, this usually means the payload has been handed to the destination system's inbound queue. It is treated as a terminal, successful status in most outbound monitoring views and shows green in WE02 and WE05. The key limitation is scope: status 12 only certifies that the sending system's dispatch step worked. Anything that happens after the RFC call returns, on the receiving side or in an intermediate middleware layer, is invisible from this status alone.

Status 12 is not an error status, so the real diagnostic question is usually not 'why did this happen' but 'why is this IDoc stuck at 12 with no matching receipt' or 'why does the business partner say nothing arrived'. The common causes, in rough order of frequency, are listed below.

Work outward from the sender before assuming anything is wrong on the receiver.

Before touching anything, establish whether the IDoc actually arrived and was processed on the receiving side. If a matching inbound IDoc exists there in a successful status, or the underlying business document (order confirmation, delivery note, master data record) already exists on the partner system, the transmission worked and nothing further should be sent; the ticket is closed as a false alarm. If the receiving system has no trace of the message at all, the fix is not a technical IDoc reprocessing step, because status 12 already marks the technical dispatch as complete and there is no error segment to correct in the IDoc data itself. Instead, the resend has to happen at the business process level: re-trigger the output, re-run the distribution, or re-send the message from the point where it originates, after confirming the partner profile, port, and RFC destination are pointed correctly. Any resend must be logged and communicated to the receiving side so a duplicate arriving later is recognized and not posted twice.

The instinctive fix is to open BD87 and try to force the IDoc through again, treating status 12 like a stuck error status such as 30 or 01. It usually does not offer a reprocess action because the technical processing already completed successfully, so people instead recreate the source document or re-output it entirely. If the original transmission had, in fact, arrived and been processed on the receiving system, this produces a second IDoc, a second inbound posting, and a duplicate business document, an order, a delivery, a master record, on the partner side.

Basis or the interface team owns the RFC destination, port, and queue health checks. The functional or application team owns confirming with the receiving system or business partner whether the document actually arrived, and owns deciding whether a resend happens at the document level rather than the IDoc level. Escalate to the middleware team only when an intermediate integration layer sits between the two SAP systems.

The green display in WE02 and WE05 creates false confidence, since it reflects only the sender's leg of a multi-hop transmission. In scenarios with an intermediate middleware layer, status 12 can be a checkpoint rather than a finish line, while in direct ALE distribution between two SAP systems it often is the finish line, so the same status number means different things depending on the landscape. Teams that close incidents purely on seeing status 12 without checking the receiving side end up reopening the same issue days later when the partner reports missing data.