IDoc status 62 — IDoc Status 62 Passed to Application

Status 62 is an inbound status. It records that the inbound processing program has called the application layer, meaning the function module or BAPI responsible for creating the target business object (sales order, material document, invoice, and so on) has been invoked with the IDoc data. What it does not confirm is the outcome of that call. A healthy IDoc moves through this point in a fraction of a second and lands on a final status, either 53 (successfully posted) or 51 (application error, data rejected with a message). An IDoc that is visibly sitting at 62 has stopped between the call and the status write-back, which is not the normal path and always points to an interruption somewhere in that window rather than a business data problem in the IDoc itself.

The essential step before any reprocessing is confirming whether the target application document already exists. Because status 62 marks the moment the posting call was made, the database write may have committed even though the status record never got updated. Check the application side directly: search for a sales order, material document, or accounting document with the same reference data, external number, or purchase order number carried in the IDoc segments. If the document exists, do not reprocess through BD87; correct the IDoc status manually to reflect that it already posted and link the document number into the IDoc for traceability. If the document does not exist, and the underlying cause identified in the inspection step has been resolved (a hung process cleared, a lock released, a queue restarted), reprocessing through BD87 is appropriate. Reprocess one IDoc at a time when working through a batch of 62 entries rather than mass-reprocessing, since a systemic cause can mean some of them did post and some did not.

Reprocessing immediately with BD87, treating 62 like a routine retry candidate the way status 64 or 51 usually is. Because 62 sits after the posting call was already made, blind reprocessing risks calling the posting function module a second time on data that already created a document the first time around, producing a duplicate sales order, duplicate material movement, or duplicate accounting entry. Unlike status 51, where the application explicitly rejected the data and nothing was created, status 62 gives no such assurance either way.

Basis or the interface support team investigates first, since the cause sits in the technical layer: dumps, locks, update tasks, or RFC queues. Once the technical cause is identified, the functional team for the target document type must confirm whether the application object was actually created before anyone touches the status or reprocesses the IDoc. Neither team should act alone on a stuck 62.

Monitoring dashboards frequently bucket status 62 with genuine error statuses because it is not 53, which overstates urgency and encourages exactly the reflex reprocessing that causes duplicates. The status also gives no indication by itself of whether posting succeeded, so relying on the status text alone without checking the application side is a guaranteed source of wrong decisions. A pile of 62 entries appearing together is often mistaken for a batch of bad IDocs when the real cause is a single systemic event, such as a database restart or a killed job, that interrupted several postings at the same moment.