EDI 997 - Functional Acknowledgment Specifications
What is an EDI 997 Functional Acknowledgment Specifications?
The EDI 997 Functional Acknowledgment Specifications is sent as a response to other EDI transactions received.
An EDI 997 serves as a receipt to acknowledge that an EDI transaction, or a series of transactions, was successfully transmitted and received by the receiving trading partner.
How is an EDI 997 Functional Acknowledgment Specifications used?
An EDI 997 Functional Acknowledgment serves as a receipt from the receiving trading partner in response to a transaction sent by the sending trading partner.
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 accordingly. It does not give any indication that the receiving trading partner agreed to the contents of the original transaction.
The 6 Functions of a 997 Functional Acknowledgment
The FA provides information on problems found with the structure or content of EDI transactions, such as a mandatory segment or element missing, or invalid code. It isn’t just a data receipt.
The 997 acknowledges receipt of one or more transactions; it reports specifically based on X12 Syntax (not backend application) data compliance.
The 997 (could) use up to a total of six different segment types in the “body” of the transaction (between the ST and SE segments), and is dependent on the level of detail being reported.
Two segment types must be present
1. AK1 (Functional Group Response Header)
2. AK9 (Functional Group Response Trailer)
These simply report that a specific Functional Group (GS/GE envelope) has been received.
This segment pair also includes the number of transaction sets received and accepted [e.g. Accepted, Accepted with Errors, or Rejected].
This is considered a simple or “Summary” 997 since it references an entire group of transactions (e.g. IN-Invoices) rather than to individual transactions (e.g. 810-Invoices).
While this level of information is often enough to support most EDI applications, some organizations prefer the 997 to report on each transaction individually.
Therefore, in addition to the AK1 and AK9 segments, two other transactions could also be included:
3. AK2 (Transaction Set Response Header)
4. AK5 (Transaction Set Response Trailer) (ST/SE envelope).
This segment pair reports the status of each transaction separately, using the same acceptance statuses [e.g. Accepted, Accepted with Errors, or Rejected]. This is considered a “Detailed” 997 since it references each transaction individually.
All 997 (Functional Group or Transaction Set) statuses are coded inside the “status-carrying” AK5 (Transaction) and AK9 (Group) segments for easy EDI translator interpretation.
If the 997 indicates an error (for example, error code ‘5’ = “One or More Segments in Error”), that 997 will report additional detail to simplify the process of linking the error back to the originating transaction.
The following segments provide the reporting capabilities to “zero in” on the exact error.
5. The AK3 (Data Segment Note)
6. AK4 (Element Segment Note)
If no errors occurred then the AK3 and AK4 segment pair would be omitted (otherwise, the AK3/AK4 would repeat for each error found on a reported transaction). Common errors include:
Mandatory segment or element missing
Invalid characters in data
Mismatched control counters
Mismatched data types
Incorrect element lengths
And many others.
Many systems commonly reconcile 997 Functional Acknowledgments (both incoming and outgoing), verify that acknowledgment reporting has occurred inside pre-determined windows of time, and confirm that all transactions were accepted.
If a 997 Functional Acknowledgment is late (either incoming or outgoing) or has reported an error on a production transaction set, the host translator can intervene, interpret the problem, and send a notification to a backend system or the EDI analyst assigned to resolve such issues (often resulting in correction and retransmission by the offending party).
Functional Acknowledgment Validation Statuses
FA reconciliation should not just ask the question, “Did I get an FA?” It should also ask whether the document has been validated. There are four validation statuses:
1. A – Accepted
2. E – Accepted with Errors
3. P – Partially Accepted (at Least One Transaction was Rejected)
4. R – Rejected.
Your reconciliation process should be checking for Rejections, at a minimum, but also for Error and Partially Accepted states. Those states may reflect a change in standards or in your partner’s requirements that you haven’t taken into account or may not be aware of. They can also mean that you have provided incomplete or incorrect data. If E, R and/or P statuses are received on a regular basis, it may be time to check your mapping and application data for those transactions.
Understanding the errors that exist in a document can be extremely helpful, especially in cases where a rejection has occurred. Even when accepted but “with errors”, you have the information needed to make the corrections needed to improve going forward. Knowing the Functions of (and implementing) an automated 997 reconciliation process can save considerable time and money for your organization.
Ignoring the Error and Rejected statuses may be costly to your company, as those EDI transactions may not be fully processed by your partner.
Modern EDI Services with Cleo
Choose the EDI Services package that best fits your business:
1. Create and deploy your own integrations using Cleo's intuitive, self-service design platform.
2. Utilize Cleo's EDI managed services team to design and build your integrations.
3. Blend our EDI expertise and your business knowledge together in any manner that suits your use case.
Read our complimentary eBook which goes in-depth into the many ways your enterprise can save on integration costs.
Identify and prioritize EDI modernization objectives and create an action plan to realize them.