Overview
The CONTRL message is a special-purpose EDIFACT message that serves as a syntax-level acknowledgment. Unlike business messages such as INVOIC or ORDERS, the CONTRL is a "service message" defined in the EDIFACT syntax rules (ISO 9735) rather than in the EDIFACT message directory. Its purpose is to confirm that an interchange was received and to report whether the interchange, its functional groups, and individual messages could be parsed correctly according to EDIFACT syntax rules.
The CONTRL operates at the technical infrastructure level, not the business level. A positive CONTRL acknowledgment means the interchange was syntactically valid and could be read by the receiving system — it does not mean the business content was understood, accepted, or processed. For business-level acknowledgment and error reporting, the APERAK message is used instead.
CONTRL is fundamental to reliable EDI operations. Without it, the sender has no confirmation that their data was received and readable. Many trading partner agreements mandate CONTRL generation for every received interchange, and monitoring systems track outstanding CONTRL responses to detect communication failures or processing problems.
Message Structure
The CONTRL message has a unique structure compared to standard business messages. It references the original interchange (by interchange reference from UNB), and for each functional group and message within that interchange, it provides an acceptance or rejection status. When rejecting, it includes error codes identifying the specific syntax violation.
Key Segments
| Segment | Name | Purpose |
|---|---|---|
UNH | Message Header | Identifies this as a CONTRL message |
UCI | Interchange Response | References the original interchange (sender, recipient, reference number) and gives overall acceptance/rejection status |
UCF | Functional Group Response | References a specific functional group within the interchange and its acceptance/rejection status |
UCM | Message/Package Response | References a specific message within a group and its acceptance/rejection status |
UCS | Segment Error Indication | Identifies the position and nature of a syntax error within a rejected message |
UCD | Data Element Error Indication | Pinpoints the specific data element within a segment that caused the error |
UNT | Message Trailer | Segment count and message reference |
Response Codes
The UCI segment carries an action code that summarises the overall result:
- 4 — Accepted: The interchange was received and parsed successfully. All messages are syntactically valid.
- 7 — Rejected: The interchange contained syntax errors and could not be processed. The specific errors are detailed in subsequent UCF, UCM, UCS, and UCD segments.
- 8 — Received, acknowledgment to follow: A preliminary acknowledgment indicating the interchange was received; a final acceptance or rejection will follow after full validation.
Common Syntax Error Codes
When reporting errors, the UCS and UCD segments use standardised error codes:
- 12 — Invalid value: A data element contains a value that is not in the allowed code list.
- 13 — Missing: A mandatory segment, data element, or composite is absent.
- 14 — Value not supported: The value is valid per the standard but not supported by this implementation.
- 15 — Not supported in this position: The segment appears in an unexpected location in the message.
- 16 — Too many occurrences: A segment or group exceeds the maximum repetition count defined in the message specification.
- 26 — Invalid decimal notation: A numeric data element uses incorrect decimal notation.
- 35 — Invalid character: A data element contains characters not permitted by the syntax level in use.
Common Use Cases
- Standard acknowledgment flow: Every received interchange triggers an automatic CONTRL response back to the sender, confirming receipt and syntactic validity within the agreed timeframe.
- Error notification: When an interchange cannot be parsed (missing mandatory segments, invalid syntax characters, malformed envelopes), the CONTRL reports the specific errors to enable the sender to correct and retransmit.
- Communication monitoring: EDI operations teams monitor CONTRL responses to verify that transmissions are being received. Missing or delayed CONTRLs trigger alerts for investigation.
- SLA compliance: Trading partner agreements often define response time requirements for CONTRL (e.g., within 4 hours of receipt). Monitoring CONTRL timing ensures compliance.
Example Snippet
UNH+1+CONTRL:D:96A:UN'
UCI+00000001+5412345000013:14+4012345000010:14+4'
UCM+1+INVOIC:D:96A:UN:EAN008+4'
UNT+4+1'This example shows a positive acknowledgment: the interchange with reference 00000001, sent from GLN 5412345000013 to GLN 4012345000010, was accepted (code 4). The single INVOIC message within it was also accepted.
Implementation Considerations
CONTRL generation should be automated in your EDI platform. Configure your translator to produce a CONTRL for every received interchange immediately after parsing, before any business-level processing occurs. This ensures that even if business processing fails, the sender knows the data was received.
Be careful to distinguish between CONTRL and APERAK in your implementation. CONTRL reports only on syntax — can the data be parsed according to EDIFACT rules? APERAK reports on business content — do the values make sense in the application context? A message can pass CONTRL validation (syntactically correct) but fail APERAK validation (e.g., references an unknown purchase order number).
When your system receives a negative CONTRL (rejection), implement automated alerting and queue the failed interchange for investigation. The error codes in UCS/UCD segments should be logged with sufficient context (original interchange reference, sender, timestamp) to enable efficient troubleshooting.