EDI 999 Implementation Acknowledgment Explained

The EDI 999 is a 997 that also checks your file against the partner's implementation guide. A 997 tells you whether a document follows the X12 standard. A 999 can also tell you that a value the standard allows is one your partner's guide does not, that a segment the guide makes required is missing, or that a field breaks the guide's format rules. Those are the rejections that confuse people, because the file looks valid to every generic X12 validator.

This guide covers what the 999 reports, how it differs from the 997, every segment you will read, two live examples (an accepted 850 and a rejected one), the IK3 and IK4 error codes, and how to work a 999 rejection back to the field that caused it.

What Is an EDI 999?

An EDI 999 is the Implementation Acknowledgment transaction set defined by the ASC X12 standards body for version 005010 and later, used to report whether each transaction set in a received functional group was accepted, accepted with errors, or rejected, measured against both the X12 standard and the implementation guide the sender declared. The implementation guide for the 999 itself is the X12 technical report 005010X231, most often used in its errata version 005010X231A1, which is the value you will see in GS08 and ST03.

Authoritative references for 999 work:

• The X12 transaction set catalog defines the 999 and its segments, including the IK3, IK4 and IK5 error segments and the CTX context segment
• Published 999 companion guides, such as the Wisconsin Department of Health Services 999 companion guide, show how a receiver fills each element and include worked examples of accepted and rejected transactions
• Your trading partner's own guide says whether it sends a 997 or a 999, and which version of each document it validates against

Who sends it? Whoever received the functional group: a retailer acknowledging your 856 or 810, or you acknowledging a customer's 850.

Who receives it? The original sender.

When is it sent? Shortly after the receiver's translator validates the file, usually automatically.

Why does it matter? A rejected transaction set in a 999 was not processed. If nobody reads the 999, the 850, ASN or invoice it refers to simply never happened as far as the partner is concerned.

The 999 is common in healthcare, where the HIPAA 5010 transactions use it as the standard acknowledgment. Outside healthcare, some retail and supply chain partners that run on 5010 also send it in place of the 997. The spelling varies in searches ("999 acknowledgement"), but the X12 name uses "acknowledgment".

EDI 999 vs 997

Both acknowledge receipt at the functional group level and report per transaction set. The difference is what they check and how they report it. Our EDI 997 guide covers the 997 in depth.

Read it this way: the 999 keeps the 997's group-level segments (AK1, AK2, AK9) and uses IK3, IK4 and IK5 in place of AK3, AK4 and AK5. Those IK segments carry the same standard error codes as their AK counterparts, plus a set of "I" codes for implementation guide violations, and they can be followed by CTX segments that explain the situation behind an error.

What "Implementation" Means in a 999

The X12 standard defines every segment, element and code list in broad terms. An implementation guide narrows that down for one use: which segments are required, which codes are allowed, how long a field can be, and which rules depend on other fields.

A concrete example. In an 850, N103 is the identification code qualifier for the party in that N1. The X12 standard allows dozens of values, including ZZ (mutually defined). Your customer's guide might allow only 92 (buyer-assigned) and UL (GLN). If your file sends ZZ:

• A 997 checks against the standard, finds ZZ valid, and accepts
• A 999 checks against the guide, finds ZZ is not used in this implementation, and reports it with code I6

That is the whole point of the 999, and the reason a file can pass a generic validator and still be rejected.

Interactive Example: Accepted 999

A distributor, Northwind, sent purchase order group 4471 containing one 850 to its supplier, Ridgeline. Ridgeline's translator validated it and returned this 999. AK1 names the group (PO, control number 4471, version 005010), AK2 names the transaction set (850, control number 0001), IK5*A accepts it, and AK9*A*1*1*1 accepts the group: one included, one received, one accepted.

Use the Plain English tab for a readable summary, or click any segment to break it down element by element.

Interactive Example: Rejected 999 With a Segment Error

The next PO, group 4472, comes back rejected. Its fifth segment (counting ST as 1) was an N1 ship-to whose N103 qualifier was ZZ.

• IK3*N1*5**8 points to the N1 segment at position 5 and says it has data element errors (code 8)
• IK4*3*66*I6*ZZ names element 3 of that segment (data element 66, the identification code qualifier), gives error I6 (code value not used in the implementation) and copies the bad value ZZ
• IK5*R*I5 rejects the transaction set because of implementation errors in one or more segments
• AK9*R*1*1*0 rejects the group: one received, none accepted

999 Structure at a Glance

The functional group code in GS01 is FA, the same as for a 997. The version in GS08 (005010X231A1) is how a translator tells a 999 group apart from a 997 group.

Key Segments Explained

AK1: Functional Group Response Header

AK1*PO*4472*005010~

AK2: Transaction Set Response Header

AK2*850*0001~

Match acknowledgments to what you sent on the pair AK102 and AK202 (group control number and transaction set control number), the same way as for a 997.

IK3: Error Identification

IK3*N1*5**8~

IK304 error codes

Codes 1 to 8 match the 997's AK304 list. The "I" codes are the ones only a guide-aware check can produce: a segment the guide marks "Not Used" was sent, or a segment the guide requires in a given situation was missing. Code 8 means "look at the IK4 segments that follow".

