A CONTRL tells you your order file was readable. APERAK tells you whether the system behind it could actually use it. The delivery point GLN might not exist in the buyer's master data, the GTIN might not be on your price file, or the invoice might quote an order that was never placed. None of those are syntax errors, so CONTRL passes them. APERAK is where they surface.
This guide follows the GS1 EANCOM 2002 APERAK layout (subset version EAN004, directory D.01B). The examples use the same fictional trading partners as the ORDERS and INVOIC guides.
What is an EDIFACT APERAK?
APERAK (application error and acknowledgement) is the UN/EDIFACT message that the receiving application sends back to the sender of a message, either to confirm the application received and processed it, or to report errors found while processing it. It works on one business document at a time: an order, a despatch advice, an invoice.
GS1's principles for APERAK are short and worth knowing before you build anything:
- It comes from the application, not the translator. The EDI translator checks syntax and answers with CONTRL. APERAK is generated after the message has reached the ERP, warehouse or finance system.
- It never acknowledges an interchange. That is CONTRL's job.
- One APERAK covers one message. You cannot acknowledge two orders in one APERAK.
- Name the business parties, not the mailbox. The
NADsegments repeat the buyer and supplier from the original document, not the interchange sender and recipient inUNB.
Where APERAK sits in the flow
Sender Receiver
| ORDERS interchange ------------------> EDI translator
| <------------------- CONTRL (syntax: readable?)
| |
| v
| ERP / order system
| <------------------- APERAK (content: usable?)
| <------------------- ORDRSP (business: will we supply?)
APERAK can follow any business message. In UK and European retail it is most often seen in two places: suppliers receiving APERAK from retailers against their DESADV and INVOIC, and retailers receiving APERAK from suppliers against ORDERS. Which documents get one, and how quickly, is set in the trading partner agreement.
Example 1: acknowledging an order
Kestrel Valley Homeware's order system has loaded Harbour Lane Stores' order HL-PO-88231 without problems. It confirms that with an APERAK containing no errors, the same pattern as GS1's own first example.
APERAK confirming an order was processed
BGM function 6 (confirmation): the application received and loaded order HL-PO-88231. No ERC segments, because there are no errors.
APERAK · Application error and acknowledgement · ref 1
- Document
- 305
- Document number
- KV-AP-10233
- Message function
- Confirmation
- Document/message date/time
- 2026-10-11 09:40
- Reference date/time
- 2026-10-11
- Order number (buyer)
- HL-PO-88231
Parties
| Role | Identifier | Name and address |
|---|---|---|
| Buyer BY | 5012345000008GS1 (GLN) | - |
| Supplier SU | 5098765000002GS1 (GLN) | - |
Interchange (UNB)
- Sender
- 5098765000002GS1 GLN
- Recipient
- 5012345000008GS1 GLN
- Prepared
- 2026-10-11 09:40
- Control reference
- KVA000201
- Syntax
- UNOC version 3
- Messages
- 1
| Segment | What it says |
|---|---|
BGM+305+KV-AP-10233+6' | Document 305 (application error and acknowledgement), APERAK number KV-AP-10233, function 6 (confirmation) |
DTM+137:202610110940:203' | When the APERAK was created: 09:40 on 11 October 2026 |
RFF+ON:HL-PO-88231' | The document acknowledged: buyer's order HL-PO-88231 |
DTM+171:20261011:102' | The date of that document |
NAD+BY / NAD+SU | The parties named in the order |
The number in BGM is the APERAK's own number. GS1 is explicit that it is not the number of the document being acknowledged; that goes in RFF.
Example 2: application errors on an order
A second order, HL-PO-88294, fails to load. Its delivery point GLN is not set up in the supplier's customer master, and line 3 carries a GTIN the supplier does not sell. The supplier rejects the order and reports both errors, the second one pointed at the exact order line.
APERAK rejecting an order with two application errors
BGM function 27 (not accepted). One ERC for the header error, one ERC with RFF pointing to order line 3.
APERAK · Application error and acknowledgement · ref 1
- Document
- 305
- Document number
- KV-AP-10241
- Message function
- Not accepted
- Document/message date/time
- 2026-10-11 14:10
- Reference date/time
- 2026-10-11
- Order number (buyer)
- HL-PO-88294
- Order number (buyer)
- HL-PO-88294
Parties
| Role | Identifier | Name and address |
|---|---|---|
| Buyer BY | 5012345000008GS1 (GLN) | - |
| Supplier SU | 5098765000002GS1 (GLN) | - |
Interchange (UNB)
- Sender
- 5098765000002GS1 GLN
- Recipient
- 5012345000008GS1 GLN
- Prepared
- 2026-10-11 14:10
- Control reference
- KVA000204
- Syntax
- UNOC version 3
- Messages
- 1
| Segment | What it says |
|---|---|
BGM+305+KV-AP-10241+27' | Function 27: the referenced document is not accepted |
ERC+DP01::91' | Application error code DP01, from a code list assigned by the supplier (agency 91) |
FTX+AAO+++...' | AAO: error description in free text |
ERC+IT02::91' | Second error, code IT02 |
RFF+ON:HL-PO-88294:3' | The error relates to line 3 of the order |
FTX+AAO+++LINE 3 GTIN 5098765100214' | More detail on that line |
Note that DP01 and IT02 are invented codes. That is not a shortcut in the example: it is how APERAK works. EANCOM does not publish a list of application error codes. The code in ERC is agreed between the partners, and the third component says whose list it is: 91 assigned by the supplier, 92 assigned by the buyer, or ZZZ in the second component for mutually defined.
Example 3: rejecting a duplicate invoice
Harbour Lane Stores' finance system receives invoice KV-INV-20918 a second time and rejects the copy. This time the document is identified both in a DOC segment, which can carry a status for the referenced document, and in RFF.
APERAK rejecting a duplicate invoice
Sent by the buyer. DOC+380 with status 8 (rejected) identifies the invoice; ERC code agreed by the buyer (agency 92).
APERAK · Application error and acknowledgement · ref 1
- Document
- 305
- Document number
- HL-AP-55120
- Message function
- Not accepted
- Document/message date/time
- 2026-10-10 08:15
- Document/message date/time
- 2026-10-09
- Reference date/time
- 2026-10-09
- Invoice number
- KV-INV-20918
Parties
| Role | Identifier | Name and address |
|---|---|---|
| Buyer BY | 5012345000008GS1 (GLN) | - |
| Supplier SU | 5098765000002GS1 (GLN) | - |
Interchange (UNB)
- Sender
- 5012345000008GS1 GLN
- Recipient
- 5098765000002GS1 GLN
- Prepared
- 2026-10-10 08:15
- Control reference
- HLS000455
- Syntax
- UNOC version 3
- Messages
- 1
| Segment | What it says |
|---|---|
UNB+UNOC:3+5012345000008:14+... | This time the buyer sends the APERAK, because the buyer received the invoice |
DOC+380+KV-INV-20918:8' | Document 380 (commercial invoice) number KV-INV-20918, status 8 (rejected) |
DTM+137:20261009:102' | The date of that invoice |
RFF+IV:KV-INV-20918' | Invoice number reference |
ERC+DUP01::92' | Error code DUP01 from the buyer's list (agency 92) |
GS1's own second APERAK example reports exactly this case, a duplicate invoice number, with a buyer-assigned code.
APERAK segment reference
Status and repeats follow the EANCOM 2002 message structure chart. M is mandatory, C conditional, R required in EANCOM.
| Segment | Name | Status | Repeats | Carries | X12 824 equivalent |
|---|---|---|---|---|---|
| UNH | Message header | M | 1 | APERAK:D:01B:UN:EAN004 | ST |
| BGM | Beginning of message | M | 1 | 305, APERAK number, function | BGN |
| DTM | Date/time | C | 9 | 137 APERAK date | BGN date |
| DOC (SG1) | Document details | C | 99 in a group of 1 | Document type and number, status | OTI |
| DTM (SG1) | Document date | R | 99 | 137 date of the referenced document | OTI date |
| RFF (SG2) | Reference | C | 9 | ON, IV, AAN, AGG, APQ | OTI, REF |
| DTM (SG2) | Reference date | C | 9 | 171 | DTM |
| NAD (SG3) | Name and address | C | 9 | BY and SU from the original document | N1 |
| ERC (SG4) | Application error | C | 99999 | Error code and whose list it is from | TED01 |
| FTX | Error text | C | 1 | AAO error description | TED02 |
| RFF (SG5) | Error reference | C | 9 | Document and line number the error relates to | REF |
| FTX (SG5) | Further text | C | 9 | AAO detail | NTE |
| UNT | Message trailer | M | 1 | Segment count | SE |
Code tables
BGM message function
| Code | Meaning in EANCOM APERAK |
|---|---|
6 | Confirmation: the document was received and processed |
9 | Original |
23 | Transaction on hold |
27 | Not accepted |
DOC document name codes
| Code | Document |
|---|---|
220 | Order |
351 | Despatch advice |
380 | Commercial invoice |
381 | Credit note |
389 | Self-billed invoice |
261 | Self-billed credit note |
DOC document status (second component of the document number)
| Code | Meaning |
|---|---|
1 | Accepted |
3 | Conditionally accepted |
8 | Rejected |
10 | Document currently valid |
39 | On hold |
RFF qualifiers for the acknowledged document
| Qualifier | Document |
|---|---|
ON | Buyer's order number |
IV | Invoice number |
AAN | Delivery schedule number |
AGG | Dispute number |
APQ | Commercial account summary reference |
ERC code list responsible agency
| Value | Position | Meaning |
|---|---|---|
91 | Third component | Code assigned by the supplier or supplier's agent |
92 | Third component | Code assigned by the buyer or buyer's agent |
ZZZ | Second component | Mutually defined; GS1 recommends it when free text replaces a code |
APERAK vs the X12 824
| Data | EDIFACT APERAK | X12 824 |
|---|---|---|
| Message identity | BGM+305 with its own number | BGN |
| Accepted or rejected | BGM function (6, 27) and DOC status | OTI01 application acknowledgment code |
| Original document | DOC and RFF (ON, IV) | OTI reference and transaction set ID |
| Error code | ERC (partner-agreed codes) | TED01 (X12 element 818 code list) |
| Error text | FTX+AAO | TED02 |
| Line reference | RFF with line number in SG5 | REF or TED context |
The biggest practical difference is the error code. X12 TED01 draws on a published code list (element 818), even though partners give some codes their own meaning. APERAK ERC codes are entirely partner-defined, so you need each partner's code list before you can automate anything. The EDI 824 guide covers the X12 side.
APERAK vs CONTRL
| CONTRL | APERAK | |
|---|---|---|
| Question answered | Is the interchange syntactically valid? | Could the application use the content? |
| Generated by | EDI translator | Business application |
| Scope | One interchange, many messages | One message |
| Error codes | Standard syntax codes (12, 13, 39...) | Partner-agreed application codes |
| X12 equivalent | 997 | 824 |
Many partners use both. A message can pass CONTRL and fail APERAK; the reverse cannot happen, because a message rejected at syntax level never reaches the application.
Common APERAK errors and fixes
- Putting the original document number in BGM. BGM carries the APERAK's own number. The acknowledged document goes in
RFF(and optionallyDOC). - Using the UNB mailbox IDs in NAD. GS1 says the parties named are those in the acknowledged message. If you trade through a hub or VAN, these will differ from the interchange IDs.
- Acknowledging several documents in one APERAK. One per message. Ten orders, ten APERAKs.
- Generating APERAK from the translator. If your translator sends APERAK the moment a file arrives, it is really a CONTRL in disguise and tells the partner nothing about whether the order loaded.
- No code list. Error codes without an agreed list force the recipient to read free text. Exchange code lists during onboarding and map them to actions.
- Silent rejections. An APERAK with function 27 means the document was not processed. If nobody watches for them, the order simply never ships. Route rejections to a person the same day.
Testing checklist
- Agree which documents get an APERAK (orders, despatch advices, invoices) and in which direction.
- Agree whether a positive APERAK (function 6) is sent for clean documents, or only rejections.
- Exchange application error code lists and decide what each code triggers.
- Confirm whether the partner uses
DOC,RFFor both to identify the document. - Test rejections for unknown GLN, unknown GTIN, unknown order number and duplicate document number.
- Confirm the response time and who handles rejections on each side.
- Paste test files into the EDIFACT inspector to check references and counts.
OrderSync links each APERAK to the document it refers to, so a rejected order or invoice shows up against that document with the partner's error text, ready for someone to fix and resend.
Frequently Asked Questions
What is APERAK in EDI?
APERAK is the UN/EDIFACT application error and acknowledgement message. The receiving business application sends it to confirm a message was processed or to report errors in its content, such as an unknown product or delivery point. It is the EDIFACT equivalent of the X12 824 application advice.
What is the difference between APERAK and CONTRL?
CONTRL is generated by the EDI translator and reports on syntax: can the interchange be read? APERAK is generated by the business application and reports on content: can the document be used? CONTRL covers a whole interchange; APERAK covers a single message.
What does BGM+305 mean?
305 is the document name code for an application error and acknowledgement message. The third element gives the function, for example 6 for confirmation or 27 for not accepted.
Where do APERAK error codes come from?
The trading partners agree them. EANCOM does not publish a list of application error codes for the ERC segment. The code list responsible agency in ERC shows whose list a code comes from: 91 for the supplier, 92 for the buyer.
Is APERAK the same as ORDRSP?
No. APERAK says whether the application could process the order. ORDRSP says whether the supplier will fulfil it, and on what terms. A supplier might send a positive APERAK and then an ORDRSP that changes quantities.
Should I send a CONTRL for an APERAK I receive?
If your interchange agreement says CONTRL is used for all messages, yes, because APERAK is an ordinary business message at syntax level. You never send an APERAK in response to an APERAK.
What is the X12 equivalent of APERAK?
The X12 824 Application Advice. Both report application-level problems with a previously sent document. The 824 uses TED for error codes from a published list; APERAK uses ERC with codes agreed by the partners.
Related guides
- EDIFACT explained: syntax, envelopes and the full X12 mapping
- EDIFACT CONTRL: syntax-level acknowledgements
- EDIFACT ORDERS and ORDRSP: the order and the supplier's business response
- EDIFACT INVOIC: invoices, a common source of APERAK rejections
- EDIFACT RECADV: goods discrepancies after delivery
- EDIFACT message types: every EDIFACT message and its X12 equivalent
- EDI 824 application advice: the X12 counterpart
Sources
- EANCOM 2002 S3: APERAK application error and acknowledgement message, GS1
- UN/EDIFACT D.01B APERAK message, UNECE
- Global Location Number (GLN), GS1
Paste any APERAK into the free EDIFACT inspector to see the document it refers to and each error it reports.