What Is EDI 997? The Functional Acknowledgment Explained

The EDI 997 is a functional acknowledgment that confirms a trading partner received an electronic data interchange (EDI) transmission and that the file passed syntax checks. It verifies that the file arrived, is readable, and follows a structurally valid format. 

The distinction matters because an accepted 997 doesn’t necessarily mean an invoice, purchase order, or shipment was approved at the business level. This article will explain what a 997 file contains, when it’s sent, how it fits into modern EDI workflows, how to interpret its response codes, and what to do when a transaction is rejected.

What Does EDI 997 Do?

An EDI 997 tells the sender whether an EDI transaction reached the recipient’s system and met basic EDI standards. It uses standards developed by X12, an organization accredited by the American National Standards Institute (ANSI), which define the structure and standardized formats used for EDI data. This document acknowledgment serves as an electronic receipt and reports whether the recipient’s software found syntax errors, missing or invalid transactions, or formatting problems in the EDI transaction set.

The acknowledgment can apply to an entire functional group or to individual transactions within that group. In a standard EDI document, envelope segments organize the transmission into an overall interchange, groups of related documents, and individual transaction sets. Control numbers within those envelopes help the sender match the 997 to the prior transaction.

A 997 creates a clear audit trail by confirming that the document arrived and showing whether the recipient’s EDI translator accepted it at the structural level.

When Is an EDI 997 Sent, and How Quickly?

A 997 is typically sent after the recipient’s EDI software receives a document and completes its initial syntactical analysis. The required response time depends on each trading partner’s specifications. Kroger, for example, monitors for expected acknowledgments and requires vendors to return them within the timeframe defined by the applicable EDI standard or within 24 hours, whichever is shorter. Failing to return the acknowledgment can disrupt EDI service.

The recipient’s system doesn’t generate another 997 after receiving one. Otherwise, the two systems could create an endless acknowledgment loop. Instead, the 997 closes the communication cycle for the original transaction.

What Does an EDI 997 Contain?

An EDI 997 contains a structured response showing how the recipient’s system evaluated the original functional group and its individual transaction sets. It helps to understand how an X12 transmission is organized:

• Interchange: The complete EDI transmission sent from one trading partner to another.

• Envelope: A pair of segments that mark the beginning and end of a particular level of the transmission.

• Functional group: A collection of related transaction sets, such as several purchase orders sent together.

• Transaction set: A single business document, such as EDI 850 purchase order or EDI 810 invoice transaction.

• Segment: A line of coded information that performs a specific function within the transaction.

• Data element: An individual piece of information inside a segment, such as a control number or acknowledgment code.

A transaction set carries data for a specific business purpose, while functional groups organize related transaction sets within the larger interchange.

Key Segments: AK1, AK2, AK5, and AK9

The most important segments in a 997 show the acknowledgment status at both the group and transaction levels. The 997 uses AK segments to identify what was received and report whether it passed syntax checks.

• AK1, functional group response header: Identifies the functional group being acknowledged and references its group control number.

• AK2, individual transaction acknowledgment: Identifies a specific transaction set within the functional group, such as an invoice or purchase order.

• AK5, transaction set response: Reports whether that individual transaction was accepted, rejected, or accepted with identified errors.

• AK9, functional group summary: Summarizes the response for the complete functional group, including how many transaction sets were included, received, and accepted.

The AK2 and AK5 segments can repeat when a functional group contains more than one transaction. This allows the 997 to report a separate result for each document rather than applying one response to the entire group.

Sample 997

ST*997*0001~

AK1*IN*4521~ (acknowledging invoice group 4521)

AK2*810*0002~ (transaction set 0002, an 810 invoice)

AK3*IT1*5**8~ (error in the IT1 segment, line 5)

AK4*2*358*1~ (element 2, quantity invoiced, is missing)

AK5*R*5~ (transaction rejected)

AK9*R*1*1*0~ (group rejected: 1 sent, 1 received, 0 accepted)

SE*8*0001~

Acknowledgment Codes: Accepted, Rejected, and Accepted With Errors

The response codes in the AK5 and AK9 segments indicate what happened during validation:

• Accepted: The transaction or group passed the required syntax checks without blocking errors.

• Rejected: The recipient found errors that prevented the transaction from being processed. The sender generally needs to correct and resend the original document.

• Accepted with errors: The transaction can still be processed, but the acknowledgment identifies issues the sender should correct in future EDI documents.

These codes help senders determine whether they need to take immediate corrective action or simply address a nonblocking issue before the next data transmission.

What Doesn't a 997 Tell You?

An accepted EDI 997 confirms that the document arrived and passed structural or syntax checks. It doesn’t confirm that the recipient approved the business information in the electronically encoded document. The recipient’s system may correctly read every segment and data element, yet still identify invalid data values or problems with transaction details.

For example, an accepted 997 for an EDI 810 invoice means the transaction followed the expected EDI format. It doesn’t mean the buyer approved the invoice, that the pricing matches the PO, or that payment has been authorized. Those decisions are made in back-end business systems after initial EDI validation.

