# EDIFACT CONTRL: Syntax Acknowledgement Guide

> EDIFACT CONTRL explained: UCI, UCM, UCS and UCD segments, action codes 4, 7 and 8, syntax error codes, four live examples and how it maps to the X12 997.

<QuickAnswer>
EDIFACT CONTRL is the syntax and service report message, the equivalent of the X12 997. The receiver sends it back to say an interchange arrived and whether its syntax was accepted or rejected. UCI reports on the interchange, UCM on each message, and UCS and UCD pinpoint the segment and data element in error.
</QuickAnswer>

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](/guides/edi/edifact-aperak) or [ORDRSP](/guides/edi/edifact-ordrsp). Keeping that line clear is most of the battle with CONTRL.

This guide follows the [GS1 EANCOM 2002 CONTRL](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/contrl/toc.htm) 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](/guides/edi/edifact-orders).

<EDIGuideCTA
  badge="For EDIFACT CONTRL"
  transactionType="997"
  headline="Read a CONTRL rejection in seconds"
  body="Paste a CONTRL into the free EDIFACT inspector to see which interchange, message and segment it refers to. OrderSync processes EDIFACT, EANCOM and TRADACOMS alongside X12, PDF, CSV and email, and tracks acknowledgements for every message you send."
  secondaryHref="/edifact-inspector"
  secondaryLabel="Try the free EDIFACT inspector"
/>

## 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:

| CONTRL segment | Reports on | In the original interchange |
|---|---|---|
| `UCI` Interchange response | The interchange envelope | `UNA`, `UNB`, `UNZ` |
| `UCM` Message response | One message | `UNH` to `UNT` |
| `UCS` Segment error indication | One segment in that message | Any segment, by position |
| `UCD` Data element error indication | One data element in that segment | Simple, composite or component element |

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:

| Code | Meaning | Where |
|---|---|---|
| `8` | Interchange received. Only the envelope has been checked | UCI only |
| `7` | This level acknowledged; the next lower level is acknowledged unless explicitly rejected | UCI, UCM |
| `4` | This level and all lower levels rejected | UCI, UCM |
| `6` | UNB/UNZ rejected (GS1 code) | UCI only |

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.

<EdifactSample
  title="CONTRL acknowledging receipt of an interchange"
  description="UCI action 8: the interchange arrived and its UNB and UNZ were readable. Nothing is said about the messages inside."
  label="EANCOM CONTRL EAN004"
  raw="UNA:+.? '
UNB+UNOC:3+5098765000002:14+5012345000008:14+261011:0916+KVC000311'
UNH+1+CONTRL:D:3:UN:EAN004'
UCI+HLS000451+5012345000008:14+5098765000002:14+8'
UNT+3+1'
UNZ+1+KVC000311'"
/>

| Segment | What it says |
|---|---|
| `UNB+...+5098765000002:14+5012345000008:14+...` | The CONTRL travels from the supplier back to the buyer, in its own interchange |
| `UNH+1+CONTRL:D:3:UN:EAN004'` | CONTRL, syntax version 3 release, EANCOM version EAN004 |
| `UCI+HLS000451+...` | The control reference of the interchange being acknowledged, copied from its UNB |
| `5012345000008:14+5098765000002:14` | The original sender and recipient, copied in their original order. The buyer is still the sender here |
| `+8'` | Action 8: interchange received |

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.

<EdifactSample
  title="CONTRL accepting an interchange and its message"
  description="UCI action 7 for the interchange and UCM action 7 for message 1, an ORDERS D.01B EAN010."
  label="EANCOM CONTRL EAN004"
  raw="UNA:+.? '
UNB+UNOC:3+5098765000002:14+5012345000008:14+261011:0917+KVC000312'
UNH+1+CONTRL:D:3:UN:EAN004'
UCI+HLS000451+5012345000008:14+5098765000002:14+7'
UCM+1+ORDERS:D:01B:UN:EAN010+7'
UNT+4+1'
UNZ+1+KVC000312'"
/>

| Segment | What it says |
|---|---|
| `UCI+HLS000451+...+7'` | Interchange acknowledged |
| `UCM+1+ORDERS:D:01B:UN:EAN010+7'` | Message reference 1, with the message identifier copied from its `UNH`, acknowledged |

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.

<EdifactSample
  title="CONTRL rejecting one message with UCS and UCD detail"
  description="Interchange acknowledged, message 1 accepted, message 2 rejected with two located errors."
  label="EANCOM CONTRL EAN004"
  raw="UNA:+.? '
UNB+UNOC:3+5098765000002:14+5012345000008:14+261012:0905+KVC000318'
UNH+1+CONTRL:D:3:UN:EAN004'
UCI+HLS000452+5012345000008:14+5098765000002:14+7'
UCM+1+ORDERS:D:01B:UN:EAN010+7'
UCM+2+ORDERS:D:01B:UN:EAN010+4'
UCS+4'
UCD+12+2:2'
UCS+10'
UCD+39+4:1'
UNT+9+1'
UNZ+1+KVC000318'"
/>

| Segment | What it says |
|---|---|
| `UCM+2+ORDERS:D:01B:UN:EAN010+4'` | Message 2 and everything in it rejected |
| `UCS+4'` | The error is in segment 4 of that message, counting `UNH` as segment 1 |
| `UCD+12+2:2'` | Error 12 (invalid value) in data element position 2, component 2: the date inside `DTM+2:20261131:102` |
| `UCS+10'` | A second error, in segment 10 |
| `UCD+39+4:1'` | Error 39 (data element too long) in position 4, component 1: the item number in `LIN` |