IK4: Implementation Data Element Note

IK4*3*66*I6*ZZ~

IK403 error codes

Two of these deserve a note. Code 7 means the value is not in the X12 code list at all. Code I6 means the value is valid X12 but not in the subset your partner's guide allows. The fix for 7 is usually a typo; the fix for I6 is reading the partner's guide for that element. Code I12 means the value broke a format rule in the guide, for example a pattern for an identifier.

CTX: Context

CTX is the one segment with no equivalent in the 997. It appears after an IK3 or an IK4 and adds context in one of two ways:

• Situational trigger. Many guide rules are conditional: "this segment is required when that element has this value". When the receiver reports a missing or unexpected segment or element because of such a rule, a CTX can point to the segment and element whose value triggered the rule. Its first element starts with the text SITUATIONAL TRIGGER.
• Business unit identifier. A CTX can also name the business record that failed, by an element name and its value from your file, so you can find it without counting segments.

The CTX structure is the same in both uses: a context name and reference, then the triggering segment ID, its position, its loop, the position within that segment and the element reference. Which of these a receiver fills in is set by the 999 implementation guide and the receiver's own companion guide. Retail partners send CTX far less often than healthcare payers do.

IK5: Implementation Transaction Set Response Trailer

IK5*R*I5~

IK501 codes: A accepted, E accepted but errors were noted, M rejected because the message authentication code failed, R rejected, W rejected because assurance failed validity tests, X rejected because content after decryption could not be analyzed.

The most common IK502 reasons are 5 (one or more segments in error), I5 (implementation one or more segments in error), 4 (the segment count in SE does not match), 3 (the control numbers in ST and SE do not match) and I6 (the implementation convention named in ST03 is not supported).

AK9: Functional Group Response Trailer

AK9*R*1*1*0~

P matters most in practice. A partially accepted group means some transaction sets went through and others did not, and you have to read each IK5 to find out which.

How to Read a 999 Rejection

1. Find the group. Match AK102 to the GS06 of the file you sent.
2. Find the transaction set. Match AK202 to the ST02. If several AK2 loops are present, check each IK5.
3. Find the segment. Count from your ST (as position 1) to the IK302 position. Do not count from ISA or from the top of the file.
4. Find the element. IK401 is the element position in that segment. IK404, when present, shows you the value that failed.
5. Decode the error. Plain numbers are standard X12 errors. "I" codes are implementation guide errors, so the fix is in the partner's guide, not the X12 standard.
6. Read any CTX. It names the field that triggered a conditional rule, or the business record that failed.
7. Fix and resend. Correct the data or the map, and resend the transaction set with new control numbers.

The EDI rejection explainer does most of this for you: paste the 999 and it explains every error code in plain English and locates each one in your original file. The free EDI inspector parses the original file segment by segment, so you can see the values at the reported position.

999 vs TA1, 997 and 824

Four documents can tell you something went wrong. They check different layers.

A clean 999 means the file was structurally right for the guide. It does not mean the partner accepted the order, shipment or invoice as a business matter. That still comes later, through an 855, an 824, or a payment that does or does not arrive.

Common Causes of 999 Rejections

Handling 999s in Production

• Reconcile every outbound group. Match each 999 to the group and transaction set it answers, on group control number and transaction set control number. Alert on groups with no acknowledgment inside the partner's window.
• Treat E with care. "Accepted with errors" means the partner processed the document, but something is wrong that may fail next time or under a stricter partner.
• Read partial acceptances line by line. An AK9*P hides one or more rejected transaction sets inside a group that looks mostly fine.
• Fix the map, not just the file. An "I" code usually means the map is wrong for this partner, so every future document will fail the same way until the map changes.
• Keep the 999s. They are your record that a document was received and accepted, which matters when a partner later says it never got an ASN or an invoice.

999 Implementation Checklist

• Confirm with each partner whether it sends a 997 or a 999, and in which version
• Make sure your translator accepts GS08 005010X231A1 groups and routes them to the same tracking as 997s
• Get the partner's implementation guide for every document you send, and build code lists from it
• Map IK304, IK403 and IK502 codes, including the "I" codes, to readable messages for your team
• Alert on rejected (R) and partially accepted (P) groups, and on missing acknowledgments
• Decide who owns fixing a rejection: the person who keyed the data, or the person who owns the map
• If you receive documents on 5010, decide whether you will send a 999 or a 997 back, and confirm it with the partner

Getting Fewer 999 Rejections With OrderSync

Most 999 rejections trace back to data that was never checked against the partner's rules before it went out: an order keyed from a PDF with a ship-to code the customer does not use, or an item number that does not match the catalog.

OrderSync reads inbound orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches customers, stores, items and units to your records, and outputs valid X12 or clean data for your ERP, so problems are caught before a document is built from them. Paste any 999 or 997 into the free EDI inspector to see what was rejected and why, read more about multi-format order processing, or book a 15-minute walkthrough to see your own orders processed.

Frequently Asked Questions