EDI 997 Functional Acknowledgment

What Is an EDI 997?

The EDI 997 Functional Acknowledgment is an automated receipt sent by a receiver back to the sender after an EDI document arrives. It confirms two things: the document was received, and whether it passed syntax validation. The 997 does not confirm business acceptance - a 997 can say 'Accepted' while the receiver's ERP rejects the order for being out of stock. But a rejected 997 means the document never made it into the receiver's system at all, so it is the first place to look when an EDI transaction disappears.

Functional Acknowledgment Meaning in EDI

In EDI, 'functional acknowledgment' is the generic term for the automated response that says 'we got your file and it looks structurally okay.' The 997 is the X12 version; the EDIFACT equivalent is called a CONTRL message. The 997 is required by most trading partner agreements because it closes the loop on transmission - without it, the sender has no idea whether the document arrived or vanished into a black hole.

EDI 997 Structure and Key Segments

A 997 mirrors the structure of the document it is acknowledging, using a hierarchical loop (AK2/AK3/AK4/AK5) to report status at the transaction set, segment, and data-element levels:

AK1 - Functional Group Response Header: identifies the functional group being acknowledged by group control number and transaction set identifier code.
AK2 - Transaction Set Response Header: identifies each transaction set within the group by its control number and type (e.g., 850, 856).
AK3 - Data Segment Note: flags a specific segment (e.g., PO1, REF) where a syntax error was found, including the segment position and loop identifier.
AK4 - Data Element Note: drills into a specific data element within the flagged segment, reporting the element position and the syntax error code.
AK5 - Transaction Set Response Trailer: summarizes the status of the entire transaction set (A=Accepted, E=Accepted with Errors, R=Rejected, X=Rejected because of errors in a segment, or P=Partially accepted).
AK9 - Functional Group Response Trailer: summarizes the entire functional group (number of included, received, accepted, and rejected transaction sets).

EDI 997 Response Codes Explained

The AK5 segment carries the master status code for each transaction set. Understanding these codes is critical to triaging EDI issues:

A (Accepted) - The transaction set passed syntax validation. This does not mean the business data was accepted, only that the structure was valid.
E (Accepted with Errors) - The transaction set was structurally valid enough to process, but contained non-fatal syntax errors (e.g., a missing optional element). The receiver may still process it.
R (Rejected) - The transaction set failed syntax validation and was not processed. This is the most serious outcome and requires immediate correction and re-transmission.
X (Rejected because of errors in a segment) - The transaction set was rejected because of errors found in one or more segments flagged in AK3/AK4.
P (Partially accepted) - Some transaction sets in the functional group were accepted, while others were rejected.

Common EDI 997 Error Codes (IK3-IK4 / AK3-AK4)

When a 997 reports errors, the AK3 and AK4 segments contain numeric error codes that pinpoint exactly what went wrong. These are the codes Yoke sees most often in production:

1 - Unrecognized segment ID (the segment name is not expected at this position).
2 - Unexpected segment (a required segment is missing, or an optional segment appears in the wrong place).
3 - Required segment missing (a mandatory segment like N1 or PO1 is absent).
4 - Loop occurs over maximum times (a loop repeats more than the X12 standard or trading partner allows).
5 - Segment exceeds maximum use (a segment appears more times than permitted).
6 - Segment not in defined transaction set (the segment is valid in X12 but not allowed in this transaction set).
7 - Segment not in proper sequence (the segment is valid but appears in the wrong order).
8 - Segment has data element errors (an AK4 error is attached to this segment).
I6 - Code value not used in this position (a qualifier code like REF01 is invalid for this transaction set).
I7 - Implementation "not supported" (the trading partner's specific implementation guide does not allow this value).
I9 - Implementation dependent "not used" segment or element present (an element that should not be sent was included).

EDI 997 vs. EDI 999: What's the Difference?

The 997 and 999 both serve the same purpose - functional acknowledgment - but they are not interchangeable. The 999 was introduced in X12 version 005010 (2003) as a more detailed replacement for the 997, adding richer error reporting. Most trading partners today accept either, but some mandate one or the other. The 997 uses AK segments; the 999 uses IK segments with the same structural roles but more granular data-element error detail. Yoke generates the correct acknowledgment type based on each trading partner's implementation guide.

Why Missing 997s Are a Bigger Problem Than Rejected Ones

A rejected 997 is loud - you know something is wrong and you fix it. A missing 997 is silent and dangerous. When a 997 never arrives, it usually means one of four things: the document never left your VAN or AS2 endpoint, the receiver's system is down, the document was dropped by the receiver's firewall or spam filter, or the receiver sent a 997 that your system never received. Without a 997, the sender assumes the document was accepted, but the receiver may have no record of it. Yoke monitors 997 SLAs and alerts when expected acknowledgments do not arrive.

Check your VAN or AS2 logs first - did the document actually transmit?
Verify the ISA/GS interchange and group control numbers match on both ends.
Confirm the receiver's mailbox or endpoint URL has not changed.
Set up 997 SLA monitoring so missing acknowledgments trigger alerts within minutes, not days.

How Yoke Handles EDI 997 Monitoring

Yoke Integration automatically generates, receives, and interprets 997 acknowledgments for every transaction in your network. Our platform parses AK segments into human-readable error descriptions, maps common error codes to corrective actions, monitors 997 SLAs per trading partner, and alerts you the moment an expected acknowledgment is missing. If a 997 comes back rejected, Yoke surfaces the exact segment, element, and error code so your team knows what to fix - no XML spelunking required.

Frequently Asked Questions

Quick answers to the questions buyers and suppliers ask most about this transaction.

What is an EDI 997? The EDI 997 Functional Acknowledgment is an automated receipt that confirms an EDI document was received by the trading partner's system and whether it passed syntax validation. It does not confirm business acceptance.
What does a 997 Functional Acknowledgment tell you? A 997 tells you whether the EDI document's structure is valid (AK5 status codes A, E, R, X, or P) and pinpoints exactly where syntax errors occurred using AK3/AK4 segment and data-element notes.
What is the difference between 997 and 999? Both are functional acknowledgments. The 997 is the original X12 format using AK segments. The 999 was introduced in version 005010 as a more detailed replacement using IK segments. Most partners accept either, but some require one specifically.
What does 'Accepted with Errors' (E) mean on a 997? Status 'E' means the transaction set was structurally valid enough to process, but contained non-fatal syntax errors. The receiver may still process it, or they may hold it depending on their error-tolerance rules.
What should I do if I never receive a 997? Check your VAN/AS2 transmission logs to confirm the document actually sent. Verify ISA/GS control numbers match. Confirm the receiver's endpoint has not changed. Set up SLA monitoring so missing 997s trigger alerts within minutes.

EDI 997 - Functional Acknowledgment