EDI 999 Acknowledgment Results — Data Dictionary

This page explains the unified 58-field Smart Mapping schema for supported X12 EDI 999 files.

Use it to understand transaction acceptance, functional-group status, and the segment or element associated with a reported implementation error.

Download the 999 Results Data Map

CSV/Excel mapping of all 58 output columns and their EDI 999 sources. The map itself contains no PHI.

Download CSV Map Download Excel Map

Column Definitions

Applies to the Client-Side EDI 999 acknowledgment-results layout
Column EDI Source Description
File Name N/A (converter) Name of the input 999 EDI file. Useful when processing acknowledgments from multiple files.
ID N/A (converter) Converter-generated stable row identifier based on the private physical source occurrence; it is not source-supplied and is not an AK2 control number.
Transaction Type ST01 Transaction set identifier from ST01. Expected to be 999 for an Implementation Acknowledgment.
Record Type N/A (converter; derived from AK2/IK3/IK4/AK9 hierarchy) Identifies the output row as a transaction result, error detail, or functional-group summary.
Issue Number N/A (converter) Sequential issue number assigned within the acknowledged transaction set or functional group.
Acceptance Result IK501 / AK901 (normalized) Human-readable acceptance result derived from the transaction-level IK5 code or group-level AK9 code, such as Accepted, Accepted with Errors, Partially Accepted, or Rejected.
Error Level IK4 / IK3 / IK5 / AK9 (derived) Highest applicable level of the reported problem: Data Element, Segment, Transaction Set, or Functional Group.
Error Summary IK3/IK4/IK5/AK9 codes and context (derived) Concise human-readable summary generated from the reported acknowledgment code, error code, and available location/context information.
Error Location IK301-IK303 / IK401-1-IK401-3 / CTX (derived) Readable location of the reported issue, assembled from the loop, segment, segment position, element position, component position, repeating data-element position, and available context.
Primary Error Code IK403 / IK304 / IK502-IK506 / AK905-AK909 (derived) Most specific available error code for the row. Element-level codes take priority, followed by segment-, transaction-, and group-level codes.
Primary Error Description Code translation (derived) Human-readable description corresponding to the Primary Error Code. The raw code remains the source of truth.
Original Functional Identifier AK101 Functional identifier code of the original functional group being acknowledged, such as HC for health care claims.
Original Group Control Number AK102 Group control number of the original functional group being acknowledged. This should correspond to GS06 in the original transmission.
Original Group Version AK103 Version, release, and implementation-guide identifier of the original functional group, when provided.
Original Transaction Set ID AK201 Transaction set identifier of the original transaction being acknowledged, such as 837.
Original Transaction Control Number AK202 Control number of the original transaction set being acknowledged. This should correspond to ST02 in the original transaction.
Original Implementation Reference AK203 Implementation convention reference for the original transaction set, when provided.
Transaction Acknowledgment Code IK501 Raw transaction-set acknowledgment code reported for the original transaction.
Transaction Acknowledgment Description IK501 code translation Human-readable meaning of the transaction acknowledgment code, such as Accepted or Rejected.
Transaction Error Codes IK502-IK506 Implementation transaction-set syntax error codes reported for the acknowledged transaction in source position order. Repeated identical physical codes remain distinct summary occurrences even though the flat display list is value-deduplicated.
Transaction Error Descriptions IK502-IK506 code translations Human-readable descriptions of the transaction-set error codes in source position order; summary occurrence counts retain every populated IK5 error position.
Segment ID IK301 Identifier of the segment reported in error in the original transaction, such as CLM, NM1, or REF.
Segment Position IK302 Position of the reported segment within the original transaction set. This is a transaction-set segment position, not necessarily a physical file line number.
Loop ID IK303 Implementation-guide loop identifier associated with the reported segment error, when supplied.
Segment Error Code IK304 Raw implementation segment syntax error code reported for the segment.
Segment Error Description IK304 code translation Human-readable description of the segment error code.
Element Position IK401-1 Position of the data element within the segment, taken from the first component of the IK401 position composite.
Component Position IK401-2 Position of the component data element within a composite, when applicable, taken from the second component of IK401.
Data Element Repetition Position IK401-3 Repeating data-element position reported in the third component of IK401, when supplied. This is distinct from element and component position.
Data Element Reference Number IK402 X12 data element reference number associated with the reported element error, when supplied.
Element Error Code IK403 Raw implementation data-element syntax error code reported for the element.
Element Error Description IK403 code translation Human-readable description of the data-element error code.
Bad Data Value IK404 Copy of the invalid or problematic source value when included in the 999. This value may contain sensitive or protected health information.
Business Unit Reference CTX01-1 (business-unit CTX) Reference name identifying the business unit associated with the error. For an acknowledged 837 this is often CLM01.
Business Unit Identifier CTX01-2 (business-unit CTX) Identifier value for the business unit associated with the error, such as the CLM01 claim submitter identifier when supplied.
Segment Error Context CTX segment(s) associated with IK3 Exact CTX element text associated with the segment error, preserving source text, case, physical order, and duplicates. Smart de-identification protects sensitive content when enabled.
Element Error Context CTX segment(s) associated with IK4 Exact CTX element text associated with the element error, preserving source text, case, physical order, and duplicates. Smart de-identification protects sensitive content when enabled.
Group Acknowledgment Code AK901 Raw functional-group acknowledgment code reported for the original functional group.
Group Acknowledgment Description AK901 code translation Human-readable meaning of the functional-group acknowledgment code, such as Accepted, Accepted with Errors, Partially Accepted, or Rejected.
Transactions Included AK902 Source-reported number of transaction sets included in the original functional-group trailer; this is not reconciled to detailed AK2 rows.
Transactions Received AK903 Source-reported number of transaction sets received by the acknowledgment sender; this is not reconciled to detailed AK2 rows.
Transactions Accepted AK904 Source-reported number of received transaction sets accepted at the implementation-acknowledgment level; this is not reconciled to detailed AK2 rows.
Transactions Rejected AK903 - AK904 (derived) Derived as source-reported received minus source-reported accepted. Negative arithmetic is preserved when source counts are internally impossible; blank when either source count is missing or nonnumeric.
Group Error Codes AK905-AK909 Functional-group syntax error codes in source position order. Repeated identical physical codes remain distinct summary occurrences even though the flat display list is value-deduplicated.
Group Error Descriptions AK905-AK909 code translations Human-readable descriptions of the functional-group error codes in source position order; summary occurrence counts retain every populated AK9 error position.
999 Transaction Control Number ST02 Transaction set control number assigned to the 999 acknowledgment itself.
999 Implementation Reference ST03 Implementation convention reference for the 999 transaction. Smart routing supports exact 005010X231 and 005010X231A1 references under the documented ST03/GS08 fallback rule.
999 Group Control Number GS06 Functional-group control number of the group containing the 999 transaction.
999 Group Version GS08 Version, release, and implementation-guide identifier of the functional group containing the 999.
Interchange Control Number ISA13 Interchange control number assigned to the interchange containing the 999.
Functional Group Sender Code GS02 Application sender code for the functional group containing the 999.
Functional Group Receiver Code GS03 Application receiver code for the functional group containing the 999.
Interchange Sender Qualifier ISA05 Qualifier identifying the type of interchange sender identifier used in ISA06.
Interchange Sender ID ISA06 Interchange sender identifier from the 999 envelope. Fixed-width padding should be trimmed for display/export.
Interchange Receiver Qualifier ISA07 Qualifier identifying the type of interchange receiver identifier used in ISA08.
Interchange Receiver ID ISA08 Interchange receiver identifier from the 999 envelope. Fixed-width padding should be trimmed for display/export.
999 Creation Date GS04 Date the 999 functional group was created. This should not automatically be treated as the date the original transaction was received.
999 Creation Time GS05 Time the 999 functional group was created.

