The foundational handshake of every EDI relationship - an automated reply that confirms a transaction set was received and is syntactically valid, or reports exactly which segments and elements failed so the sender can fix and resend.
The EDI 997 Functional Acknowledgment is the universal confirmation layer of the X12 EDI standard. Every time one trading partner sends any transaction set - a 850 Purchase Order, a 856 ASN, a 810 Invoice, a 214 shipment status, or any other - the receiving system sends back a 997 to confirm that the envelope was received and that the transaction is syntactically valid (correct structure, valid element lengths, proper segment sequences, required fields present).
The critical distinction: a 997 is not a business-level acknowledgment. An "accepted" 997 means the EDI structure passed validation - it does not mean the purchase order was approved, the invoice was matched, or the ASN was processed against open orders. Business-level responses come from different documents (an 855 Purchase Order Acknowledgment responds to an 850; an 865 confirms a PO change order; application-level errors use the 824). The 997 only addresses the EDI envelope itself.
When a 997 comes back with a rejection, it contains an AK5 acknowledgment code of R (rejected) along with AK3 and AK4 segments pointing to the exact segment position, element number, and error code that caused the rejection. This makes 997 rejections actionable - a skilled EDI team can pinpoint and fix the problem immediately. Common rejection causes include missing mandatory segments, element values that exceed allowed lengths, invalid code values, and wrong transaction set ID numbers.
The 997 is universal - it exists in every industry that uses X12 EDI. Retail, healthcare, transportation, financial services, manufacturing, government procurement - any organization sending or receiving X12 transaction sets exchanges 997s. Unlike most transaction sets that are specific to a workflow, the 997 is infrastructure. Most EDI platforms generate and process 997s automatically without requiring any manual configuration per trading partner.
Suppliers sending 850-triggered documents (856 ASNs, 810 invoices) wait for 997 acceptance before treating their transmission as confirmed. A 997 rejection means the document didn't reach the trading partner's business system - the supplier must fix the error and resend before the retailer's system has visibility. Missing this loop results in late ASN chargebacks and invoice payment delays even when the physical goods arrived on time.
Retailers generate 997s for every inbound transaction from suppliers and carriers. Their EDI platforms are configured to auto-accept well-formed documents and return 997 rejections with specific error codes when structural issues are found. Retailer trading partner portals typically expose 997 status - suppliers can see whether their transmissions were accepted or rejected without needing to call EDI support.
Carriers sending 214 status messages and 210 invoices receive 997s from shippers confirming the status data landed in the TMS or FAP system. 3PLs exchanging 940/945 and 943/944 documents with depositors use 997s to confirm the operational order-flow documents were received - a rejected 997 on a 940 means the 3PL's WMS never saw the shipping order, and fulfillment is at risk without immediate re-transmission.
Identifies the functional group being acknowledged. AK101 = functional identifier code (e.g., PO for purchase orders, SH for ship notices, IN for invoices - matching the GS01 of the received document), AK102 = group control number (matching GS06 of the received group). One AK1 per 997 transaction, linking this acknowledgment to exactly one incoming functional group. This is how the sender matches the 997 back to a specific batch of documents they sent.
Identifies the specific transaction set within the group being acknowledged. AK201 = transaction set ID (e.g., 850, 856, 810), AK202 = transaction set control number (matching ST02 of the received transaction). One AK2/AK5 loop per transaction set in the group. When a functional group contains 50 purchase orders, the 997 includes 50 AK2/AK5 loops - one per PO - allowing individual document-level acceptance or rejection within a single batch.
Reports errors at the segment level when a transaction is rejected. AK301 = segment ID code (which segment has the error, e.g., BEG, N1, PO1), AK302 = segment position in transaction set (which occurrence of that segment), AK303 = loop identifier code, AK304 = segment syntax error code (1 = unrecognized segment, 2 = unexpected segment, 3 = mandatory segment missing, 4 = too many occurrences, 8 = segment has data element errors). AK3 tells the EDI developer exactly where to look.
Reports errors at the element level within a failing segment. AK401 = element position (which element in the segment), AK402 = element reference number (from the X12 standard), AK403 = data element syntax error code (1 = mandatory element missing, 2 = conditional element missing, 3 = too many data elements, 4 = data element too short, 5 = data element too long, 6 = invalid code value, 7 = invalid date, 8 = invalid time). AK404 = copy of the invalid element value for reference.
Closes the AK2 loop and delivers the verdict for that transaction set. AK501 = transaction set acknowledgment code: A = accepted, E = accepted but errors were noted (rare, partner-specific), R = rejected. AK502–AK506 = error codes (up to five) summarizing why the transaction was rejected. The AK501 code drives automation: A means the downstream system can proceed; R means re-transmission is required after fixing the reported errors.
Closes the 997 and provides group-level summary. AK901 = functional group acknowledge code (A = accepted, R = rejected, P = partially accepted - some transactions accepted, some rejected), AK902 = number of transaction sets included, AK903 = number received, AK904 = number accepted. AK905–AK909 = group-level error codes. AK901 of P is important - it means a mixed batch was sent and only some documents made it through, requiring selective re-transmission of the rejected subset.
The 824 is the business-level complement to the 997. Where a 997 confirms syntactic validity of the EDI envelope, an 824 reports application-level errors - a purchase order that references an invalid vendor number, an invoice that doesn't match any open PO, or an ASN with a GTIN that isn't in the item master. Not all trading partners use 824, but where implemented, it closes the loop the 997 can't.
The 997 can acknowledge any X12 transaction set - purchase orders (850), ship notices (856), invoices (810), remittance (820), and all the transportation and warehouse documents described elsewhere in this library. The functional identifier code in AK101 identifies which document type is being acknowledged in each 997 functional group response.
The 999 is the newer X12 standard (introduced in version 005010) that replaces the 997 with an expanded acknowledgment framework that also validates documents against a trading partner's specific implementation guide - not just base X12 syntax. Healthcare (HIPAA) mandates the 999 for 5010 transactions. Many retail and general supply chain implementations still use 997 for backward compatibility.
Better EDI monitors 997 acknowledgment status across all your trading partners - with automated re-transmission workflows and real-time alerts for rejections so nothing falls through the cracks.
Talk to an EDI Expert