EDIFACT CONTRL: Syntax Acknowledgement Guide

CONTRL answers one question: did my file get there, and could the other side read it? It says nothing about whether the order makes commercial sense, whether the price is right or whether the product exists. Those are application questions, and they come back in APERAK or ORDRSP. Keeping that line clear is most of the battle with CONTRL.

This guide follows the GS1 EANCOM 2002 CONTRL specification (subset version EAN004, syntax version 3), which is what most UK and European retail partners use. The examples acknowledge the fictional order interchange from the ORDERS guide.

What is an EDIFACT CONTRL message?

CONTRL (syntax and service report) is the UN/EDIFACT message that acknowledges or rejects a received interchange, and the messages in it, at syntax level. The receiver generates it, usually from its EDI translator, and sends it back to the sender of the original interchange.

A sender asks for a CONTRL by setting the acknowledgement request (data element 0031) in its UNB to 1. In an ORDERS interchange that looks like this, with the 1 in the ninth data element:

UNB+UNOC:3+5012345000008:14+5098765000002:14+261011:0915+HLS000451++ORDERS++1'

GS1 sets out several rules that shape every CONTRL:

• CONTRL is only sent where the recipient supports it, as agreed in the interchange agreement. If the sender requests one in UNB, it must be able to receive it.
• A CONTRL always travels in its own interchange. Never bundle it with business messages.
• One CONTRL reports on one interchange. It cannot cover several, or parts of several.
• At most two CONTRLs per interchange: an optional "received" acknowledgement, and the result of the full syntax check.
• Nothing is ever sent in reply to a CONTRL. Errors in a CONTRL are reported by other means, such as email or phone.
• EANCOM does not use functional groups, so the UN segment for group responses (UCF) does not appear.

The four reporting levels

CONTRL is built from four segments, each pointing at a different part of the original interchange:

Each UCM can be followed by repeating UCS and UCD pairs, one for each error found. The levels nest: you cannot report a segment error without first identifying the message it is in.

Action codes: received, accepted, rejected

The action code (data element 0083) sits in UCI and UCM. EANCOM allows these:

GS1 notes that codes 4 and 7 are only used after a complete check of the interchange, and code 8 only to acknowledge receipt. Not every translator follows those definitions to the letter: Microsoft's Azure Logic Apps documentation, for example, describes 8 as "accepted" and 7 as "accepted with some messages rejected". When a partner's CONTRL reads oddly, ask which translator generated it.

Example 1: interchange received

The supplier, Kestrel Valley Homeware, has received Harbour Lane Stores' order interchange HLS000451 and checked the envelope. This is the minimal CONTRL: three segments inside the message.

The sender and recipient in UCI are copied from the original UNB, not swapped. This is the detail people get wrong most often when building CONTRL by hand.

Example 2: interchange and message accepted

After the full syntax check the supplier confirms the interchange and its one ORDERS message.

Because action 7 at UCI level means "lower levels acknowledged unless explicitly rejected", a partner may send only the UCI line and leave out UCM for accepted messages. Both forms are valid.

Example 3: one message rejected with segment and element errors

Interchange HLS000452 contains two orders. Message 1 is fine. Message 2 has an impossible delivery date (31 November) in its fourth segment, and a 15-digit item number in its tenth segment, longer than any GTIN.

How the positions are counted. UCS counts segments from UNH as 1. In UCD (and in the element part of UCI and UCM), the segment tag itself is position 1, so the first data element after the tag is position 2. In a LIN+1++509876510001612:SRV segment, LIN is 1, the line number 2, the empty action code 3, and the item composite 4. The component number counts within the composite from 1.

To report a missing segment, UCS gives the position of the last segment processed before the one that should have been there, with error 13. GS1's own example rejects an INVOIC with UCS+3+13': a mandatory segment expected after segment 3 is missing.

Example 4: whole interchange rejected as a duplicate

The buyer's system resent HLS000451 after a timeout. The supplier's translator has already processed that control reference, so it rejects the second copy at interchange level.

Duplicate rejections are the main reason to keep UNB control references unique and never reuse them on a resend. If you resend deliberately, use a new reference.

CONTRL segment reference

Status and repeats follow the EANCOM 2002 structure chart. M is mandatory, C conditional.

Syntax error codes (data element 0085)

These are the values EANCOM allows. The UN/EDIFACT syntax defines more; not every code is valid at every level.

GS1 strongly discourages general codes such as 18 when a precise one exists. If you receive a CONTRL full of 18s, ask the partner for the underlying error.

CONTRL vs the X12 997

