For many EDI analysts, the “997 Functional Acknowledgment” [EDI transaction] is a necessary, but little observed, piece of the overall EDI process…one that informs recipients that an EDI transaction has been received. But, there is much more to the 997 than you might think as it is, after all, called a “Functional” Acknowledgement. So what exactly are its’ functions?
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. At minimum, the AK1 (Functional Group Response Header) and AK9 (Functional Group Response Trailer) segments must be present. 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, the AK2 (Transaction Set Response Header) and AK5 (Transaction Set Response Trailer) segments could also be included (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 AK3 (Data Segment Note) and AK4 (Element Segment Note) segments provide the reporting capabilities to “zero in” on the exact error. 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).
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.