EDI 997 and 999: what the acknowledgments mean

An EDI 997 is a Functional Acknowledgment transaction set that confirms a functional group of X12 documents arrived intact and passed basic syntax checks. An EDI 999 does the same job at a deeper level, validating the transaction against a specific implementation guide rather than just the base X12 standard. Neither one tells you whether the business content was accepted.

What is an EDI functional acknowledgment?

Think of it as a delivery receipt for the translator, not for the person reading the invoice. When your ERP sends an 810 invoice and the retailer's system sends back a 997, all you've confirmed is that an EDI transaction, or group of transactions, was received by the remote party, and your document arrived and was processed by the recipient's EDI translator. That's it.

EDI 997 is sent by the receiver of an EDI document to confirm that the document reached the receiving EDI process and was checked against EDI syntax rules. The 999 exists for the same purpose but sits one layer deeper. The EDI 999 transaction set is an Implementation Acknowledgement document, developed specifically to replace the 997 Functional Acknowledgement document for use in healthcare. Both are control-layer documents. Neither is a business response, and confusing that distinction is where most new EDI analysts trip up.

997 vs 999: what's actually different

The short version: a 997 tells you the envelope arrived and the punctuation is correct. A 999 tells you that plus whether the specific fields required by your trading partner's implementation guide are actually populated correctly.

If you work in retail or manufacturing, you'll most often encounter 997. If you work in healthcare (HIPAA), you'll almost always need 999. That single line explains why most supply chain EDI shops never touch a 999 in production, while every payer and provider system is built around it.

What it does not tell you

This is the part that catches people out during go-live weeks. A 997 (or 999) confirms structure, not agreement. When you receive an EDI 997 in response to a transaction you sent previously, you only know that your document arrived and was processed by the recipient's EDI translator. It does not provide any indication that the trading partner agrees with the contents of the prior transaction, or that the transaction met all their business requirements. For example, a 997 sent in response to an EDI 810 (Invoice) transaction does not indicate that the pricing or terms in the invoice were accepted, only that that invoice transaction was received and identified.

That's a different job from a business-level acknowledgment. EDI 855, also known as the Purchase Order Acknowledgment, is a response to the receipt of a purchase order, while EDI 997 focuses on verifying the integrity and accuracy of the original transaction set, without consulting or parsing the "business content" of the transaction. The same logic applies further down the chain in transport: a functional acknowledgment on a 210 freight invoice or a 214 shipment status update only means the message parsed. Whether the carrier actually agrees with the accessorial charges, or whether the shipment status matches reality, is a separate conversation entirely.

Worked example: a functional group of invoices

Retail EDI programs make this concrete. Lowe's uses EDI 997 to transmit acknowledgments to its trading partners to confirm receipt of all inbound EDI transactions, returning an EDI 997 Functional Acknowledgment within 15 minutes from receiving the transaction, with one 997 transmitted per group of documents sent. Depending on setup, Lowe's will send a Summary 997 using just AK1 and AK9 to acknowledge each group of transactions, or a Detail 997 using AK1, AK2, AK5, and AK9 when the trading partner has requested detail-level acknowledgment for each inbound document.

Picture a manufacturer sending a functional group with two 810 invoices to a retail partner in one transmission. A simplified Detail 997 response might look like this, illustrating the segment mechanics rather than any single vendor's actual file:

ST*997*0001
AK1*IN*4501
AK2*810*000112
AK5*A
AK2*810*000113
AK3*DTM*3
AK4*2*373*3
AK5*R*5
AK9*E*2*2*1
SE*9*0001

Here the first invoice (control number 000112) comes back accepted, but the second (000113) is rejected because a DTM date segment failed element 373, likely a bad date format. A: Accepted means the transaction set was accepted. E: Accepted with errors means the transaction set was accepted, but errors were found. R: Rejected means the transaction set was rejected and typically needs correction and resubmission. With a 999 instead, the same failure wouldn't just flag the transaction as rejected. It would point to the exact segment and element, similar to how an IK3 segment references the failing segment position and an IK4 segment identifies the specific data element and error code, saving the manufacturer's EDI analyst from manually scanning the raw 810 for a date field mismatch.

Where this sits in a transport and logistics EDI stack

In freight and 3PL environments, 997/999 traffic runs underneath the documents planners actually look at: the 204 tender, the 214 status update, the 210 freight invoice. The acknowledgment layer answers one narrow question before anyone opens the business document: did the file land, and was it readable? If a carrier never sends back a 997 for a 214, the shipper has no proof the status update was even parsed, regardless of whether the shipment itself moved on schedule.

Watching for missing acknowledgments used to mean someone manually checking a translator's log every morning. Most TMS and multi-carrier connectivity platforms now surface this automatically instead of leaving it to raw EDI logs, whether that's Cargoson consolidating carrier acknowledgments into one dashboard, or platforms like MercuryGate, Descartes, Transporeon, Alpega, Oracle Transportation Management, and ShipEngine doing similar exception alerting across their own carrier networks. The acknowledgment itself hasn't changed; what's changed is who's watching for it.

FAQ

• Is EDI 997 mandatory under the X12 standard? No. While not mandatory, the EDI 997 is highly recommended for transactional reliability, and some trading partners may insist on receiving one to ensure the integrity of their EDI exchanges. It's enforced through the trading partner agreement, not the standard itself.
• Does EDI 999 replace 997 everywhere? No. It's effectively mandatory in HIPAA transactions but rare outside healthcare. Retail and manufacturing partners almost always use 997; healthcare partners almost always need 999.
• What happens if I never send a 997 or 999 back? The sender may not know whether the trading partner's EDI process received or validated the document at all, and the cause could be a transmission failure, partner processing delay, configuration issue, or acknowledgment routing problem, so integration teams should monitor for missing acknowledgments and follow up based on SLA requirements.
• Is there an EDIFACT equivalent? Yes. The closest EDIFACT equivalent is the CONTRL message, which is used to acknowledge receipt and validation of EDI messages just like the 997.
• Can a 997 itself be acknowledged? No. Neither the 997 nor the 999 acknowledgment shall be acknowledged, which prevents an endless cycle of acknowledgments of acknowledgments.

If you're not currently monitoring for missing 997s or 999s as their own exception category, separate from business-document errors, that's the first gap worth closing. A missing invoice is a business problem. A missing functional acknowledgment is a plumbing problem, and it's usually the cheaper one to fix if you catch it early.