Two differences matter when you run both standards. CONTRL has no "accepted with errors": a message is acknowledged or rejected. And X12 acknowledges at functional group level (GS), which EANCOM does not use. See the EDI 997 guide for the X12 side.

CONTRL vs APERAK vs ORDRSP

An order can pass CONTRL and still fail in APERAK, for example when the syntax is perfect but the delivery point GLN is unknown.

Syntax version 3 vs version 4

EANCOM 2002 uses syntax version 3, where CONTRL is identified as CONTRL:D:3:UN:EAN004. Partners on syntax version 4 identify it as CONTRL:4:1:UN and may use additional segments and codes, such as the data element occurrence in UCD. If a partner sends a version you do not expect, the EDIFACT explained guide covers how the UNB syntax identifier works.

Common CONTRL errors and fixes

• Swapping sender and recipient in UCI. UCI copies the original UNB sender and recipient as they were. Your own ID goes in the CONTRL's UNB, not in UCI as sender.
• Sending CONTRL inside a business interchange. It must be its own interchange.
• Acknowledging a CONTRL. Never. Two systems that both do this loop forever.
• Positions off by one. UCS counts from UNH as 1. UCD counts the segment tag as 1.
• Treating CONTRL acceptance as order acceptance. Action 7 means "readable", not "agreed". Wait for ORDRSP or APERAK where the partner sends them.
• Not monitoring missing CONTRLs. If you requested one and nothing arrives within the agreed time, the interchange may never have been delivered. Chase it before the delivery date, not after.
• Copying broken data. GS1 notes that if the original UNH or UNB data is itself invalid, a valid CONTRL cannot be built. Report that error by other means.

Testing checklist

1. Agree in the interchange agreement whether CONTRL is used, in which direction, and how quickly it should arrive.
2. Confirm syntax version (3 or 4) and EANCOM version (EAN004 in EANCOM 2002).
3. Confirm whether the partner sends UCM lines for accepted messages or only for rejected ones.
4. Send a valid test interchange and check UCI copies your reference, sender and recipient exactly.
5. Send a deliberately broken message (bad date, overlong field, wrong segment count) and check the rejection points at the right position.
6. Resend an interchange with the same control reference and check you get error 26.
7. Paste each CONTRL into the EDIFACT inspector and confirm the references line up.

OrderSync tracks every outbound interchange against its CONTRL, so a missing or rejected acknowledgement shows up as an exception the same day, not as a missed delivery.

Frequently Asked Questions

What is a CONTRL message in EDIFACT?

CONTRL is the syntax and service report message. The receiver of an interchange sends it to the sender to confirm receipt and report whether the interchange and its messages passed the syntax check. It is the EDIFACT equivalent of the X12 997 functional acknowledgment.

What is the difference between CONTRL and APERAK?

CONTRL checks syntax and is generated by the EDI translator. APERAK checks business content and is generated by the receiving application. A message can pass CONTRL and still be rejected in APERAK because, for example, the order number is unknown.

What do UCI action codes 4, 7 and 8 mean?

8 means the interchange was received and its envelope checked. 7 means the interchange was acknowledged after a full syntax check, with lower levels acknowledged unless rejected. 4 means the interchange and everything in it is rejected.

How do I request a CONTRL?

Set the acknowledgement request, data element 0031 in UNB, to 1. The recipient must have agreed to send CONTRL, and you must be able to receive it.

Do I send a CONTRL in response to a CONTRL?

No. GS1 and the UN/EDIFACT rules say no CONTRL, or any other message, is sent in response to a CONTRL. Errors in a received CONTRL are reported by other means.

Is CONTRL the same as the X12 997?

It does the same job. The main differences: CONTRL has no "accepted with errors" status, EANCOM does not acknowledge functional groups, and CONTRL reports interchange status in UCI where X12 uses a separate TA1.

What does UCS+4 mean?

UCS identifies a segment in error by its position in the message, counting UNH as 1. UCS+4 means the fourth segment of the referenced message. A following UCD gives the element and the error code.

Related guides

• EDIFACT explained: syntax, envelopes and the full X12 mapping
• EDIFACT APERAK: application-level errors and acknowledgements
• EDIFACT ORDERS: the interchange acknowledged in these examples
• EDIFACT ORDRSP: the business response to an order
• EDIFACT message types: every EDIFACT message and its X12 equivalent
• EDI 997 functional acknowledgment: the X12 counterpart

Sources

• EANCOM 2002 S3: CONTRL syntax and service report message, GS1
• Syntax and service report message CONTRL, UNECE
• EDIFACT CONTRL acknowledgments and error codes, Microsoft Learn

Paste any CONTRL into the free EDIFACT inspector to see which interchange and message it refers to.