X12 transaction guide · Acknowledgments
EDI 997 Functional Acknowledgment
The X12 document a receiver sends back to confirm that EDI documents arrived and were syntactically valid.
- Sent by
- Receiver of any EDI document
- Received by
- Original sender
- Standard
- ANSI ASC X12
- EDIFACT equivalent
- CONTRL
What is an EDI 997?
The EDI 997 Functional Acknowledgment is the ANSI X12 transaction set a receiver returns to confirm that it received a functional group of EDI documents and whether they passed syntax checks. It reports acceptance or rejection at the group and transaction set level and can identify segment and element errors.
A 997 does not confirm business acceptance. It does not mean an order was accepted, a shipment was received or an invoice was approved; it only confirms that the document arrived and could be read. Monitoring for missing or rejected 997s is still one of the most effective ways to catch communication problems early.
How to read this diagram: the top row shows who sends the 997, to whom, and which documents usually come before and after it. The lower part shows what X12 release 004010 itself requires: the envelopes around the 997 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.
When it is used
- Confirming receipt of purchase orders, ship notices, invoices and other documents
- Reporting syntax errors so the sender can correct and resend
- Reconciling sent documents against acknowledgments to find gaps
Where it fits in the document flow
Structure
Key segments in the 997
The segments most implementations use, described in plain language. The last column shows what X12 release 004010 itself requires: "Required" marks a segment the standard requires in every 997; "Optional, common" marks a segment the standard leaves optional, or that sits in an optional loop, but that implementations often use. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, makes some optional segments mandatory and restricts the values, and requirements can differ between releases. The requirement status comes from one published X12 reference listing and has not been checked against a second source.
| Segment | Name | What it carries | In X12 004010 |
|---|---|---|---|
| AK1 | Functional Group Response Header | Identifies the functional group being acknowledged by its functional identifier code and group control number. | Required |
| AK2 | Transaction Set Response Header | Identifies each transaction set acknowledged by type and control number. | Optional, common |
| AK3 / AK4 | Segment and Element Notes | Point to segments and elements with errors and describe the problem. | Optional, common |
| AK5 | Transaction Set Response Trailer | Accept or reject status for each transaction set. | Optional, common |
| AK9 | Functional Group Response Trailer | Overall status for the group and counts of sets included, received and accepted. | Required |
Example
Sample EDI 997
Acknowledges functional group 1001 of purchase orders (PO). The single 850 in the group was accepted (AK5 A), and the group as a whole was accepted (AK9 A).
Illustrative data only, not tied to one X12 release or trading partner. The interchange (ISA/IEA) and functional group (GS/GE) envelopes are omitted for readability.
ST*997*0001~
AK1*PO*1001~
AK2*850*0001~
AK5*A~
AK9*A*1*1*1~
SE*6*0001~The sample is the same one shown above, with a note beside each segment the first time it appears. Segment IDs are highlighted at the start of each line; the fields after them are separated by asterisks, and each segment ends with a tilde.
Avoid problems
Common 997 errors and how to prevent them
Treating a 997 as business acceptance
A 997 confirms syntax only. Orders still need an 855 or other business response where partners require it.
Not monitoring missing acknowledgments
Documents without a 997 may never have arrived. Reconcile sent documents against acknowledgments daily.
Ignoring rejected 997s
A rejected 997 means the partner could not process the document. It must be corrected and resent.
Trading partners
Integration guides that include the 997
How ECOM helps
Automate the 997 with ECOM
Product
PRISM-SCV
Order lifecycle visibility, response monitoring, routed alerts and business-identifier search across your B2B transactions.
Solution
EDI Integration
Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.
Service
24×7 Support
Round-the-clock monitoring and incident support for EDI, B2B and MFT operations.
EDI 997 FAQs
Is a 997 the same as an 855?
No. A 997 confirms that a document was received and is syntactically valid. An 855 confirms the business details of a purchase order.
What is the difference between a 997 and a 999?
Both are X12 acknowledgments. The 999 implementation acknowledgment is used mainly in healthcare HIPAA transactions and can report implementation guide errors in more detail.
How quickly should a 997 be sent?
Many partners expect a 997 within hours of receiving a document. Exact expectations come from each partner's guide.
More general questions about EDI are answered in the EDI FAQ.
Need help with the EDI 997?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.