What is an ANSI X12 EDI 997 Message?
The ANSI X12 EDI 997 message acts as both a technical and functional acknowledgement for any ANSI x12 EDI message exchanged between suppliers and customers. As a technical response, an EDI 997 confirms the receipt and acceptance of the main message. It can also state the approval or rejection of the previously submitted interchange and a detailed list of errors as a functional response.
Although EDI 997 messages are not always mandatory, they are a vital message type for the electronic purchasing process in manufacturing industries. There are mostly used as a reaction on an EDI 850 Purchase Order or EDI 810 Invoice.
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.
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.
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.
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.
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.
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.
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.
SEEBURGER B2B/EDI solutions are state-of-the-art for reliability and stability. For operating a very reliable supply chain, we recommend EDI 997 Acknowledgements to protect financial transactions, enhance troubleshooting and lower the error rate when exchanging messages with external EDI Trading Partners, which you don’t have operational control over.