APERAK — Application Error and Acknowledgement Message (D.96A)

APERAK is the application-level acknowledgment: it tells the message issuer that the message has been received by the recipient's application, and was either accepted (acknowledgment) or rejected because of a business error detected at runtime (application error).

Purpose

Per the UN/CEFACT functional definition, APERAK has two functions:

1. "to inform a message issuer that his message has been received by the addressee's application and has been rejected due to errors encountered during its processing in the application";
2. "to acknowledge to a message issuer the receipt of his message by the addressee's application".

The principle is explicit: a message is first controlled at the system level (CONTRL) to detect syntax errors and acknowledge receipt, then handed to the application for processing. If an error is detected at application level — preventing full processing — an APERAK is sent back to the issuer with error details. If no error is detected and an acknowledgment is needed (no dedicated answer message exists — no ORDRSP for an ORDERS, for instance), APERAK serves as the application-level acknowledgment.

Segment structure

APERAK D.96A is a very short message — no Detail/Summary. Everything is defined in aperak_s.htm (segment table) and aperak_d.htm (clarification).

Header

Mandatory header segments: UNH M and BGM M . Other header segments are conditional: DTM C , FTX C , and CNT C .

Segment groups

Four segment groups:

• SG1 (C, ×9) — RFF + DTM: reference to the original message being acknowledged (often RFF+ON for Order Number, RFF+IV for Invoice) and reference date.
• SG2 (C, ×9) — NAD + CTA + COM: parties involved (APERAK issuer, technical contact).
• SG3 (C, ×999) — ERC + FTX + SG4: the error / acknowledgment section. The segment ERC M is mandatory inside the group: it carries the error (or acknowledgment) code in composite C901. FTX provides the human-readable detail.
• SG4 (C, ×1, inside SG3) — RFF + FTX: precise reference inside the original message (line number, faulty segment, position) and free text.

The message closes with UNT M .

Mandatory / conditional

Strictly mandatory in every APERAK D.96A:

• UNH, UNT — frame the message.
• BGM — application acknowledgment type (qualifier 313 = application error notification, 312 = administrative message).
• ERC (inside SG3) — error or acknowledgment code, mandatory if SG3 is instantiated.

At the standard level, everything else is conditional. But in practice: without SG1 RFF pointing back to the original message, the receiver cannot tell which message is being acknowledged or rejected; without SG3 ERC, the message conveys no useful information. Both are systematically present in production.

Real-world example

An application-error acknowledgment sent by a manufacturer (ACME SUPPLY GMBH) in response to an ORDERS from a buying group, with two application errors detected: an unknown buyer GLN and an obsolete GTIN on one line.

UNB+UNOC:3+5410000000456:14+5410000000123:14+260513:1530+CTRL000200'
UNH+1+APERAK:D:96A:UN'
BGM+313+APERAK-2026-0099+9'
DTM+137:202605131530:203'
RFF+ON:ORDER789'
DTM+171:20260513:102'
NAD+EM+5410000000456::9++ACME SUPPLY GMBH'
ERC+ME010:::Unknown buyer GLN'
FTX+ABO+++GLN 5410000099999 NOT REGISTERED IN OUR MASTER DATA'
RFF+LI:1'
ERC+ME015:::GTIN not in catalogue'
FTX+ABO+++LINE 2: GTIN 3520000005678 SUPERSEDED ON 2026-04-01'
RFF+LI:2'
UNT+13+1'
UNZ+1+CTRL000200'

• BGM+313+APERAK-2026-0099+9 — code 313 (application error notification), number APERAK-2026-0099, status 9 (Original).
• RFF+ON:ORDER789 — reference to the rejected ORDERS (ON = Order Number). DTM+171 = reference date.
• NAD+EM — Message Issuer (qualifier EM = APERAK issuer).
• ERC+ME010 — first error, application code defined by ACME (the standard mandates the segment, not the code dictionary — each vendor publishes its own lexicon).
• FTX+ABO — Reason (qualifier ABO = Reason for adjustment) explaining the error in clear text.
• RFF+LI:1 — Line Item reference (LI = Line Identifier), pointing to the faulty line (1 = header for the first error, 2 for the second).
• UNT+13+1 — 13 segments in the message (UNH and UNT included).

APERAK vs CONTRL

APERAK / CONTRL confusion is classic. The separation is clean:

A single flow can yield both in sequence: first CONTRL (positive syntactic ack), then APERAK later on (business rejection).

Common errors

• ERC without a shared code dictionary — the ERC code is not standardised. If the issuer hasn't published its lexicon, the APERAK has to be handled manually.
• BGM+313 vs BGM+312 — 313 = application error (rejection), 312 = positive application acknowledgment (usually used when no dedicated response message exists). Mixing them blurs the flow semantics.
• Missing RFF in SG1 — without a reference to the original message (RFF+ON, RFF+IV, RFF+DQ), the APERAK is useless: the receiver doesn't know what to fix.
• ERC repeated at the header — ERC cannot be instantiated outside SG3. Common mistake from ERPs that flatten the structure.
• Ambiguous return code — an application APERAK does not necessarily mean rejection: an ERC code can be an acknowledgment (success) or a warning. Rule: BGM[1]+313 = error, BGM[1]+312 = ack.

Related messages

APERAK responds to any EDIFACT message. A few common scenarios:

• ORDERS D.96A received, unknown GTIN → APERAK with ERC + RFF+LI line reference.
• INVOIC D.96A received, invalid VAT → APERAK with FTX detail.
• DESADV D.96A received, missing order number → APERAK requesting correction.
• CONTRL D.96A — the prior syntactic acknowledgment, complementary.

JSON equivalent

JSON projection for integration in an EDI gateway or B2B portal:

{
  "interchange": {
    "controlRef": "CTRL000200",
    "from": { "id": "5410000000456", "qualifier": "14" },
    "to": { "id": "5410000000123", "qualifier": "14" },
    "datetime": "2026-05-13T15:30:00Z",
    "syntax": { "id": "UNOC", "version": "3" }
  },
  "message": {
    "ref": "1",
    "type": "APERAK",
    "version": { "syntax": "D", "release": "96A", "agency": "UN" }
  },
  "applicationError": {
    "number": "APERAK-2026-0099",
    "function": "313",
    "status": "9",
    "issuedAt": "2026-05-13T15:30:00Z",
    "subjectMessage": { "type": "ORDERS", "number": "ORDER789", "date": "2026-05-13" },
    "issuer": { "qualifier": "EM", "gln": "5410000000456", "name": "ACME SUPPLY GMBH" },
    "errors": [
      {
        "code": "ME010",
        "description": "Unknown buyer GLN",
        "detail": "GLN 5410000099999 NOT REGISTERED IN OUR MASTER DATA"
      },
      {
        "code": "ME015",
        "description": "GTIN not in catalogue",
        "detail": "LINE 2: GTIN 3520000005678 SUPERSEDED ON 2026-04-01",
        "lineRef": 2
      }
    ]
  }
}