Overview
The APERAK (Application Error and Acknowledgment) message provides business-level feedback about received EDIFACT messages. While the CONTRL message handles syntax-level validation (confirming that data can be parsed according to EDIFACT rules), APERAK operates at the application layer — it reports whether the data makes sense in the business context and whether it could be processed by the receiving application.
Consider an INVOIC message that is syntactically perfect: all segments are in the correct order, mandatory elements are present, and data types are valid. The CONTRL will acknowledge it positively. However, if the invoice references a purchase order number that does not exist in the buyer's system, or the supplier's GLN is not registered as an approved vendor, those are application-level errors that APERAK is designed to report.
APERAK is particularly important in complex EDI environments where business rules vary by trading partner, product category, or transaction type. It provides a standardized way to communicate specific business validation failures back to the sender, enabling them to correct the data and retransmit without resorting to phone calls or emails for error resolution.
Message Structure
The APERAK message references the original message that triggered the error (by message type, reference number, and sender) and then details each error encountered. Errors are described using free-text descriptions and, where applicable, coded error identifiers. The message can report multiple errors from a single source message.
Key Segments
| Segment | Name | Purpose |
|---|---|---|
BGM | Beginning of Message | APERAK document number and function (notification of error, acknowledgment) |
DTM | Date/Time/Period | Date when the error was detected |
RFF | Reference | Reference to the original message that caused the error (message reference number, document number) |
NAD | Name and Address | Sender and recipient of the error report, and the original message sender |
ERC | Application Error Information | Coded error identification — the specific error code describing what went wrong |
FTX | Free Text | Human-readable description of the error, providing additional context |
RFF | Reference (in error detail) | Points to the specific document, segment, or data element that caused the error |
CONTRL vs. APERAK
Understanding the distinction between these two acknowledgment mechanisms is critical for EDI implementation:
| Aspect | CONTRL | APERAK |
|---|---|---|
| Validation level | Syntax (can the data be parsed?) | Application (does the data make business sense?) |
| Generated by | EDI translator / communication layer | Business application / ERP system |
| Timing | Immediately upon receipt | After business validation processing |
| Error examples | Missing mandatory segment, invalid character set | Unknown PO number, unregistered GLN, expired price |
| Message type | Service message (ISO 9735) | Standard EDIFACT message (UN/EDIFACT directory) |
Common Application Errors
The types of errors reported via APERAK span a wide range of business validation scenarios:
- Unknown reference: The message references a purchase order, contract, or other document that cannot be found in the receiver's system.
- Invalid party: A GLN or other party identifier in the NAD segment is not recognized or not authorized for this transaction type.
- Product not found: The GTIN or article number in LIN does not exist in the receiver's product master data.
- Price mismatch: The price in the invoice does not match the agreed price from the PRICAT or purchase order, exceeding allowed tolerance.
- Duplicate document: A message with the same document number has already been processed.
- Date validation failure: Dates fall outside acceptable ranges (e.g., a delivery date in the past, or an invoice date before the order date).
- Quantity discrepancy: Invoiced quantity exceeds the ordered or received quantity beyond the allowed tolerance.
Common Use Cases
- Invoice rejection feedback: When an incoming INVOIC fails business validation (wrong PO reference, price mismatch), the buyer's ERP sends an APERAK to the supplier explaining the rejection reason.
- Order processing errors: A supplier's system sends APERAK when an incoming ORDERS references discontinued products or requests quantities below minimum order requirements.
- Positive acknowledgment: Some trading partnerships use APERAK to confirm successful business processing — not just to report errors. The BGM function code distinguishes between error notifications and positive acknowledgments.
- Data quality improvement: Systematic analysis of APERAK errors helps identify recurring data quality issues (e.g., a supplier consistently using wrong GTINs), driving root-cause correction.
Example Snippet
UNH+1+APERAK:D:96A:UN:EAN008'
BGM+313+APERAK-2024-00012+9'
DTM+137:20240320:102'
RFF+ACE:1'
NAD+MS+5412345000013::9'
NAD+MR+4012345000010::9'
ERC+100'
FTX+AAO+++Purchase order PO-2024-99999 not found in system'
RFF+ON:PO-2024-99999'
UNT+9+1'Implementation Considerations
Integrate APERAK generation into your business application's validation workflow. After the EDI translator successfully parses a message (and sends a positive CONTRL), the message enters your ERP or business system for processing. If business validation fails, the system should automatically generate and queue an APERAK for transmission.
Define clear error codes that align with your trading partner agreements. While EDIFACT provides standard error code lists, many implementations use bilaterally agreed codes that are more specific to the business context. Document these codes in your implementation guidelines so that trading partners can programmatically interpret and act on them.
On the receiving side, implement automated processing of incoming APERAK messages. When your system receives an APERAK reporting errors in a message you sent, it should automatically flag the original transaction for review, display the error details to the appropriate user, and ideally suggest corrective actions based on the error code.