Notes

  • A 999 confirms whether an implementation was accepted, accepted with errors, or rejected; it is not a claim-adjudication or payment response.
  • Exact Smart routing: ST01 must be 999. A nonblank ST03 must be exactly 005010X231 or 005010X231A1; only blank ST03 may fall back to an exact supported GS08. Near matches and unsupported references are Raw-only.
  • The one unified 58-field Smart schema has no separate Key schema and is a bounded, non-exhaustive X231/X231A1 projection, not a lossless hierarchy.
  • Hybrid row grain: one row per IK4; an IK3 without IK4; an AK2 without IK3; or a group-summary row when no AK2 exists. Converter-generated ID is based on private physical occurrence identity and is not source-supplied. AK1 supplies functional-group context; each physical AK2 is a distinct acknowledged transaction occurrence even when visible controls repeat.
  • IK301/IK302/IK303/IK304 are segment ID, segment position, loop identifier, and segment syntax error. IK401-1, IK401-2, and IK401-3 map element, component, and repeating data-element positions using ISA16; IK402 is the data-element reference, IK403 the syntax error, and IK404 the bad-data copy.
  • CTX is situational contextual evidence owned by a valid preceding IK3 or IK4. Smart output preserves exact source text, case, physical order, and duplicates; malformed or unowned CTX is omitted from Smart output and retained in Raw.
  • Summary counts physical AK2 transactions, IK3 segment errors, IK4 data-element errors, and every populated IK502-IK506/AK905-AK909 position independently. Repeated identical codes remain separate occurrences.
  • AK902 Included, AK903 Received, and AK904 Accepted are source-reported. Rejected is derived as AK903 minus AK904; negative source arithmetic is retained and flagged, and AK9 counts are not reconciled to AK2 detail.
  • Validation enforces the enabled X231/X231A1 structure: AK1 and AK9 are required singletons; IK5 is a required singleton under AK2; IK3 is situational; IK4 is situational under IK3; CTX is situational; and AK902-AK904 are required when AK9 is present. High-confidence ordering requires AK2 after AK1, IK3 under AK2, IK4 under IK3, IK5 after its AK2 error detail, and AK9 as final group summary; this is not exhaustive grammar validation.
  • Enabled code tables: IK304: 1-8, I4, I6-I9; IK403: 1-10, 12, 13, I6, I9-I13; IK501: A, E, M, R, W, X; IK502-IK506: 1-13, 15-19, 23-27, I5, I6; AK901: A, E, M, P, R, W, X; AK905-AK909: 1-6, 10-19, 23-26. Unknown reported codes remain visible as unknown; enabled validation reports them.
  • Privacy: De-identify PHI protects Smart rows, Summary, validation presentation, and CSV/JSON/XLSX/XML downloads. Bad Data Value, business-unit identifiers, and CTX can contain PHI. Raw segments preserves identified original segment rows, bypasses the 58-field Smart projection and 999 Smart Summary/validation, and is not de-identified.
  • Unsupported breadth: TA1, additional optional X231 structures, payer/partner companion rules, and lossless hierarchical export are outside the current result schema.
Parse an EDI 999 into structured fields.
Browse the other Client-Side EDI data maps and tutorials.