**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.

<EdifactSample
  title="CONTRL rejecting a duplicate interchange"
  description="UCI action 4 with error 26 (duplicate detected), pointing at the control reference in UNB."
  label="EANCOM CONTRL EAN004"
  raw="UNA:+.? '
UNB+UNOC:3+5098765000002:14+5012345000008:14+261011:1102+KVC000315'
UNH+1+CONTRL:D:3:UN:EAN004'
UCI+HLS000451+5012345000008:14+5098765000002:14+4+26+UNB+6'
UNT+3+1'
UNZ+1+KVC000315'"
/>

| Element | What it says |
|---|---|
| `4` | Interchange and everything in it rejected. No business data will be processed |
| `26` | Syntax error: duplicate detected |
| `UNB` | The service segment where the problem lies |
| `6` | Data element position 6 in UNB, counting the tag as 1: the interchange control reference |

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.

| Segment | Name | Status | Repeats | Carries | X12 997 equivalent |
|---|---|---|---|---|---|
| UNH | Message header | M | 1 | `CONTRL:D:3:UN:EAN004` | ST |
| UCI | Interchange response | M | 1 | Original UNB reference, sender, recipient, action, error | TA1, AK9 |
| UCM (SG1) | Message response | C | 999999 | Original UNH reference and identifier, action, error | AK2, AK5 |
| UCS (SG2) | Segment error indication | C | 999 per message | Segment position, error | AK3 |
| UCD | Data element error indication | C | 99 per segment | Error, element and component position | AK4 |
| UNT | Message trailer | M | 1 | Segment count | SE |

## 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.

| Code | Meaning | Typical level |
|---|---|---|
| `2` | Syntax level or version not supported | UCI |
| `3` | Message version/release not supported (GS1) | UCM |
| `6` | Data segment missing or invalid (GS1) | UCS |
| `7` | Interchange recipient not actual recipient | UCI |
| `9` | Mandatory data element missing (GS1) | UCD |
| `12` | Invalid value | All |
| `13` | Missing | All |
| `14` | Value not supported in this position | All |
| `15` | Not supported in this position | All |
| `16` | Too many constituents | All |
| `17` | No agreement | UCI, UCM |
| `18` | Unspecified error | All |
| `19` | Invalid decimal notation | UCI, UCD |
| `21` | Invalid character(s) | All |
| `22` | Invalid service character(s) | All |
| `23` | Unknown interchange sender | UCI, UCM |
| `24` | Too old | UCI |
| `25` | Test indicator not supported | UCI, UCM |
| `26` | Duplicate detected | UCI, UCM |
| `28` | References do not match (for example UNH and UNT) | UCI, UCM |
| `29` | Control count does not match number of instances received | UCI, UCM |
| `35` | Too many segment repetitions | UCS |
| `36` | Too many segment group repetitions | UCS |
| `37` | Invalid type of character(s) | UCD |
| `38` | Missing digit in front of decimal sign | UCD |
| `39` | Data element too long | UCD |
| `40` | Data element too short | UCD |

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

| Concept | EDIFACT CONTRL | X12 997 |
|---|---|---|
| Interchange status | `UCI` action code | `TA1` (separate segment) and `AK9` for the group |
| Group status | Not used in EANCOM | `AK1` and `AK9` |
| Message status | `UCM` action 7 or 4 | `AK2` and `AK501` (A, E, R) |
| Segment error | `UCS` position and code | `AK3` |
| Element error | `UCD` position and code | `AK4` |
| "Accepted with errors" | No equivalent | `AK501` = E |
| Request for ack | `UNB` 0031 = 1 | `ISA14` (for TA1); 997 by agreement |

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](/guides/edi/997-functional-acknowledgment) for the X12 side.

## CONTRL vs APERAK vs ORDRSP

| Message | Answers | Generated by | X12 equivalent |
|---|---|---|---|
| CONTRL | Did the interchange arrive, and is the syntax valid? | EDI translator | [997](/guides/edi/997-functional-acknowledgment) |
| [APERAK](/guides/edi/edifact-aperak) | Did the receiving application accept the message's content? | Business application | [824](/guides/edi/824-application-advice) |
| [ORDRSP](/guides/edi/edifact-ordrsp) | Will the supplier fulfil the order, and on what terms? | Order management | 855 |

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](/guides/edi/edifact) 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](/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](/guides/edi/edifact)**: syntax, envelopes and the full X12 mapping
- **[EDIFACT APERAK](/guides/edi/edifact-aperak)**: application-level errors and acknowledgements
- **[EDIFACT ORDERS](/guides/edi/edifact-orders)**: the interchange acknowledged in these examples
- **[EDIFACT ORDRSP](/guides/edi/edifact-ordrsp)**: the business response to an order
- **[EDIFACT message types](/guides/edi/edifact-message-types)**: every EDIFACT message and its X12 equivalent
- **[EDI 997 functional acknowledgment](/guides/edi/997-functional-acknowledgment)**: the X12 counterpart

## Sources

- [EANCOM 2002 S3: CONTRL syntax and service report message](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/contrl/toc.htm), GS1
- [Syntax and service report message CONTRL](https://unece.org/sites/default/files/datastore/fileadmin/DAM/trade/untdid/download/r1186.pdf), UNECE
- [EDIFACT CONTRL acknowledgments and error codes](https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-edifact-contrl-acknowledgment), Microsoft Learn

Paste any CONTRL into the free [EDIFACT inspector](/edifact-inspector) to see which interchange and message it refers to.