How to read a rejected EDIFACT message
- min read
- 8 min read
- Published
- Published
- Updated
- Updated
- Written for :
- EDI integrators, IT teams and order-management leads who receive rejections with no usable documentation.
Short answer
How do I identify the cause of a rejected EDIFACT message?
To identify the cause of an EDIFACT rejection, start from the raw message actually transmitted rather than how the integration tool displays it, then read the technical acknowledgement — a CONTRL, where one is sent, usually names the offending segment and data element. Compare that segment against the partner specification currently in force, then determine whether the gap comes from the mapping (the data exists but is misplaced or miscoded) or from the source data (the mapping is correct but receives a wrong value). Those two cases are fixed in different places.
Step 1 — Retrieve the raw message
How a message appears in an integration interface is a reconstruction. It almost always hides decisive detail: separators, empty elements, real lengths, encoding.
The only artefact that counts is the file actually transmitted. It is what the partner evaluated, and the only one on which a gap can be demonstrated.
Step 2 — Read the technical acknowledgement
Where the partner sends one, the technical acknowledgement (CONTRL in the EDIFACT world) states the level at which the error was detected: interchange, group, message, segment or data element.
A rejection at segment or element level is good news: it points at the exact spot. A rejection at interchange level suggests an envelope problem, exchange identifiers or overall structure instead.
Step 3 — Compare against the specification in force
An EDIFACT message can conform to the standard and still be refused, because each partner publishes a subset with its own obligations: required segments, mandated qualifiers, restricted lengths, closed code lists.
The question is never "is this message valid?" but "does this message conform to what this partner expects, in the version in force today?".
Step 4 — Isolate the offending segment
- Compare the last accepted message and the first rejected one, line by line. The gap is often single and tiny.
- Check qualifiers before values: a correct code in the wrong qualifier is the most mundane cause and the hardest to see.
- Check conditional segments: they become mandatory depending on context, and that context changes with transaction type.
- Look at empty elements transmitted explicitly, which are not equivalent to absent elements.
Step 5 — Separate a mapping error from a data error
If the expected value exists in the ERP but arrives misplaced, miscoded or truncated, the mapping is what needs fixing.
If the mapping faithfully carries a value that is already wrong upstream, fixing the mapping hides the defect: it will resurface on another flow. The fix belongs to the process producing the data.
This distinction determines who fixes it, where, and whether the problem will reappear elsewhere. It is the only genuinely useful conclusion of the analysis.
Where these rejections show up most
| Message | Role | Effect of a rejection |
|---|---|---|
| ORDERS | The purchase order, start of the chain. | The error propagates through to the invoice: the symptom appears far from its cause. |
| DESADV | The despatch advice, ahead of the goods. | Can physically block a goods receipt at the dock. |
| INVOIC | The invoice. | Direct cash effect: the payment clock does not start. |
| CONTRL | The technical acknowledgement. | Its absence removes all diagnosis: the message leaves with no usable response. |