December 14th, 2021

When exchanging documents according to the ANSI X12 standard, the EDI 997 Functional Acknowledgment (FA) can be sent in response to any given X12 message with the main purpose of validating the contents of the message (or group of messages) from a technical perspective. 

The EDI 997 either confirms or rejects the data contained within X12 message(s). It’s most similar to the EDIFACT CONTRL message (more commonly used in Europe), and, in the case of invoices, you can also think of it as a much less detailed version of a Peppol Invoice Response message.

A Functional Acknowledgment of Your Message(s)

As the name clearly suggests, the EDI 997 is a (purely) functional acknowledgement of a previously sent message or group of messages. In other words, it’s used to alert the sender whether or not a message has been accepted, rejected, or something in between. The message is only meant to report on data (in)accuracy in terms of structure (format) and is not used to validate message contents (semantics), for example, if the total amount listed on the invoice is correct. 

Here’s a basic overview of what the EDI 997 is used for:

  • To confirm receipt of a message
  • To tell the sender whether or not the message has been accepted, accepted with errors, partially rejected, or rejected
  • To provide (in the case of full or partial rejection) a detailed list of errors about the previous exchange

EDI 997 Specification 

According to the official X12 definition, the EDI 997 Functional Acknowledgment Transaction Set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets.

Detailed Specs: EDI 997 

Depending on the nature of the exchange and level of detail required, an EDI 997 may contain up to six segments:

AK1 – Required

Contains the Functional Group Header (GS) which contains basic header information like the identities of both sender and receiver, the document type(s) being referenced in the 997 FA (e.g., “PO” for EDI 850 Purchase Order), and more. 

AK2 – Required

Contains the Transaction Set Header (ST) for each individual document referenced in the EDI 997 FA.

AK3 – Optional

This segment is known as the “data segment note,” and it’s only included in the EDI 997 in the case of an error. Specifically, this segment points to the segment of the received message that contains the error(s). 

AK4 – Optional

This segment is known as the “data element note,” and like the AK3 segment, it’s only included in the EDI 997 FA in the case of an error. Specifically, this segment points to the specific element(s) within the segment of the received message that contains the error(s). It may also contain a numeric code that explains the error in more detail (e.g., data element is too short).

AK5 – Required

This segment contains the Transaction Set Response Trailer (SE) which is used to state the status of the referenced document(s) via the appropriate transaction set acknowledgment code: 

  • A – Accepted 
  • E – Accepted with error(s)
  • M – Rejected (Message Authentication Code (MAC) failed)
  • P – Partially accepted (at least one transaction set referenced within the 997 has been rejected)
  • R – Rejected
  • W – Rejected (validity test failed)
  • X – Rejected (content could not be analyzed after decryption) 

AK9 – Required

This segment contains the Functional Group Response Trailer (GE) which is used to state the status of the group of documents contained within the EDI 997. To state this information, this segment uses the same single-letter codes that are used to indicate individual document status in segment AK5 (see above). 

Here's an example of how an EDI 997 might be used in practice:

  • A buyer (customer) sends a purchase order to their supplier (ORDERS).
  • The supplier confirms receipt of their customer's PO (ORDRSP).
  • The suppliers preps the order, ships it, and then shares the shipment details with their customer (DESADV).
  • The supplier sends their customer an invoice for the order (INVOIC).
  • The buyer acknowledges that the invoice has been received and that it is structurally correct (CONTRL).
  • The buyer provides their supplier with their payment details (REMADV).

You might also like...