Product: X12 EDI
Article Link: http://help.truecommerce.com/en/articles/10697096-x12-edi-how-to-read-functional-acknowledgments-997
A Functional Acknowledgement (997) is a report that automatically gets sent back to the Sender of an EDI Transaction to either confirm or reject a received Transaction. This is an important feedback system within the X12 EDI standard that helps ensure delivery of your digital data that is getting passed across the TrueCommerce Network (Tc.Net) so that both Transaction Manager and any Trading Partner can know when data was received, confirmed, rejected, or in the event of an error - missing.
Functional Acknowledgments (997) are not an Acceptance/Rejection of the original Transaction's request itself (such as requesting to purchase goods, update an order, or provide a bill)
But instead act as a X12 EDI Compliance check to ensure the data is structured in the required way so that it may be properly processed.
Functional Acknowledgement (997) States
As a generate rule, there are essentially three-main states that a Functional Acknowledgement (997) may be in. Accepted, Rejected, and Unacknowledged.
Accepted
An Accepted state means that the originating Transaction has been received by the network, and the Transaction was Accepted into that network.
Rejected
A Rejected state means that the originating Transaction has been received by the network, but was rejected due to an error in the original
Unacknowledged
An Unacknowledged state for your Functional Acknowledgement means that the receiving network has not yet evaluated (or may not of received) the specific Transaction yet. This could be for a variety of reasons such as
The Network processes acknowledgements in batches (common way of maintaining performance) and is waiting for the next evaluation to occur
There is a delay/latency between the TrueCommerce Network (Tc.Net) and the Trading Partner
The Production/Test Flag on the ISA Segment was set incorrectly (this can occur when a Trading Partner switches from Test to Production but the Acknowledgment is still set to Test in Transaction Manager)
The Delivery Address was incorrect and not received
Functional Acknowledgements are turned off for this Transaction/Trading Partner
Functional Acknowledgement State - AK9
The AK9 - Functional Group Response Trailer within the Functional Acknowledgement (997) is the Functional Group Response Trailer - meaning it is providing details on the overall rejection of the returned Functional Acknowledgment when multiple Transactions are Consolidated together during the send.
Typically - if one Transaction out of the entire batch is rejected then you will receive a Rejection in the AK901 segment indicated typically by an R to inform you at least one rejection occurred. Otherwise if all Transactions were accepted - you will find your AK901 segment with an A
Rejected Example
AK9*R*1*1*1~
Accepted Example
AK9*A*1*1*1~
Acceptance/Rejection Codes
Below is the full list of Acceptance/Rejection codes used by X12 EDI.
Code | Definition |
A | Accepted |
E | Accepted, But Errors Were Noted. |
M | Rejected, Message Authentication Code (MAC) Failed |
P | Partially Accepted, At Least One Transaction Set Was Rejected |
R | Rejected |
W | Rejected, Assurance Failed Validity Tests |
X | Rejected, Content After Decryption Could Not Be Analyzed |
Functional Group Details
Your Functional Acknowledgments (997) contain Functional Group details which act as the bookends - providing high-level overview details of whether or not the Functional Group was accepted or rejected as a whole represented by the AK1 and the AK9.
Specific Transactions, which are wrapped by those two segments, are contained within the Functional Group section. The purpose of the AK1/AK9 grouping details allows for summary information that covers all transactions.
Functional Group Response Header- AK1
Within the Functional Acknowledgment (997) you will find information about the Group of Transactions that can contain multiple transactions grouped together during the send known as the AK1 - Functional Group Response Header
This is the primary way that the TrueCommerce Network (Tc.Net) matches a Functional Acknowledgement (997) with the original document its referencing
However the AK2 (if present) contains the original document # which can be an easier way of identifying a transaction at an individual level
Functional Group Response Trailer - AK5
The AK5 - Transaction Set Response Trailer segment is the Transaction Set Response Trailer - which provides you with an Acceptance/Rejection notice for each specific Transaction found within the overall batch. This section allows you to narrow down to the specific transaction in question that is apart of the overall Functional Acknowledgment (997).
Much like the AK9 segment you will find that your transaction is marked as Accepted or Rejected within the AK501 segment with either an A for Accepted or an R for Rejected.
Rejected Transaction Example
AK5*R~
Accepted Transaction Example
AK5*A~
Acceptance/Rejection Codes
Below is the full list of Acceptance/Rejection codes used by X12 EDI.
Code | Definition |
A | Accepted |
E | Accepted But Errors Were Noted |
M | Rejected, Message Authentication Code (MAC) Failed |
R | Rejected |
W | Rejected, Assurance Failed Validity Tests |
X | Rejected, Content After Decryption Could Not Be Analyzed |
Transaction Details
The Transaction Loop which includes the AK2, AK3, AK4 and AK5 segments detail out a per-Transaction detailing of their Acceptance/Rejection status
This set of segments provides information on which Transactions were Accepted/Rejected, and if rejected - the reason for the rejection. A Transaction response is broken down into the Header/Trailer (AK1 & AK5) and then the Segment/Element Details for the Rejection (AK3 & AK4)
Transaction details are optional - and not every Trading Partner will send a detailed explanation of the rejection.
If these segments are missing during a Rejection - you will need to reach out to your Trading Partner for the rejection details manually.
Transaction Status
The AK2 and AK5 act as the Transaction Response summary - providing information on the Transaction Type & Document Number (AK2) and the Acceptance/Rejection Status (AK5).
AK2 - Transaction Set Response Header
Each AK2 - Transaction set Response Header segment represents a single specific Transaction Identifier. Letting you know the type of Transaction and the Document Number associated with it.
AK201 - Transaction Set Identifier Code
The Transaction Set Identifier Code is essentially the 3-digit EDI Transaction Set Code used to identify an X12 EDI Transaction globally (such as 810 for Invoice, or 856 for Advance Ship Notice). This is defined by the value placed within the AK201 and identifies the type of Transaction that was rejected.
AK201 with an Advance Ship Notice (856) Code
AK2*856*0001
AK202 - Transaction Set Control Number
The Transaction Set Control Number provides the Document Number that is associated with the specific Transaction. This typically would be your Purchase Order, Invoice, or Shipment Number that you search for within inside Transaction Manager when looking for a specific Transaction.
Rejection Details
When a Transaction is rejected - a Trading Partner can often provides details (although they don't always) about why a Transaction was rejected through the use of the AK3 and the AK4 segments that provide key details about the Segment/Element that was rejected and potentially a reason code for why.
AK3 - Data Segment Note
The AK3 - Data Segment Note is a segment about a segment. The details it provides informs you as to which Segment within the specified Transaction failed to pass the inspection within the AK301 segment.
PO4 Segment Failed Example
AK3*PO4*26**8
The AK3 will also provide a generic Error Code within the AK304 segment that can be used to give a baseline idea as to why the segment failed. In this example the error code is an 8 - Segment Data Element Error
AK3*PO4*26**8
Code | Definition |
1 | Unrecognized segment ID |
2 | Unexpected segment |
3 | Mandatory segment missing |
4 | Loop Occurs Over Maximum Times |
5 | Segment Exceeds Maximum Use |
6 | Segment Not in Defined Transaction Set |
7 | Segment Not in Proper Sequence |
8 | Segment Has Data Element Errors |
AK4 - Data Element Note
Whenever an AK304 returns with an error code of 8 - Segment Has Data Element Errors it will indicate this is an issue with a value inside the designated segment from the originating document.
The AK4 - Data Element Note (if present) will detail out the reason for that element error by identifying the Element's Position (AK401) within the segment, an Error Code (AK403), and a reference to the bad value (AK404)
Example AK4 Error
AK4*4**7*2
In the above error, we can break down each element to determine what sort of issue we're having with the PO4 Segment mentioned in the AK301 earlier.
Element | Breakdown |
AK401 = 4 | The first Element, our AK401 has notified us that Element 4 of the PO4 segment (mentioned in the AK3 segment) of our 856 (mentioned in the AK1 segment) is bad |
AK403 = 7 | The 3rd element, our AK403 is providing us an optional error code of 7 to give us an idea of what's wrong. In this case, a 7 means "Invalid code value" |
AK404 = 2 | Our 4th Element, our AK404 is giving us a copy of the bad data - which is that of a 2. Referencing the X12 EDI Specifications for the PO404 segment - we can see that 2 is an invalid code that has no definition. |
Note: Transactional Details, such as AK2, AK3, and the AK3 segments are optional - and not all Trading Partners will send this information.
You may need to reach out to your Trading Partner if no detail information is present in your Functional Acknowledgment (997) to be given a reason for the rejection
Acceptance/Rejection Codes
| Definition |
1 | Mandatory data element missing |
2 | Conditional required data element missing. |
3 | Too many data elements. |
| More data elements existed than defined for the segment |
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 |
12 | Too Many Repetitions; More repetitions existed than defined for the segment |
13 | Too Many Components; More components existed than defined for the element |
Summary
We can do a quick check on Functional Acknowledgements sent by your Trading Partner by checking the AK9 for an Accepted or Rejected code.
And if present during a rejection, we can utilize the information provided in the AK2, AK3, and AK4 segments to break down the reason for rejection in order to easily correct the issue.
rev 3/3/2025