Tag Archives: functional acknowledgement

The 997: It’s More “Functional” Than You Might Think

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). Continue reading

Functional Acknowledgment Reconciliation

If your company uses Electronic Data Interchange (EDI), reconciling Functional Acknowledgements, or “FAs”, or “997s” is important and often overlooked. Just because the FA is a small document that is automatically generated from your translator, doesn’t mean that it should be ignored.

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. So, 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: A – Accepted; E – Accepted with Errors; P – Partially Accepted (at Least One Transaction was Rejected); and 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.

Ignoring the Error and Rejected statuses may be costly to your company, as those EDI transactions may not be fully processed by your partner.

So, remember the next time you consider the humble FA: reconciliation means more than, “Did I get an FA?”