The same distinction applies to purchase orders. A 997 can confirm that an EDI 850 arrived in a readable format, but it doesn’t communicate whether the supplier can fulfill the order. An EDI 855 Purchase Order Acknowledgment provides the business-level response of accepting, rejecting, or proposing changes to the order.

EDI 997 vs. EDI 999: What Is the Difference?

Another acknowledgment document you may encounter in an EDI workflow is the EDI 999 Implementation Acknowledgment. It confirms whether an EDI document meets the syntax and implementation-specific requirements of the applicable implementation guide. Like the 997, it tells the sender whether a functional group or individual transaction was accepted, rejected, or accepted with errors. However, the 999 goes further by validating the transaction against implementation-specific rules. It also reports errors in greater detail.

As a general rule, the EDI 997 functional acknowledgment is the standard in retail, logistics, and other commercial business data interchange environments. In healthcare, the 999 is commonly required for HIPAA transactions because it validates against the applicable implementation guide rather than just checking basic syntax.

The main difference is depth: the 997 confirms structural compliance, while the 999 performs a more detailed implementation-level review.

What Happens When an EDI 997 Is Rejected?

A rejected 997 means the recipient’s EDI software found syntax or formatting errors that prevented the original transaction from processing. The sender should use acknowledgment details to identify problems, correct source data or mapping, and resend the original EDI transaction.

A practical response usually follows these steps:

• Match the acknowledgment to the original document: Use the functional group and transaction control numbers to locate the rejected file.

• Review the reported errors: Check the AK segments and error codes for missing mandatory data, invalid characters, incorrect character lengths, or erroneous elements.

• Correct the underlying issue: Update the source data, mapping rules, or document format that caused the rejection.

• Regenerate and resend the transaction: Create a corrected version rather than editing the transmitted file manually.

• Monitor the replacement acknowledgment: Confirm that the recipient accepts the resubmitted transaction and retain both responses as part of the audit trail.

Orderful surfaces rejection notifications as soon as validation occurs, helping teams address failed transactions before they create delays or costly chargebacks. Orderful validates every transaction against your partner's guidelines, in testing and in production.

EDI 997 Functional Acknowledgment FAQs

What Does an EDI 997 Acknowledgment Confirm?

An EDI 997 confirms that a transmission reached the recipient's system and passed X12 syntax checks. It reports, for each functional group and transaction set, whether it was accepted, rejected or accepted with errors. It doesn't confirm that the trading partner approved the business content, such as invoice pricing or order quantities. Those decisions happen later in the partner's back-end systems.

How Quickly Should a 997 be Sent?

The deadline is set by each trading partner's specifications. Kroger, for example, expects an acknowledgment within the time defined by the EDI standard and version being used, or within 24 hours, whichever is shorter. Missing the required window can disrupt EDI service, so most teams set their EDI software to send 997s automatically as soon as a document is received.

Does a 997 Acknowledge Another 997?

No. A recipient doesn't send a 997 in response to another 997, because the two trading partners' systems could then trigger an endless loop of acknowledgments. The 997 closes the communication cycle for the original transaction. If an expected 997 never arrives, the sender should check the transmission and follow up with the trading partner directly.

What is The Difference Between an EDI 997 and an EDI 855?

A 997 is a technical receipt that confirms a purchase order arrived and passed syntax checks. An EDI 855 Purchase Order Acknowledgment is a business response. It tells the buyer whether the supplier accepts the order, rejects it or proposes changes to items, quantities, prices or dates. Many retailers require both because they answer different questions.

What is The Difference Between an EDI 997 and an EDI 999?

Both acknowledge receipt and report accepted, rejected or accepted-with-errors results. The 997 checks basic X12 syntax and is standard in retail, logistics and other commercial EDI. The 999 Implementation Acknowledgment also validates against a specific implementation guide and reports errors in more detail, which is why it is commonly required for HIPAA healthcare transactions.

What Should You Do When a 997 Shows a Rejection?

Use the group and transaction control numbers to find the original document. Then review the AK3 and AK4 details to see which segment or element failed. Fix the source data or mapping, regenerate the transaction rather than hand-editing the sent file, and resend it. Confirm the new 997 shows accepted, and keep both acknowledgments for your audit trail.

Monitor EDI 997 Functional Acknowledgments With Less Manual Work

EDI 997 acknowledgments help teams confirm that documents arrived, passed syntax checks, and reached the next step in the transaction flow. Monitoring them closely makes it easier to catch formatting errors before they lead to delays or chargebacks.

Orderful can automatically send a 997 as soon as an inbound document is received (set per relationship as your acknowledgment policy) and flags rejected transactions as soon as validation runs. Pixel supports teams that prefer a browser-based EDI workflow, while Mosaic gives developers API-driven control over transaction processing and acknowledgment tracking.

Book a demo with our team