Raw boundary: Raw mode preserves identified original segment rows, bypasses the 58-field Smart projection and 999 Smart Summary/validation, and is not de-identified. TA1, broader optional X231 structures, payer/partner companion rules, and lossless hierarchical export remain outside the current result schema.
Current converter contract
Smart routing requires ST01=999. A nonblank ST03 must be exactly 005010X231 or 005010X231A1; only a blank ST03 may fall back to an exact supported GS08. Near matches and unsupported references are Raw-only.
Smart Mapping exposes one unified 58-field schema with no separate Key schema. It is a bounded, non-exhaustive X231/X231A1 projection with hybrid row grain: one row per IK4, an IK3-without-IK4 row, an AK2-without-IK3 row, or a group-summary row when no AK2 exists. Converter-generated ID represents private physical occurrence identity and is not source-supplied.
IK401-3 is the repeating data-element position. CTX output preserves exact source text, case, physical order, and duplicates. Summary counts physical AK2, IK3, IK4, and every populated IK5/AK9 error-code position independently; AK9 counts remain source-reported and are not reconciled to AK2 detail.
De-identification protects Smart rows, Summary, validation presentation, and CSV/JSON/XLSX/XML downloads. Raw mode preserves identified original segment rows and is not de-identified.
Implementation acknowledgment reference
What Is an EDI 999 Acknowledgment?
Understand how a 999 reports implementation-level acceptance and pinpoints segment or element errors.
An EDI 999 is an X12 Implementation Acknowledgment returned to report whether a received functional group and its transaction sets conform to the applicable implementation syntax checks. In 005010X231A1, AK1 identifies the acknowledged group; AK2 identifies a transaction set; IK3 and IK4 report segment and element error context; IK5 reports a transaction-set result; and AK9 summarizes the group result and counts. Acceptance does not prove business acceptance, claim adjudication, enrollment, eligibility, or payment.
Where the 999 fits in an EDI exchange
A receiver sends a 999 after processing an inbound X12 functional group. The sender uses it to determine whether the envelope and transaction sets passed the reported implementation checks and, if not, where to investigate. A single 999 can acknowledge several transaction sets and report different outcomes within one group.
The 999 is technical acknowledgment evidence. For healthcare claims, a later 277CA can report claim-oriented intake results, and an 835 explains adjudication and payment. Other business transactions have their own response or acceptance workflows.
Keep the original submitted group available. AK1 and AK2 controls connect the 999 to the source; IK3 and IK4 locations only become actionable when compared with that source.
How a 999 is organized
| Segment | Purpose | Reading question |
|---|---|---|
| AK1 | Identifies the acknowledged functional group and control | Which group is this response about? |
| AK2 | Identifies an acknowledged transaction set | Which ST control owns the following result? |
| IK3 | Reports segment position and error context | Which segment occurrence needs review? |
| IK4 | Reports element/component position, reference, bad data, and error code | Which value or component caused the finding? |
| IK5 | Reports the transaction-set acknowledgment result | Was this transaction accepted, accepted with errors, or rejected? |
| AK9 | Reports group outcome and received/included/accepted counts | What happened to the functional group overall? |
Read outcomes without losing error hierarchy
Start with AK9 for the group, then inspect every AK2 loop and its IK5 result. When errors exist, preserve IK3 occurrence number and segment position with any related IK4 element or component information. Do not flatten IK4 into a separate unrelated row: it refines the enclosing segment error.
Counts also matter. AK9 received, included, and accepted counts should be interpreted with the group outcome and the number of acknowledged AK2 loops. A rejection can be valid content in a structurally complete 999; it reports a problem in the transaction being acknowledged, not necessarily a malformed 999.
Synthetic EDI 999 example
ST*999*0001*005010X231A1~
AK1*HC*000001*005010X222A1~
AK2*837*000000001*005010X222A1~
IK3*NM1*12**8~
IK4*9:1:003*67*7*12345~
IK5*R*5~
AK9*R*1*1*0~
SE*8*0001~ST identifies a 999. AK1 points to the acknowledged healthcare group; AK2 points to its 837 transaction. IK3 identifies an NM1 segment occurrence and IK4 narrows the finding to an element. IK5 rejects that transaction, while AK9 rejects the group and reports one received, one included, and zero accepted. The values are synthetic and contain no protected health information.
999 compared with 277CA and business responses
A 999 reports implementation-level syntax status. A 277CA reports claim-submission acknowledgment status tied to transaction, provider, claim, or service-line context. An 835 reports claim adjudication and payment. An accepted 999 therefore means only that the transaction passed the reported implementation checks; it does not promise downstream business acceptance.
How to review a 999 in EDIFileConverter.com
- Open the EDI workspace and add an authorized 999.
- Keep Smart mapping (per file) selected and confirm 005010X231A1.
- Select Convert & Preview and begin with group, transaction, error, IK5, and AK9 fields.
- Select Open full editor for filters and occurrence-level review.
- Use Validation Results for source checks and Analysis for grouped outcomes and error patterns.
- Use Download for Excel, CSV, JSON, or XML after retaining error ownership.
Editing converted rows does not rewrite the source 999 or change the receiver’s acknowledgment.
Common 999 interpretation mistakes
Assuming accepted means approved
Implementation acceptance is not business acceptance, adjudication, or payment.
Separating IK4 from IK3
Element details must remain attached to their segment occurrence and AK2 owner.
Ignoring control numbers
Use AK1 and AK2 controls to match the correct source group and transaction.
Treating rejection content as a malformed 999
A valid 999 can legitimately report rejection of the source transaction.
Frequently asked questions
What does a 999 acknowledge?
It reports implementation-level results for a functional group and its transaction sets.
Does accepted mean approved?
No. It does not establish business acceptance or payment.
What do IK3 and IK4 identify?
IK3 identifies segment error context; IK4 adds element or component detail.
How do IK5 and AK9 differ?
IK5 is transaction-level; AK9 is group-level.