EDI 997 Functional Acknowledgement Transaction Specifications
1. What is an EDI 997 Functional Acknowledgement?
The EDI 997 is also known as EDIFACT CONTROL and x12 997 Functional Acknowledgement serves as a receipt from the receiving trading partner in response to a transaction sent by the sending trading partner. This document also reports any formatting errors or loss of data. It can be sent by any trading partner in response to an individual EDI message or a group of messages.
It is important to note that when an EDI 997 is sent, it is only a notification to the sender that the original transaction arrived and was processed. It is not a confirmation of a transaction, it does not give any indication that the receiving trading partner agreed to the contents of the original translation.
Many may not know how important the EDI 997 FA document is and how important this very small EDI transaction set can be to your EDI operations. The 997 is less than one Kilo character in size, yet the value it provides is massive in the EDI world. Although it is an optional document, its benefits are crucial to staying on top of your internal business processes.
2. How does a typical EDI 997 structure look like?
2.1 The ANSI X12 EDI 997 Structure
An EDI 997 message is sent in response to a received ANSI X12 message. These EDI 997 messages can be minimal in size when a positive confirmation is sent. The details may contain a cross-reference relating to the message triggering the EDI 997.
A typical EDI 997 Message includes:
- Message Header
- Details stating precisely which previously received message this acknowledgement relates to
- The acceptance or rejection code, at both Interchange and Message levels
- If a rejection is being sent, details of why this message (or part of the message) have been rejected
An EDI transaction set is a document defined by the ANSI X12 EDI standard that prescribes the exchange of information between two businesses using electronic means. In case the transaction set is sent from one Trading Partner to another, it is called a message.
2.2 Key data elements included in the EDI 997 Functional Acknowledgement
AK1 – Group Acknowledgment (Refers to GS segment)
AK3 – Reports Errors in a specific segment
01: Segment in Error
02: Line in error from ST
AK4 – Reports Errors in specific element
01: Lists the Element in error
02: Lists the ID in EDI dictionary of the element
03: Code giving a general reason for the error 04: Shows the bad data
- 1: Mandatory data element missing
- 2: Conditional data element missing
- 3: Too many data elements
- 4: Data element too short
- 5: Data element too long
- 6: Invalid character in data element
- 7: Invalid code value
- 8: Invalid date
- 9: Invalid time
- 10: Exclusion condition violated
AK9 – Group Response
- Additional dates (such as cancel by dates
AK2 – Document Acknowledgment (Refers to ST segment)
AK5 – Type of acknowledgment
01: Lists the Acknowledgment Status
- A: Accepted
- E: Accepted with Errors noted
- M: Rejected; message authentication
- P: Partially accepted
- R: Rejected
- W: Rejected
- X: Rejected
02: Transaction set syntax Error Code
- 1: Transaction set not supported
- 2: Transaction set trailer missing
- 3: Transaction control #’s don’t match
- 4: Number of segments don’t match count
- 5: One or more segments in error
- 6: Missing transaction set identifier
- 7: Missing or invalid transaction set control #
- 16: Syntax Error
- 23: Transaction set control # not unique
3. What are the Essential Components of EDI 997?
Normally, EDI 997 Functional Acknowledgements are very basic documents. The main elements in an EDI 997 are:
- Received EDI transaction code
- Indication of acceptance, acceptance with errors, or rejection
- List of erroneous elements and reason for the error(s)
4. How do I Use EDI 997?
In most cases, businesses choose to fully automate EDI 997, triggering a new EDI 997 document every time an EDI transaction set is received. For example, when your EDI software receives a new EDI 850 Purchase Order, it can automatically send a Functional Acknowledgement to let the buyer know you’ve gotten the order.
It’s important to note that EDI 997 only communicates the receipt of a document by another company’s EDI software. While a 997 can reject another EDI document due to syntax errors, an accepted document does not indicate that the document has actually been viewed by a person or processed by their internal business systems. Additionally, EDI 997 does not indicate whether the partner accepts, rejects, or needs to make changes to the details within the document. For this, the trading partner will need to send a corresponding EDI request for changes or reach out to the sender directly.
5. How Do EDI 997 Work?
5.1 Usage of the ANSI X12 EDI 997 Message
There are two different styles of the ANSI X12 EDI 997 message. Either as a technical response or a functional response.
A technical acknowledgement informs the recipient that the previous interchange has been received, whether it has been accepted, and references the message type and ID. A technical response would comprise of AK1 (Functional Group Response Header), AK2 (Transaction Set Response Header) and AK5 (Transaction Set Response Trailer), stating the Original Transaction, the Transaction Control number and Response code. A functional acknowledgement would also include AK3 (Data Segment Note) and AK4 (Data Element Note) segments, which details the specifics within the Data Segments and Elements which caused the error and reasons for a failure.
5.2 Processing of the ANSI X12 EDI 997 Message
Once an ANSI X12 EDI 997 message has arrived, the EDI system will check the message’s details to find the message triggering the EDI 997. If the triggering message has been accepted, the sender knows that the message’s content and syntax are acknowledged. In the case of rejections, the EDI 997 message’s feedback helps the sender fix and resend the triggering message.
6. EDI 997 in the EDI Workflow
6.1 ANSI X12 EDI 997 Example in the EDI Workflow
An ANSI X12 EDI 997 message can be the response to any triggering EDI message. There might be only EDI 997 messages required for the more critical EDI messages, not for all. Therefore there is not the one typical EDI 997 example in the workflow like with other EDI messages.
6.2 What are the equivalents of ANSI X12 EDI 997 in other EDI Standard Formats?
The ANSI X12 standard is common in the NAFTA region. The comparable message with EDIFACT is a CONTRL message. VDA messages are commonly used in the automotive industry. VDA APERAK (Application Error and Acknowledgement message), both 4937 and 4938, is used to acknowledge receipt of a message and highlight any issues.
6.3 ANSI X12 EDI 997 vs. EDI 824
An EDI 997 message acknowledges if an EDI transmission has been received and translated in comparison to an EDI 824 which indicates whether an invoice has been rejected or accepted by the Accounts Payable system. EDI 824 is typically used for sending invoice disputes with their notes.
The ANSI X12 EDI 824 is an electronic representation of an application advice.
7.Benefits of the EDI 997?
7.1 What are the Benefits of EDI 997?
First and foremost, EDI 997 ensures that other EDI documents are being properly received by a trading partner’s systems. It creates an audit trail that can be useful during reconciliation if needed and helps to streamline order processing communications.
EDI 997 can also let the sender know about syntax errors in their documents. By rejecting or pointing out such errors, EDI 997 gives the sender a chance to fix their other documents, before they are seen or dealt with by the recipient. This helps reduce delays and discrepancies which can have a negative impact on trading partner relationships.
7.2 Benefits of the ANSI X12 EDI 997 Message
EDI 997 messages have many different benefits
- An automatic audit trail can be generated by which the sender will get confirmation if the triggering message has been accepted and received by the receiver.
- Supply chain and financial transactions are protected
- EDI 997 introduce easier troubleshooting:
- If parts of the message were rejected, the sender gets this information with rejection reasons
- If only part of a message is denied, the accepted information can still be used and processed – this can also be reported back to the sender
- Cause of rejection can be compared with an ERP system and diagnosed against the previously sent message
7.3 Typical Errors when using the ANSI X12 EDI 997 Message
Typical reasons for rejection include violation of character length, incomplete or missing data in mandatory segments, or invalid data.If the customer never received a message, no acknowledgement gets created. The ideal handling of such a scenario requires monitoring and alerting for non-events.