AK1
Functional group response header: the functional identifier and group control number being acknowledged.
The receipt that says an EDI transmission arrived and was parsed, with any syntax errors found. Receiver back to sender, for almost every X12 document. This page covers what the 997 is for, the segments you meet when you open one, the documents it travels with, where it tends to go wrong, and how it moves over AS2 into your systems on Files.com, which receives, parses, validates, and routes it as configuration.
No credit card required · 7-day free trial · Live in minutes
The 997 is EDI’s return receipt. When a system receives an X12 functional group, it sends a 997 back to say the group arrived and whether each transaction set inside it was accepted, accepted with errors, or rejected at the syntax level. It says nothing about business content: a 997 can accept an 850 whose PO number the buyer will later reject on an 855.
Most trading-partner agreements require a 997 within a set window, and a missing one is treated as a failed delivery. That is why the 997 is the document EDI operations teams watch hardest: the count of 997s expected versus received is the daily health check of an exchange.
In document order, the segments that carry the 997's meaning. A partner's implementation guide says which are required and which fields each must hold.
Functional group response header: the functional identifier and group control number being acknowledged.
Transaction set response header: the transaction set and control number being acknowledged.
Data segment note: a segment in error, with its position.
Data element note: the element in error and the error code.
Transaction set response trailer: accepted, accepted with errors, or rejected.
Functional group response trailer: the overall result and counts of sets included, received, and accepted.
Treating a 997 as business acceptance. It is not; the 855 and 824 carry the business answer. The operational failure is the reverse: a partner who never sends 997s, or sends them late, leaves the sender unable to prove delivery, which is why teams pair EDI-level 997 tracking with a transport-level receipt such as the AS2 MDN.
The 997 rarely moves alone. These are the documents that precede, answer, or settle it.
A buyer’s order to a supplier: the items, quantities, prices, dates, and ship-to locations.
See The 850The supplier’s bill for goods or services delivered against a purchase order.
See The 810The advance ship notice: what is in the shipment, how it is packed, and how it is labeled, sent before it arrives.
See The 856A payer’s notice of payment: which invoices are being paid, for how much, and how.
See The 820A business-level accept or reject of a received document, with the reasons, beyond what a 997 can say.
See The 824A partner sends the 997 over AS2, SFTP, or FTPS, and it lands in that partner’s inbox folder on Files.com with the transport receipt recorded. From there it is a workflow, not a project: TransformScript parses the X12 natively into the JSON, CSV, or XML your ERP or WMS reads, content validation flags a document whose contents are wrong before anything ingests it, and an automation routes the result to the system and the people who act on it.
Outbound is the mirror image. Your system exports its record, TransformScript builds the 997 the partner’s guide specifies, and the file dropped in the partner’s outbox goes out over AS2 with automatic retries until the MDN confirms delivery. Every transmission in both directions is in the audit log, and delivery monitoring alerts when a 997 that was due never arrives. The full picture is on the EDI software page.
What teams ask about the 997 and how it moves on Files.com.
An EDI 997 is the X12 Functional Acknowledgment. The receiver of an EDI transmission sends it back to confirm the transmission arrived and was parsed, reporting whether each transaction set was accepted or rejected at the syntax level.
No. The 997 confirms receipt and syntax only. Business acceptance of an order comes on the 855, and business-level rejection of any document comes on the 824.
The MDN is the transport receipt: the AS2 endpoint confirms it received the exact bytes sent. The 997 is the EDI receipt: the translator confirms the X12 inside parsed. Mature exchanges track both.
Yes. Files.com is a standards-compliant RFC 4130 AS2 endpoint, and a 997 sent by a trading partner lands in that partner’s inbox folder with a signed MDN receipt returned to the sender. Partners who exchange over SFTP or FTPS connect to the same platform and the document lands in the same place.
Yes. TransformScript parses the X12 997 natively and writes the JSON, CSV, or XML your systems ingest, as a step in the workflow that fires when the document arrives. Outbound, the same engine builds a 997 from your system’s export and drops it in the partner’s outbox for delivery.
Start the 7-day trial, turn AS2 on, and exchange certificates with your partner. The 997 lands in their folder, parses into the record your system reads, and every transmission carries a signed receipt.
No credit card required • Free for 7 days • Live in minutes