IDoc status 04 — IDoc Status 04 Control Record Rejected By EDI Subsystem

Status 04 is an outbound error. It follows status 03, meaning SAP successfully handed the IDoc data to the communication port, but the external EDI subsystem or middleware layer then examined the control record and rejected it before attempting any translation or mapping. Processing stops here on the SAP side because the rejection is reported back into the status record, and the IDoc effectively never got past the gatekeeper on the receiving system. This is distinct from a failure to transmit at all; the file or RFC call reached the subsystem, but something in the header fields, sender/receiver identifiers, message type, or test indicator failed the subsystem's own validation before content processing began.

Identify and correct the control record mismatch first, whether that means aligning WE20 partner profile settings with the subsystem's configuration, correcting the port or RFC destination in WE21, or coordinating a mapping fix with the middleware team. Because the IDoc never reached translation, nothing was posted or delivered downstream, so reprocessing generally carries no duplicate-posting risk on the receiving business system, unlike inbound statuses that stop after partial posting. The risk instead is duplicate transmission: check whether the subsystem or an automated retry already resent the file before assuming a clean slate. Once the underlying configuration is corrected, reprocess through BD87, selecting the affected IDocs and triggering outbound processing again. For a single problem IDoc used to prove the fix, WE19 can regenerate a test transmission, but production volumes should go through BD87 or the standard reprocessing job so the audit trail in the status record stays intact.

Reprocessing the IDoc through BD87 without touching the partner profile or port configuration sends the identical faulty control record back to the same subsystem, which rejects it again with the same status 04. Because a control record mismatch usually affects every IDoc on that message type and partner combination, mass reprocessing the whole error queue multiplies the same rejection across dozens or hundreds of documents instead of fixing one. On some middleware platforms repeated rejected deliveries also trip retry limits or error thresholds, which then blocks legitimate traffic on the same channel.

Shared between the SAP interface or basis team and the EDI subsystem or middleware team, since the fix can land on either side of the boundary. SAP side owns the partner profile and port definition; the middleware or EDI translator team owns their partner agreement and mapping configuration. Hand over the exact control record values, sender, receiver, message type, IDoc type, and test indicator, along with the subsystem's raw rejection text.

Status 03 reads as success and status 04 as the next step, which leads people to assume the IDoc was delivered when in fact it was bounced immediately afterward; the two statuses sit right next to each other in the flow but mean opposite outcomes. The quality of the error text depends entirely on what the subsystem chooses to report back, and some middleware configurations return a generic rejection code with no readable detail, forcing a manual cross-check against the middleware's own log rather than the IDoc status screen alone. Status 04 is also easy to confuse with status 02 (failed before reaching the port) or status 05 (failed during translation, meaning it did get past control checks), and picking the wrong one to investigate wastes time on the wrong layer.