997 EDI - Functional Acknowledgment

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.