997 EDI - Functional Acknowledgment
The 997 Functional Acknowledgement is one of the most common EDI transactions. Learn about EDI 997s by reading the guide below.
If you need to send EDI 997s, we can help.
What is an EDI 997 Functional Acknowledgment Specifications?
The EDI 997 Functional Acknowledgment 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 the EDI 997 Functional Acknowledgment Specification 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.
EDI 997 Format
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
- Invalid codes/conditions/qualifiers
- 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 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.
Here is an EDI 997 Transaction within Cleo Integration Cloud
EDI 997 Specification
This X12 Transaction Set contains the format and establishes the data contents of the Functional Acknowledgment Transaction Set (997) for use within the context of an Electronic Data Interchange (EDI) environment. The 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..
Accredited Standards Committee X12. ASC X12 Standard [Table Data]. Data Interchange Standards Association, Inc., Falls Church, VA. https://x12.org/index.php/products/transaction-sets
Automate EDI / API Transactions
Eliminate manual integration flows by automating and orchestrating EDI and API-based transactions in an intuitive self-service, low-code development environment.
Not ready for self-service? Leverage Cleo’s Managed Services team to get you up and running.