Skip to main content
Version: v0.1.10

Warning and error codes

Every code @cosyte/x12 can hand you, in three groups:

  • Fatal codes (4): parseX12 throws an X12ParseError carrying one when the input is not recoverable as X12 at all.
  • Warning codes (65): a deviation a reader tolerated, recorded on the model's warnings array with a position, while the value stays on the model.
  • Refusal codes (15 registries): a builder or a checker refused what it was given and threw a typed error carrying one.

Branch on the code, never on the message: the codes are the stable contract. This page is generated from the package source, and the docs test fails when the two differ. Tolerance tiers and warning codes explains how the tiers work, and Handle warnings shows how to triage them.

Fatal codes​

Thrown as X12ParseError, whatever strict says. Exported as FATAL_CODES.

CodeMeaning
X12_NO_ISA_HEADERThe input does not begin with an ISA, so it is not an X12 interchange.
X12_ISA_TOO_SHORTThe ISA is truncated below its fixed 106 bytes, so the delimiters cannot be read.
X12_INVALID_DELIMITERSThe delimiters cannot be recovered from the ISA.
X12_EMPTY_INPUTNothing to parse.

Warning codes​

Exported as WARNING_CODES, in the order the registry lists them. Each warning's message is one of the strings below, taken from a frozen registry and never built from the document, so a message holds no value from it; position says where to look. Where one code carries several messages, each is listed with the registry entry it comes from. ALL_WARNING_MESSAGES holds every one of them.

X12_CONTROL_NUMBER_MISMATCH​

  • X12_CONTROL_NUMBER_MISMATCH_INTERCHANGE: Control number mismatch: ISA-13 (header) and IEA-02 (trailer) disagree. Both values are preserved verbatim on the model; neither is echoed here.
  • X12_CONTROL_NUMBER_MISMATCH_GROUP: Control number mismatch: GS-06 (header) and GE-02 (trailer) disagree. Both values are preserved verbatim on the model; neither is echoed here.
  • X12_CONTROL_NUMBER_MISMATCH_TRANSACTION: Control number mismatch: ST-02 (header) and SE-02 (trailer) disagree. Both values are preserved verbatim on the model; neither is echoed here.

X12_PRE_005010​

The twelfth element of the ISA split does not read "00501", the HIPAA baseline interchange control version number, so the input may diverge from 005010 semantics. Whether that element is ISA-12 is NOT established here: where X12_ISA_EXTRA_ELEMENT_SEPARATOR is also present on this interchange the header did not split into ISA plus 16 elements, so the element read may be a displaced one. All 106 ISA bytes are preserved verbatim on isa.raw, which with the ISA fixed widths is the route back. Nothing is echoed here.

X12_ISA_EXTRA_ELEMENT_SEPARATOR​

The ISA element area carries at least one element separator beyond the 16 sitting at their fixed 005010 byte positions, so the header does not split into ISA plus 16 elements. isa.elements is that split as it came out: an element containing an extra separator comes back a prefix and everything after it is displaced. How far is NOT derivable from isa.elements, so any other ISA-derived diagnostic on this interchange may be reporting a displaced value. All 106 bytes are preserved verbatim on isa.raw, which with the ISA's fixed widths is the route back. Which reading is correct - the byte as data under the ISA's fixed widths, or as a separator - is NOT decided here, and nothing is re-framed.

X12_GROUP_COUNT_MISMATCH​

IEA-01 does not equal the number of GS..GE groups actually present in the interchange. The declared count is preserved verbatim on the model and is NEVER silently corrected.

X12_TRANSACTION_COUNT_MISMATCH​

GE-01 does not equal the number of ST..SE transaction sets actually present in the group. The declared count is preserved verbatim on the model and is NEVER silently corrected.

X12_SEGMENT_COUNT_MISMATCH​

SE-01 does not equal the number of segments actually present in the transaction set it closes. The declared count is preserved verbatim and is corrected only on serializeX12(ix, { specClean: true, recomputeCounts: true }).

X12_TRAILING_GARBAGE​

Bytes followed the IEA segment terminator, preserved verbatim on trailingBytes. Common cause: a second interchange concatenated into the same file (multi-ISA, out of v1 scope).

X12_MISSING_IEA​

Interchange has no IEA trailer - input is truncated.

X12_MISSING_GE​

Functional group has no GE trailer - group is truncated.

X12_MISSING_SE​

Transaction set has no SE trailer - transaction is truncated.

X12_DANGLING_RELEASE_CHAR​

Release character (?) appears at end of element/segment with no following byte to escape - preserved verbatim.

X12_UNEXPECTED_SEGMENT​

  • X12_UNEXPECTED_SEGMENT_TA1_INSIDE_GROUP: Unexpected segment: TA1 is envelope-level but appeared inside an open functional group, so it is NOT captured on ta1Segments and parseTA1 will not read it. It is retained verbatim on orphanSegments at the matching position.segmentIndex.
  • X12_UNEXPECTED_SEGMENT_GE_WITHOUT_GS: Unexpected segment: a GE appeared with no open functional group, so it closes nothing and no group is recorded for it. It is retained verbatim on orphanSegments at the matching position.segmentIndex.
  • X12_UNEXPECTED_SEGMENT_ST_WITHOUT_GS: Unexpected segment: an ST appeared with no open functional group (missing GS), so no transaction set is opened and nothing that follows it is bound to one. It is retained verbatim on orphanSegments at the matching position.segmentIndex.
  • X12_UNEXPECTED_SEGMENT_SE_WITHOUT_ST: Unexpected segment: an SE appeared with no open transaction set, so it closes nothing and no transaction is recorded for it. It is retained verbatim on orphanSegments at the matching position.segmentIndex.
  • X12_UNEXPECTED_SEGMENT_BODY_OUTSIDE_TRANSACTION: Unexpected segment: a body segment appeared outside any open transaction set, so it is not bound to a transaction and no get* reader will see it. It is retained verbatim on orphanSegments at the matching position.segmentIndex.

X12_835_REMIT_BALANCE_MISMATCH​

  • X12_835_REMIT_BALANCE_MISMATCH_CLAIM: 835 balance invariant violated [CLP-04 + Σ(claim CAS + line CAS) == CLP-03]: the claim does not balance. Every amount is preserved verbatim on the model as an X12Decimal and is NEVER silently rebalanced.
  • X12_835_REMIT_BALANCE_MISMATCH_SERVICE_LINE: 835 balance invariant violated [SVC-03 + Σ(line CAS) == SVC-02]: the service line does not balance. Every amount is preserved verbatim on the model as an X12Decimal and is NEVER silently rebalanced.
  • X12_835_REMIT_BALANCE_MISMATCH_REMIT_TOTAL: 835 balance invariant violated [Σ(CLP-04) - Σ(PLB amounts) == BPR-02]: the remittance total does not balance. Every amount is preserved verbatim on the model as an X12Decimal and is NEVER silently rebalanced.

X12_UNKNOWN_CARC​

Unknown CARC: the claim adjustment reason code is outside the bundled snapshot. The verbatim code is preserved on the adjustment; only its description is unavailable.

X12_UNKNOWN_RARC​

Unknown RARC: the remittance advice remark code is outside the bundled snapshot. The verbatim code is preserved on the remark; only its description is unavailable.

X12_HL_PARENT_MISMATCH​

HL-02 declares a parent id that no earlier HL in this transaction set emitted as its HL-01. The declared pointer is preserved verbatim and the hierarchy is NEVER silently re-numbered.

X12_HL_PARENT_LEVEL_INVALID​

HL-03 is inconsistent with the declared parent's HL-03 per the TR3 hierarchy. Both level codes are preserved verbatim and the hierarchy is NEVER silently re-parented.

X12_UNKNOWN_HI_QUALIFIER​

Unknown HI qualifier: the composite qualifier is outside the bundled HI_QUALIFIERS snapshot. The verbatim qualifier and code are preserved; codeSystem resolves to "unknown".

X12_MISSING_REQUIRED_LOOP​

  • X12_MISSING_REQUIRED_LOOP_2000A: Missing required loop "2000A" (Billing Provider HL): no Billing Provider HL precedes the CLM.
  • X12_MISSING_REQUIRED_LOOP_2000B: Missing required loop "2000B" (Subscriber HL): no Subscriber HL precedes the CLM.
  • X12_MISSING_REQUIRED_LOOP_2010BA: Missing required loop "2010BA" (Subscriber Name): no Subscriber Name follows the Subscriber HL.
  • X12_MISSING_REQUIRED_LOOP_2010BB: Missing required loop "2010BB" (Payer Name): no Payer Name follows the Subscriber HL.
  • X12_MISSING_REQUIRED_LOOP_270_2000A: Missing required loop "2000A" (Information Source HL) on a 270: the transaction set carries no HL segment at all, so this reader built no inquiry hierarchy for it and the returned model carries no levels. Nothing is fabricated to stand in and no level is synthesized. The verbatim segments are preserved on the transaction set; read them there before concluding the sender asked nothing.
  • X12_MISSING_REQUIRED_LOOP_270_2100: Missing required loop "2100" (the name loop of the hierarchical level at position.segmentIndex) on a 270: no NM1 follows that HL before the next one, so the level carries no name, no identifier and no demographics on the typed model. Which level it is is read off the model at that position, never from this message. Nothing is fabricated to stand in: an absent name is left absent rather than defaulted. The verbatim segments are preserved on the transaction set.
  • X12_MISSING_REQUIRED_LOOP_270_2110: Missing required loop "2110" (Eligibility or Benefit Inquiry) on a 270: the subscriber or dependent level at position.segmentIndex carries no EQ, so this reader recorded no requested service type for it and the level's inquiry list is empty. Read that literally, as a property of the READ: an empty inquiry list on a level this code names is a level the document left short of an EQ, and nothing is invented to fill it. The verbatim segments are preserved on the transaction set; read them there before concluding the sender requested nothing.

X12_837_UNKNOWN_VARIANT​

837 variant could not be resolved: ST-03's implementation convention reference is absent, empty, or not an 837 Technical Report Type 3 identifier this reader recognises, and no SVx service-line segment was present to fall back on. The set of references it recognises covers the professional, institutional and dental 837 guides HIPAA adopts at 45 CFR 162.1102 together with their published errata; it is NOT claimed to be exhaustive, and this message deliberately does not enumerate it, because a list here goes stale the moment a guide is added. A reference outside that set is not asserted to be invalid - all this code reports is that this reader could not turn it into a variant and had nothing to fall back on.

X12_837_AMBIGUOUS_VARIANT​

837 variant resolved from a service segment while the transaction body carries service segments of more than one variant: no caller type option was supplied and ST-03's implementation convention reference is absent, empty, or not an 837 Technical Report Type 3 identifier this reader recognises, so this reader fell back to the FIRST SV1 / SV2 / SV3 in the body, and a later one names a different variant. submission.variant is therefore a guess between contradictory evidence, and every claim and service line in the submission was read against it. Which service segment is the stray one is NOT decided here and is not derivable from the TR3s: this reader cannot tell a stray service segment from a conformant one, and the fallback takes the first regardless of whether any Loop 2400 was open at it, so an orphan segment decides the variant like any other. Read the bound literally, as a property of the RESOLUTION rather than of the document: this reports the fallback's own ambiguity, so a caller-supplied type, or an ST-03 this reader does turn into a variant, means no guess was made and this code is NOT raised however mixed the body is. Whatever else this reader raised on a document that reaches this code, it still raises, at the same position, and this one is added beside them. It is NOT a list of what else you will see, and it does not promise that any particular loss on such a document is reported at all. Re-read with the type option to decode the document against a variant you trust. The verbatim segments are preserved on the transaction set; read them there before acting on the submission's type.

X12_UNKNOWN_CLAIM_STATUS_CATEGORY​

Unknown claim status category (CSCC): the STC composite's first component is outside the bundled snapshot. The verbatim code is preserved on the status; only its description is unavailable.

X12_UNKNOWN_CLAIM_STATUS​

Unknown claim status code (CSC): the STC composite's second component is outside the bundled snapshot. The verbatim code is preserved on the status; only its description is unavailable.

X12_834_UNKNOWN_MAINTENANCE_TYPE​

Unknown 834 maintenance type: the INS-03/HD-01 code is outside the bundled snapshot. The verbatim code is preserved on the enrollment and the action is NEVER inferred.

X12_UNPARSEABLE_DECIMAL​

Unparseable decimal: the element at position.elementIndex held bytes this library could not decode as a decimal, so NO value was decoded from it. Whatever occupies that slot on the model, including 0 and undefined, is a stand-in and is NOT a value the sender supplied. The verbatim bytes are preserved on the segment; read them there before acting on the amount, quantity or percent.

X12_837_SERVICE_LINE_NOT_DECODED​

837 service line with no decoded service segment: the Loop 2400 line opened at position.segmentIndex is followed by no SV1 / SV2 / SV3 matching the variant this submission resolved to, so NOTHING carried by the service segment was read. The line's charge and units are undefined, which is what this library puts on a decimal slot it decoded no value into; its procedure code, modifiers, unit of measure and place of service are equally undecoded. Two common causes: the line carries no SVx at all, or it carries one for a different 837 variant than ST-03 (or the caller's type option) named. Which side is wrong is NOT decided here, because a caller-supplied type can disagree with a perfectly conformant document. The verbatim segments are preserved on the transaction set; read them there before acting on the charge or the quantity.

X12_837_SERVICE_LINE_DROPPED​

837 service line dropped from the typed model: the LX at position.segmentIndex opened no Loop 2400, so no line appears on any claim's serviceLines for it and the SV1 / SV2 / SV3 that followed - its charge, units, procedure code and modifiers - was read into nothing. Compare X12_837_SERVICE_LINE_NOT_DECODED, where the line IS on the model and only its service segment went unread. Two causes: no Loop 2300 (CLM) is open at this LX, so there is no claim to attach a line to; or the submission's variant is not one of P / I / D, so no variant-specific line shape could be built. Read submission.variant and submission.claims to tell them apart; do NOT expect X12_837_UNKNOWN_VARIANT alongside this code, because a caller-supplied type outside P / I / D reaches the second cause without it. Nothing is fabricated to stand in for the missing line and no claim is synthesized. What becomes of a DTP / AMT / NTE / REF that follows the dropped LX depends on the route and this message does not say; see KNOWN-LIMITATIONS.md. The verbatim segments are preserved on the transaction set; read them there before concluding the claim had no service lines.

X12_837_SERVICE_SEGMENT_WITHOUT_LX​

837 service segment with no Loop 2400 to read it into: no service line was open at the SV1 / SV2 / SV3 at position.segmentIndex, so NOTHING it carries - its charge, units, procedure code, modifiers, unit of measure and place of service - was read. Read that literally: an LX may well appear earlier in the transaction, and what this reports is that none of them had opened a Loop 2400 still current at this segment. No line appears on any claim's serviceLines for it and nothing is fabricated to stand in. Compare the two codes anchored at an LX: X12_837_SERVICE_LINE_DROPPED, where an LX IS present and opened no line, and X12_837_SERVICE_LINE_NOT_DECODED, where the line is on the model and only its service segment went unread. Neither of those can report the SAME service segment as this code, because both are raised at an LX and this one only where no Loop 2400 is open; a document with several claims can still carry all three. This says NOTHING about how the submission's variant resolved: absent a caller-supplied type option, and where ST-03 names no known implementation convention, the reader falls back to the first SV1 / SV2 / SV3 in the transaction, and a segment reported here is eligible for that fallback like any other, so a stray one can decide the variant every line is read against. Read submission.variant. The verbatim segments are preserved on the transaction set; read them there before concluding the claim had no service lines.

X12_837_SERVICE_SEGMENT_REPEATED​

837 service segment repeated inside one Loop 2400: the SV1 / SV2 / SV3 at position.segmentIndex is not the first service segment to arrive in the service line the LX before it opened. This reader's line carries ONE service segment's worth of slots, so it cannot hold both, and this code is the only thing that tells you the document sent more than one. It asserts nothing about what usage the TR3s give the segment; what it reports is that this reader has one set of those slots per line. What the line carries is what the LAST service segment MATCHING the submission's resolved variant wrote onto it, and only that. Such a segment writes every slot its kind writes - the charge, the units and the procedure code among them - so a matching one arriving second leaves NOTHING an earlier matching one wrote, including where the later one's charge or units element is ABSENT: there the line is left with undefined, which is what this library puts on a decimal slot it decoded no value into, over an amount the earlier one stated. A service segment of a kind that does NOT match the resolved variant is read into nothing at all - it overwrites no slot, and what it carries reaches no part of the typed model. Which of them the sender meant is NOT decided here and is not derivable from the TR3s: this reader cannot tell a stray service segment from a conformant one, and picking a winner would be inventing. Nothing is fabricated to stand in, no second line is synthesized - an LX is what opens a line and there is none here - and no earlier value is kept in a second slot. Read the bound literally, as a property of the READ: this reports a second service segment arriving while a Loop 2400 IS open, whether or not it decoded. It is disjoint from X12_837_SERVICE_SEGMENT_WITHOUT_LX, which requires that NO Loop 2400 be open where this one requires that one is, so the two can never name the same segment; read that as disjointness and NOT as a promise that a service segment outside an open Loop 2400 is always named by that code, because a service segment FOLLOWING an LX that opened no line at all is named by neither of them, the loss having already been reported at that LX by X12_837_SERVICE_LINE_DROPPED. X12_837_SERVICE_LINE_NOT_DECODED, anchored at the LX, reports that no service segment matching the variant decoded onto the line at all, so a document can carry both codes on different segments. It fires once per repeat, so three service segments in one Loop 2400 are two warnings, and the count resets with the line: a first service segment under a later LX is a first and never a repeat. It says nothing about how the submission's variant resolved; where the fallback decided that and the body names more than one, X12_837_AMBIGUOUS_VARIANT reports it separately. The verbatim segments are preserved on the transaction set; read them there before acting on the charge, the quantity or the procedure code.

X12_837_ENTITY_SEGMENT_DISCARDED_AFTER_LX​

837 entity segment read into nothing after a dropped LX: the N3 / N4 / PER / REF at position.segmentIndex arrived while no entity loop was open, because an earlier LX in this transaction opened no Loop 2400 (no CLM was open at it) and closed the entity loop that was current there. NOTHING this segment carries reached the model: no party's address, contacts or references was written from it, and no party, claim or line was synthesized to hold it. This is the code that names THAT loss; X12_837_SERVICE_LINE_DROPPED is raised at the LX itself and names the SERVICE LINE's loss, never an entity segment, so the two report different things about the same stretch of the document. Read the bound literally, because this code does NOT report every unattached entity segment: it reports one discarded after such an LX and only while nothing since has opened a new loop, so an N3 / N4 / PER / REF that reaches no party by any other route is still silent, and one arriving after a later NM1 is outside this code's scope, whether or not this reader surfaces that segment kind on that party. It reports that the segment reached NO party; it does not claim it would have reached one had the LX been absent, because this reader does not surface every one of these segment kinds on every party (a PER on a patient or a pay-to address, for one). Which party a segment following a stray LX belongs to is not derivable from the TR3s in either direction, so it is discarded rather than attributed: see KNOWN-LIMITATIONS.md. The verbatim segments are preserved on the transaction set; read them there before concluding a party had no address, no secondary identifier or no contact.

X12_837_PAY_TO_ADDRESS_REPEATED​

837 pay-to address named more than once in one Loop 2000A: the NM1*87 at position.segmentIndex is not the first in this Loop 2000A, and the TR3s allow Loop 2010AB at most once there. The model has ONE pay-to address slot, so it cannot carry both, and this code is the only thing that tells you the document named more than one. The reader NEVER merges them: an N3 or N4 after this segment can no longer add a street line to, or fill a blank in, the address an earlier NM1*87 named, which is what this library did through 0.0.12 - it returned a fused address no sender sent, silently. What the slot carries instead is the LAST occurrence that stated an address of its own; an occurrence that states none - one carrying no N3 or N4 at all, or only a valueless N3 or N4 whose elements are empty - does NOT replace one that did, so nothing an earlier occurrence stated is blanked either. Where no occurrence states an address, the slot holds what the FIRST N3 or N4 to arrive under any of them produced, which may be an address with no elements at all, and which is not necessarily the first occurrence's: an occurrence that carries no N3 or N4 writes nothing, so a later one's valueless N3 is the first write and takes a slot still empty. Read that as the corner it is, and never restate it as the first OCCURRENCE winning. Which occurrence the sender meant is NOT decided here and is not derivable from the TR3s, and the losing occurrence's address is NOT on the model in any form. Read the bound literally: this reports repetition within one Loop 2000A, which is where the pay-to route lives, and an NM1*87 arriving while a CLM is open never reaches that route. The verbatim segments are preserved on the transaction set; read them there before acting on where a payment is to be sent.

X12_835_BALANCE_NOT_EVALUABLE​

  • X12_835_BALANCE_NOT_EVALUABLE_CLAIM: 835 balance invariant [CLP-04 + Σ(claim CAS + line CAS) == CLP-03] could not be evaluated: at least one term of it is undefined on the model, meaning this library decoded no value from that element. The equation is NOT reported as violated and NOT reported as satisfied, because an absent term has no value to compare - substituting 0 for it would be this library asserting a total the sender never sent. Which term is missing is read off the model, never from this message. Compare X12_835_REMIT_BALANCE_MISMATCH, which is raised only where every term decoded and the equation is genuinely out of balance.
  • X12_835_BALANCE_NOT_EVALUABLE_SERVICE_LINE: 835 balance invariant [SVC-03 + Σ(line CAS) == SVC-02] could not be evaluated: at least one term of it is undefined on the model, meaning this library decoded no value from that element. The equation is NOT reported as violated and NOT reported as satisfied, because an absent term has no value to compare - substituting 0 for it would be this library asserting a total the sender never sent. Which term is missing is read off the model, never from this message. Compare X12_835_REMIT_BALANCE_MISMATCH, which is raised only where every term decoded and the equation is genuinely out of balance.
  • X12_835_BALANCE_NOT_EVALUABLE_REMIT_TOTAL: 835 balance invariant [Σ(CLP-04) - Σ(PLB amounts) == BPR-02] could not be evaluated: at least one term of it is undefined on the model, meaning this library decoded no value from that element. The equation is NOT reported as violated and NOT reported as satisfied, because an absent term has no value to compare - substituting 0 for it would be this library asserting a total the sender never sent. Which term is missing is read off the model, never from this message. Compare X12_835_REMIT_BALANCE_MISMATCH, which is raised only where every term decoded and the equation is genuinely out of balance.

X12_AMOUNT_ROW_DROPPED​

Amount row dropped from the typed model: the AMT or ADX at position.segmentIndex carried no decodable amount (AMT-02, ADX-01), so NO row was built for it and the rest of the segment went with it - its qualifier or adjustment reason code, and any reference qualifier and id. Nothing is fabricated to stand in: a row is not built around a zero this library did not read, which is why the loss is reported rather than papered over. Two routes reach it and this code does not say which: the amount element was ABSENT, or it was present and held bytes that do not decode as a decimal. On this segment only the second route also raises X12_UNPARSEABLE_DECIMAL, carrying the failing element in its own position.elementIndex, so whether one is present at this position.segmentIndex is what separates them - and that code is unchanged by this one, which is raised alongside it rather than in place of it. Read the bound literally: this reports a row whose AMOUNT was read and decoded no value, and it is NOT a general report that an amount segment reached no model. A segment a reader discards before reading its amount is not on this channel, and neither is one whose amount decoded and then found no claim, service line, coverage or remittance open to attach the row to. An 820 RMR is not on it either, for its own reason: that row is dropped on open-item IDENTITY, RMR-01 and RMR-02 both empty, before the amount is read at all, so an RMR that states an open item and no amount keeps its row with amountPaid undefined while one that states an amount and no open item is dropped whole. That second case is a separate loss, and so is an 837 AMT that decoded while a Loop 2430 adjudication was open; X12_STATED_AMOUNT_DISCARDED reports both, and this code reports neither. The two can never name the same segment, because this one requires an amount element that decoded no value and that one requires the opposite. The verbatim segments are preserved on the transaction set; read them there before concluding the document stated no such amount.

X12_STATED_AMOUNT_DISCARDED​

Stated amount discarded: the RMR or AMT at position.segmentIndex populated its amount element and this reader built NO row for it, for a reason that is not a failure to decode that amount. What the sender wrote reaches no part of the typed model, so an empty list of open items or amounts is not evidence the sender stated none. Read that as the only claim made here: this code does NOT assert the amount is decodable, and on the RMR route below it is raised without the bytes ever being DECODED, so they may be unreadable, blank-but-present, or a lone component separator. Two routes reach it and this code does not say which. First, an 820 RMR whose RMR-01 and RMR-02 are BOTH empty while a remittance loop is open: the open item is refused on identity before RMR-04 or RMR-05 is read at all, so a stated payment amount, a stated amount due and the payment action code beside them go together. Second, an 837 AMT arriving while a Loop 2430 line adjudication is open: AMT-02 decoded, and the v1 adjudication model carries no amount row to put it on, so the row is skipped. Compare X12_AMOUNT_ROW_DROPPED, which reports the other situation on the same segments: there the amount element decoded no value, so there was no row to build at all. The two can never name the same segment. Read the bound literally, as a property of the READ: this reports a segment whose amount element the sender populated, arriving while the loop that would carry its row was open. It does NOT report an AMT or ADX that reaches a reader with no such loop open, which stays silent and is recorded in KNOWN-LIMITATIONS.md. And on the RMR route it says nothing about whether that amount WOULD have decoded, because the row is refused before the decode is attempted, so no X12_UNPARSEABLE_DECIMAL accompanies it even where the bytes are unreadable. Nothing is fabricated to stand in. The verbatim segments are preserved on the transaction set; read them there before concluding the document stated no such amount.

X12_270_NON_CONVENTIONAL_DELIMITER​

This interchange declares at least one delimiter other than the conventional one, and the 270 reader TOLERATED it: the declared set is what the shared interchange parse framed the document with, this reader took that set rather than assuming one, and NOTHING about the typed inquiry model changes because of it. So two 270s differing only in their declared delimiters decode to equal models. Nothing is echoed here, not the byte and not which role declared it: isa.raw carries all 106 bytes verbatim and, with the ISA fixed widths, is the route back. Read the bound literally. It is raised ONCE per 270 transaction set, whatever number of the four roles deviate, and it is raised on the 270 path ONLY: it reports what this reader tolerated on this transaction set and asserts nothing about how any other transaction set reads, nor that the declared set is unusual for the sender's trading partner.

X12_270_INTER_SEGMENT_LINE_BREAK​

A run of CR or LF bytes sits between segments of this interchange, and the 270 reader TOLERATED it: the shared interchange parse consumes such a run before the next segment opens, so it is part of no element and of no value the typed inquiry model exposes, and two 270s differing only in inter-segment line breaks decode to equal models. What was consumed is recorded nowhere on the model, so serializeX12 does not reproduce it and the emit is not byte-identical to a pretty-printed source; that is long-standing behaviour, unchanged here, and recorded in KNOWN-LIMITATIONS.md. Read the bound literally, and read it as CR and LF and NOTHING ELSE. Whitespace that is not CR or LF, a space or a tab between segments, is not consumed by the shared interchange parse at all: it becomes part of the next segment's identifier, the functional group never frames, and no 270 is found to report anything about. That is the shared parse's long-standing behaviour, it is unchanged here, and it is recorded in KNOWN-LIMITATIONS.md rather than widened by this reader. This code is raised ONCE per 270 transaction set however many runs the document carries, it is anchored at the ISA because the framing is a property of the document rather than of one segment, and it is raised on the 270 path ONLY.

X12_270_DUPLICATE_HIERARCHY_ID​

Two hierarchical levels in this 270 were transmitted with the same HL-01. The one at position.segmentIndex is not the first to carry that identifier, and this reader NEVER re-numbers a hierarchy: both levels keep their declared HL-01 verbatim on the model. What the duplication decides is attachment, and the rule is fixed so that the same bytes always decode to the same model: a child naming that identifier in its HL-02 attaches to the FIRST level carrying it in transmitted order, and never to a later one. A later level carrying the identifier is therefore reachable in the hierarchy only if some other pointer reaches it, and where none does it is reported separately as detached. Which of them the sender meant is NOT decided here and is not derivable from the TR3: this reader cannot tell a re-used identifier from a mis-keyed one. The verbatim segments are preserved on the transaction set.

X12_270_HIERARCHY_CYCLE​

The chain of HL-02 parent pointers starting at the hierarchical level at position.segmentIndex returns to a level already on that chain, so the document describes a hierarchy that is not a tree. The walk is bounded by the number of HL segments in the transaction set and visits no level twice on one chain, so it terminates rather than following the cycle: this code is what it reports instead. The level is NOT attached to a parent, and this reader neither re-numbers the hierarchy nor picks a link to break, because either would be inventing a structure the sender did not send. Every declared pointer stays verbatim on the model and the level's own HL is still on hierarchies. Read it as disjoint from a dangling pointer, which is X12_HL_PARENT_MISMATCH: that one reports a pointer naming a level that is not present, and this one requires that every pointer on the chain names a level that IS.

X12_270_LEVEL_DETACHED​

The hierarchical level at position.segmentIndex is not attached to the inquiry hierarchy this reader returns, because its declared HL-02 did not resolve to a level of the parent kind the TR3 gives it. Everything that level carried, its name, identifiers, demographics, traces, dates and eligibility inquiries, is therefore absent from the returned tree, and so is everything transmitted beneath it. NOTHING is fabricated to stand in: no parent is synthesized, no level is re-parented onto whichever one happened to be open, and no pointer is re-numbered. This code names THAT loss and nothing else; the separate defect in the pointer is reported by its own code at the same position, one of X12_HL_PARENT_MISMATCH, X12_HL_PARENT_LEVEL_INVALID or X12_270_HIERARCHY_CYCLE, so a level reported here always carries one of those beside it. The level's HL is still on hierarchies verbatim and its segments are still on the transaction set; read them there before concluding the sender sent no such level.

X12_270_DATE_ROW_DROPPED​

270 date row dropped from the typed model: the DTP at position.segmentIndex reached this reader short of one of the two elements a date row is built from, so NO row was built for it and the rest of the segment went with it. Both the qualifier that says what the date is for (DTP-01) and the date value itself (DTP-03) are required to build one. The format qualifier (DTP-02), which says whether the value is a single date or a range, is carried ON the row and is not what decides this. Two routes reach it and this code does not say which: DTP-01 was absent, or DTP-03 was. Nothing is fabricated to stand in: no date is defaulted, no qualifier is inferred from the loop the segment sits in, and no half a row is built from the element that IS present. An empty dates list on a level or an inquiry is therefore not by itself evidence the sender stated no date, which is exactly the ambiguity this code exists to remove. Read the bound literally, as a property of the READ: this reports a DTP whose row this reader tried to build and could not. It does NOT report a DTP that decoded and then reached no level or inquiry to sit on, which is a different loss, stays silent, and is recorded in KNOWN-LIMITATIONS.md. It is raised on the 270 path ONLY, once per such segment. The verbatim segments are preserved on the transaction set; read them there before concluding the document stated no such date.

X12_276_DUPLICATE_HIERARCHY_ID​

Two hierarchical levels in this 276 were transmitted with the same HL-01. The one at position.segmentIndex is not the first to carry that identifier, and this reader NEVER re-numbers a hierarchy: both levels keep their declared HL-01 verbatim on the model. What the duplication decides is attachment, and the rule is fixed so that the same bytes always decode to the same model: a child naming that identifier in its HL-02 attaches to the FIRST level carrying it in transmitted order, and never to a later one. A later level carrying the identifier is therefore reachable in the hierarchy only if some other pointer reaches it, and where none does it is reported separately as detached. Which of them the sender meant is NOT decided here and is not derivable from the TR3: this reader cannot tell a re-used identifier from a mis-keyed one. The verbatim segments are preserved on the transaction set.

X12_276_HIERARCHY_CYCLE​

The chain of HL-02 parent pointers starting at the hierarchical level at position.segmentIndex returns to a level already on that chain, so the document describes a hierarchy that is not a tree. The walk is bounded by the number of HL segments in the transaction set and visits no level twice on one chain, so it terminates rather than following the cycle: this code is what it reports instead. The level is NOT attached to a parent, and this reader neither re-numbers the hierarchy nor picks a link to break, because either would be inventing a structure the sender did not send. Every declared pointer stays verbatim on the model and the level's own HL is still on hierarchies. Read it as disjoint from a dangling pointer, which is X12_HL_PARENT_MISMATCH: that one reports a pointer naming a level that is not present, and this one requires that every pointer on the chain names a level that IS.

X12_276_LEVEL_DETACHED​

The hierarchical level at position.segmentIndex is not attached to the claim-status-request hierarchy this reader returns, because its declared HL-02 did not resolve to a level of the parent kind the TR3 gives it. Everything that level carried, its name, identifiers, demographics and the claims asked about under it, is therefore absent from the returned tree, and so is everything transmitted beneath it. NOTHING is fabricated to stand in: no parent is synthesized, no level is re-parented onto whichever one happened to be open, and no pointer is re-numbered. This code names THAT loss and nothing else; the separate defect in the pointer is reported by its own code at the same position, one of X12_HL_PARENT_MISMATCH, X12_HL_PARENT_LEVEL_INVALID or X12_276_HIERARCHY_CYCLE, so a level reported here always carries one of those beside it. The level's HL is still on hierarchies verbatim and its segments are still on the transaction set; read them there before concluding the sender sent no such level.

X12_276_DATE_ROW_DROPPED​

276 date row dropped from the typed model: the DTP at position.segmentIndex reached this reader short of one of the two elements a date row is built from, so NO row was built for it and the rest of the segment went with it. Both the qualifier that says what the date is for (DTP-01) and the date value itself (DTP-03) are required to build one. The format qualifier (DTP-02), which says whether the value is a single date or a range, is carried ON the row and is not what decides this. Two routes reach it and this code does not say which: DTP-01 was absent, or DTP-03 was. Nothing is fabricated to stand in: no date is defaulted, no qualifier is inferred from the loop the segment sits in, and no half a row is built from the element that IS present. An empty dates list on a claim or a service line is therefore not by itself evidence the sender stated no date, which is exactly the ambiguity this code exists to remove. Read the bound literally, as a property of the READ: this reports a DTP whose row this reader tried to build and could not. It does NOT report a DTP that decoded and then reached no claim or service line to sit on, which is a different loss, stays silent, and is recorded in KNOWN-LIMITATIONS.md. It is raised on the 276 path ONLY, once per such segment. The verbatim segments are preserved on the transaction set; read them there before concluding the document stated no such date.

X12_276_REFERENCE_ROW_DROPPED​

276 reference row dropped from the typed model: the REF at position.segmentIndex reached this reader short of one of the two elements a reference row is built from, so NO row was built for it and the rest of the segment went with it. Both the qualifier that says what the identifier is (REF-01) and the identifier itself (REF-02) are required to build one, and the description (REF-03) is carried ON the row rather than deciding this. Two routes reach it and this code does not say which: REF-01 was absent, or REF-02 was. Nothing is fabricated to stand in: no qualifier is inferred from the loop the segment sits in, no empty string is substituted for the value, and no half a row is built from the element that IS present. An empty references list on a claim or a service line is therefore not by itself evidence the sender stated no identifier. Read the bound literally, as a property of the READ: this reports a REF whose row this reader tried to build and could not. It does NOT report a REF that decoded and then reached no claim or service line to sit on, which is a different loss, stays silent, and is recorded in KNOWN-LIMITATIONS.md. It is raised on the 276 path ONLY, once per such segment. The verbatim segments are preserved on the transaction set; read them there before concluding the document stated no such identifier.

X12_271_AAA_REJECT_REASON_ABSENT​

  • X12_271_AAA_REJECT_REASON_ABSENT_INFORMATION_SOURCE: 271 AAA request validation at the information source level states no reject reason code: AAA-03 is absent, or present and empty. The typed AAA condition carries that code as ABSENT rather than as a value, no placeholder is substituted, and the segment is NOT dropped - everything else the reader read off it is on the condition under its own key. Nothing the sender sent is echoed here; position says which segment and which element to read. Compare X12_271_AAA_UNKNOWN_CODE, which reports a code that IS stated and resolves to no description.
  • X12_271_AAA_REJECT_REASON_ABSENT_INFORMATION_RECEIVER: 271 AAA request validation at the information receiver level states no reject reason code: AAA-03 is absent, or present and empty. The typed AAA condition carries that code as ABSENT rather than as a value, no placeholder is substituted, and the segment is NOT dropped - everything else the reader read off it is on the condition under its own key. Nothing the sender sent is echoed here; position says which segment and which element to read. Compare X12_271_AAA_UNKNOWN_CODE, which reports a code that IS stated and resolves to no description.
  • X12_271_AAA_REJECT_REASON_ABSENT_SUBSCRIBER: 271 AAA request validation at the subscriber level states no reject reason code: AAA-03 is absent, or present and empty. The typed AAA condition carries that code as ABSENT rather than as a value, no placeholder is substituted, and the segment is NOT dropped - everything else the reader read off it is on the condition under its own key. Nothing the sender sent is echoed here; position says which segment and which element to read. Compare X12_271_AAA_UNKNOWN_CODE, which reports a code that IS stated and resolves to no description.
  • X12_271_AAA_REJECT_REASON_ABSENT_DEPENDENT: 271 AAA request validation at the dependent level states no reject reason code: AAA-03 is absent, or present and empty. The typed AAA condition carries that code as ABSENT rather than as a value, no placeholder is substituted, and the segment is NOT dropped - everything else the reader read off it is on the condition under its own key. Nothing the sender sent is echoed here; position says which segment and which element to read. Compare X12_271_AAA_UNKNOWN_CODE, which reports a code that IS stated and resolves to no description.
  • X12_271_AAA_REJECT_REASON_ABSENT_UNATTACHED: 271 AAA request validation under no identified hierarchical level states no reject reason code: AAA-03 is absent, or present and empty. The typed AAA condition carries that code as ABSENT rather than as a value, no placeholder is substituted, and the segment is NOT dropped - everything else the reader read off it is on the condition under its own key. Nothing the sender sent is echoed here; position says which segment and which element to read. Compare X12_271_AAA_UNKNOWN_CODE, which reports a code that IS stated and resolves to no description.

X12_271_AAA_UNKNOWN_CODE​

  • X12_271_AAA_UNKNOWN_CODE_INFORMATION_SOURCE: 271 AAA request validation at the information source level states a code outside the bundled snapshot: the reject reason code or the follow-up action code at position.elementIndex resolved to no description, so the VERBATIM inbound code is preserved on the typed condition and only its description is absent. The bundled AAA snapshots ship EMPTY, so every stated AAA code is reported here; that is the intended consequence of shipping no descriptions rather than descriptions whose redistribution terms nobody recorded. One warning is raised per unrecognised code occurrence, so a segment stating both codes raises two. Nothing the sender sent is echoed here.
  • X12_271_AAA_UNKNOWN_CODE_INFORMATION_RECEIVER: 271 AAA request validation at the information receiver level states a code outside the bundled snapshot: the reject reason code or the follow-up action code at position.elementIndex resolved to no description, so the VERBATIM inbound code is preserved on the typed condition and only its description is absent. The bundled AAA snapshots ship EMPTY, so every stated AAA code is reported here; that is the intended consequence of shipping no descriptions rather than descriptions whose redistribution terms nobody recorded. One warning is raised per unrecognised code occurrence, so a segment stating both codes raises two. Nothing the sender sent is echoed here.
  • X12_271_AAA_UNKNOWN_CODE_SUBSCRIBER: 271 AAA request validation at the subscriber level states a code outside the bundled snapshot: the reject reason code or the follow-up action code at position.elementIndex resolved to no description, so the VERBATIM inbound code is preserved on the typed condition and only its description is absent. The bundled AAA snapshots ship EMPTY, so every stated AAA code is reported here; that is the intended consequence of shipping no descriptions rather than descriptions whose redistribution terms nobody recorded. One warning is raised per unrecognised code occurrence, so a segment stating both codes raises two. Nothing the sender sent is echoed here.
  • X12_271_AAA_UNKNOWN_CODE_DEPENDENT: 271 AAA request validation at the dependent level states a code outside the bundled snapshot: the reject reason code or the follow-up action code at position.elementIndex resolved to no description, so the VERBATIM inbound code is preserved on the typed condition and only its description is absent. The bundled AAA snapshots ship EMPTY, so every stated AAA code is reported here; that is the intended consequence of shipping no descriptions rather than descriptions whose redistribution terms nobody recorded. One warning is raised per unrecognised code occurrence, so a segment stating both codes raises two. Nothing the sender sent is echoed here.
  • X12_271_AAA_UNKNOWN_CODE_UNATTACHED: 271 AAA request validation under no identified hierarchical level states a code outside the bundled snapshot: the reject reason code or the follow-up action code at position.elementIndex resolved to no description, so the VERBATIM inbound code is preserved on the typed condition and only its description is absent. The bundled AAA snapshots ship EMPTY, so every stated AAA code is reported here; that is the intended consequence of shipping no descriptions rather than descriptions whose redistribution terms nobody recorded. One warning is raised per unrecognised code occurrence, so a segment stating both codes raises two. Nothing the sender sent is echoed here.

X12_271_AAA_SEGMENT_MALFORMED​

  • X12_271_AAA_SEGMENT_MALFORMED_INFORMATION_SOURCE: 271 AAA request validation at the information source level is malformed at position.elementIndex: an element is present PAST the highest element position this reader has a source for, or the follow-up action code element is present and empty. What the reader did read is surfaced on the typed condition and the rest of the document is read to completion; reading a 271 never becomes fatal over AAA content. NO MEANING IS ASSIGNED to an element past the sourced positions - this reports that a position is occupied and says nothing whatever about what occupies it, because the layout beyond the follow-up action code is not established here and guessing it is the failure this code exists to avoid. Nothing the sender sent is echoed here.
  • X12_271_AAA_SEGMENT_MALFORMED_INFORMATION_RECEIVER: 271 AAA request validation at the information receiver level is malformed at position.elementIndex: an element is present PAST the highest element position this reader has a source for, or the follow-up action code element is present and empty. What the reader did read is surfaced on the typed condition and the rest of the document is read to completion; reading a 271 never becomes fatal over AAA content. NO MEANING IS ASSIGNED to an element past the sourced positions - this reports that a position is occupied and says nothing whatever about what occupies it, because the layout beyond the follow-up action code is not established here and guessing it is the failure this code exists to avoid. Nothing the sender sent is echoed here.
  • X12_271_AAA_SEGMENT_MALFORMED_SUBSCRIBER: 271 AAA request validation at the subscriber level is malformed at position.elementIndex: an element is present PAST the highest element position this reader has a source for, or the follow-up action code element is present and empty. What the reader did read is surfaced on the typed condition and the rest of the document is read to completion; reading a 271 never becomes fatal over AAA content. NO MEANING IS ASSIGNED to an element past the sourced positions - this reports that a position is occupied and says nothing whatever about what occupies it, because the layout beyond the follow-up action code is not established here and guessing it is the failure this code exists to avoid. Nothing the sender sent is echoed here.
  • X12_271_AAA_SEGMENT_MALFORMED_DEPENDENT: 271 AAA request validation at the dependent level is malformed at position.elementIndex: an element is present PAST the highest element position this reader has a source for, or the follow-up action code element is present and empty. What the reader did read is surfaced on the typed condition and the rest of the document is read to completion; reading a 271 never becomes fatal over AAA content. NO MEANING IS ASSIGNED to an element past the sourced positions - this reports that a position is occupied and says nothing whatever about what occupies it, because the layout beyond the follow-up action code is not established here and guessing it is the failure this code exists to avoid. Nothing the sender sent is echoed here.
  • X12_271_AAA_SEGMENT_MALFORMED_UNATTACHED: 271 AAA request validation under no identified hierarchical level is malformed at position.elementIndex: an element is present PAST the highest element position this reader has a source for, or the follow-up action code element is present and empty. What the reader did read is surfaced on the typed condition and the rest of the document is read to completion; reading a 271 never becomes fatal over AAA content. NO MEANING IS ASSIGNED to an element past the sourced positions - this reports that a position is occupied and says nothing whatever about what occupies it, because the layout beyond the follow-up action code is not established here and guessing it is the failure this code exists to avoid. Nothing the sender sent is echoed here.

X12_271_AAA_LOOP_UNIDENTIFIED​

  • X12_271_AAA_LOOP_UNIDENTIFIED_INFORMATION_SOURCE: 271 AAA request validation at the information source level could not be attributed to an IDENTIFIED hierarchical loop: the enclosing level states no HL-01. The hierarchical identifier part of the condition's key is left ABSENT rather than synthesised, every other part of the key is still carried, and the AAA is NOT dropped. The occurrence index part of the key is always determinable and is never absent, so the condition still names exactly one loop occurrence in document order. Nothing the sender sent is echoed here.
  • X12_271_AAA_LOOP_UNIDENTIFIED_INFORMATION_RECEIVER: 271 AAA request validation at the information receiver level could not be attributed to an IDENTIFIED hierarchical loop: the enclosing level states no HL-01. The hierarchical identifier part of the condition's key is left ABSENT rather than synthesised, every other part of the key is still carried, and the AAA is NOT dropped. The occurrence index part of the key is always determinable and is never absent, so the condition still names exactly one loop occurrence in document order. Nothing the sender sent is echoed here.
  • X12_271_AAA_LOOP_UNIDENTIFIED_SUBSCRIBER: 271 AAA request validation at the subscriber level could not be attributed to an IDENTIFIED hierarchical loop: the enclosing level states no HL-01. The hierarchical identifier part of the condition's key is left ABSENT rather than synthesised, every other part of the key is still carried, and the AAA is NOT dropped. The occurrence index part of the key is always determinable and is never absent, so the condition still names exactly one loop occurrence in document order. Nothing the sender sent is echoed here.
  • X12_271_AAA_LOOP_UNIDENTIFIED_DEPENDENT: 271 AAA request validation at the dependent level could not be attributed to an IDENTIFIED hierarchical loop: the enclosing level states no HL-01. The hierarchical identifier part of the condition's key is left ABSENT rather than synthesised, every other part of the key is still carried, and the AAA is NOT dropped. The occurrence index part of the key is always determinable and is never absent, so the condition still names exactly one loop occurrence in document order. Nothing the sender sent is echoed here.
  • X12_271_AAA_LOOP_UNIDENTIFIED_UNATTACHED: 271 AAA request validation could not be attributed to a hierarchical level at all: no level of a kind this surface names encloses the segment, either because none had opened when it arrived or because the enclosing level's HL-03 is none of them. The level part of the condition's key is left ABSENT rather than guessed, and so is the hierarchical identifier where the enclosing level states none. The occurrence index counts within the AAA segments of this document whose level is likewise unknown, in document order, so two such segments are indexed 0 and 1 and never both 0. The AAA is NOT dropped and nothing the sender sent is echoed here.

X12_GUIDE_NOT_IMPLEMENTED​

The transaction set declares an implementation guide this reader does not implement. The declaration is ST-03, decoded of any release escape, or, where ST-03 is absent or empty, GS-08 of the functional group that framed the transaction set, decoded the same way; it is compared exactly, with nothing trimmed, case-folded or prefix-matched, against the guide identifiers this reader's rows in X12_TR3_CONFORMANCE name. The reading was still decoded and returned against the element positions of the guide this reader implements, and nothing was refused, dropped or re-decoded because of this code, so a value on it may sit at a position the declared guide defines differently. Nothing the sender declared is echoed here. Where the reading publishes implementationConventionReference, that field carries the decoded ST-03; the transaction set's st carries ST-03 as framed, and GS-08 is raw, framed bytes on the functional group's gs.

X12_GUIDE_NOT_DECLARED​

The transaction set declares no implementation guide: ST-03 is absent or empty, and GS-08 of the functional group that framed the transaction set is absent or empty too, or no functional group header reached the transaction set at all. The reading was still decoded and returned against the element positions of the guide this reader implements, and nothing was refused, dropped or re-decoded because of this code; that the document follows that guide is assumed here, not established. X12_TR3_CONFORMANCE names the guides each reader implements. Nothing is echoed here.

X12_BINARY_DATA_TRUNCATED​

The input ends before the binary data of this BDS or BIN segment reaches the octet count its length element (BDS-02 or BIN-01) declares. The data element at position.elementIndex holds only the octets present in the input: nothing past its end is read or invented, and because the declared count runs to the end of the input, every byte after the length element belongs to this segment and no trailer after it frames. The length element is preserved verbatim and is never rewritten. Nothing is echoed here.

X12_BINARY_LENGTH_INVALID​

The length element of this BDS or BIN segment (BDS-02 or BIN-01, at position.elementIndex) is absent, empty, or not a non-negative integer written as 1 to 15 ASCII digits, so its binary data cannot be framed by a count. No length is inferred from the data or from where a terminator falls: the segment is framed by its delimiters exactly as any other segment is, so a delimiter byte inside the binary data ends an element or the segment there. The length element is preserved verbatim on the model. Nothing is echoed here.

X12_BINARY_LENGTH_MISMATCH​

The binary data of this BDS or BIN segment does not end where its length element (BDS-02 or BIN-01) says it does: the byte after the declared span is not the segment terminator, or the segment ends before a data element begins. Where a data element is present it holds exactly the declared span, and the bytes between that span and the next segment terminator stay on the segment's raw text, so the default serializeX12 emit reproduces them; where none is present the segment is framed by its delimiters. Nothing is corrected, the length element is never rewritten, and nothing is echoed here.

X12_BINARY_LENGTH_UNVERIFIABLE​

The declared span of this BDS or BIN segment's binary data holds a character above U+00FF, which is not one octet, so the octet count its length element declares could not be verified against the input. This arises only for string input: the span is counted in UTF-16 code units, one per octet, and its characters are carried verbatim on the data element at position.elementIndex. A Buffer passed to parseX12 is read one octet per character, where the count is exact. Nothing is echoed here.

X12_277_RFAI_HEADER_ABSENT​

277 request for additional information with no BHT: the transaction set carries no Beginning of Hierarchical Transaction segment, so the reading's header is undefined. Nothing is fabricated to stand in: no purpose code, reference, date or time is inferred, and the rest of the transaction set was read as it stands. The verbatim segments are preserved on the transaction set. Nothing is echoed here.

X12_277_RFAI_LEVEL_ABSENT​

277 request for additional information with no hierarchical level: the transaction set carries no HL segment, so the reading's levels list is empty, and no entity and no claim-level request is reachable on it, because each is read under the level it was sent in. Nothing is fabricated to stand in and no level is synthesized. The verbatim segments are preserved on the transaction set; read them there before concluding the health plan requested nothing. Nothing is echoed here.

X12_277_RFAI_REQUEST_ABSENT​

277 request for additional information with no claim-level request: no level on the reading carries a request, because no TRN, STC or SVC arrived under an HL. Where the transaction set carries no HL at all, X12_277_RFAI_LEVEL_ABSENT is raised beside this code. The reading therefore names no claim and no requested item. Nothing is fabricated to stand in. The verbatim segments are preserved on the transaction set; read them there before concluding the health plan requested nothing. Nothing is echoed here.

X12_275_ATTACHMENT_ABSENT​

275 with no attachment: the transaction set carries no BDS segment, so the reading's attachments list is empty. Nothing is fabricated to stand in. The heading and every LX line are on the reading as usual, and the verbatim segments are preserved on the transaction set, including any segment this reader does not read as an attachment. Nothing is echoed here.

X12_999_IK5_ABSENT​

999 transaction set response with no IK5: the AK2 at position.segmentIndex was closed by the next AK2, by the AK9 or by the end of the transaction set before its IK5 arrived, so the sender stated no disposition for that response. The reading fills one in, fail-safe: ik5.disposition reads R (rejected) and ik5.syntaxErrorCodes is empty. Treat that reject as the reader's, not the sender's. The verbatim segments are preserved on the transaction set. Nothing is echoed here.

X12_999_AK9_ABSENT​

999 with no AK9: the transaction set ends without a functional group response trailer, so the sender stated no disposition and no counts for the group. The reading fills them in, fail-safe: ak9.disposition reads R (rejected), the three transaction set counts read 0 and ak9.syntaxErrorCodes is empty. Treat that reject and those counts as the reader's, not the sender's. The verbatim segments are preserved on the transaction set. Nothing is echoed here.

X12_999_AK1_ABSENT​

999 with no AK1: the transaction set carries no functional group response header, so the sender named no functional group this 999 answers. The reading fills one in: ak1.functionalIdCode and ak1.groupControlNumber read as empty strings and ak1.versionRelease is undefined. Treat them as the reader's, not the sender's: nothing on this 999 ties it to a functional group you sent, so do not match it to one by those empty values. The verbatim segments are preserved on the transaction set. Nothing is echoed here.

X12_999_IK5_DISPOSITION_UNKNOWN​

999 transaction set response disposition the reader could not read: IK5-01 (or AK5-01 on a legacy segment) at position.segmentIndex is absent, empty or not one of the seven codes of code list 715 (A, E, P, R, M, W, X, compared exactly). The reading falls back, fail-safe: ik5.disposition reads R (rejected), and the syntax error codes after it are read as sent. Treat that reject as the reader's, not the sender's. Compare X12_999_IK5_ABSENT, where the response has no IK5 at all. The verbatim segment is preserved on the transaction set. Nothing is echoed here.

X12_999_AK9_DISPOSITION_UNKNOWN​

999 functional group disposition the reader could not read: AK9-01 at position.segmentIndex is absent, empty or not one of the seven codes of code list 715 (A, E, P, R, M, W, X, compared exactly). The reading falls back, fail-safe: ak9.disposition reads R (rejected), and the counts and syntax error codes after it are read as sent. Treat that reject as the reader's, not the sender's. Compare X12_999_AK9_ABSENT, where the 999 has no AK9 at all. The verbatim segment is preserved on the transaction set. Nothing is echoed here.

X12_271_HEADER_ABSENT​

271 with no BHT: the transaction set carries no Beginning of Hierarchical Transaction segment, which the implementation guide requires right after the ST of every 271, so a trading partner checking against the guide can reject it. Nothing is fabricated to stand in: no purpose code, reference, date or time is inferred, and the rest of the transaction set was read as it stands. The verbatim segments are preserved on the transaction set. Nothing is echoed here.

Refusal codes​

Each registry types the code of one error class. The generated reference documents each registry and its class; follow the links.

RegistryError classCodes
X12_BUILD_ERROR_CODESX12BuildErrorX12_BUILD_INVALID_SPEC
ELIGIBILITY_270_BUILD_ERROR_CODESEligibility270BuildErrorX12_270_BUILD_INVALID_HIERARCHY, X12_270_BUILD_INVALID_SPEC
ELIGIBILITY_271_BUILD_ERROR_CODESEligibility271BuildErrorX12_271_BUILD_INVALID_HIERARCHY, X12_271_BUILD_INVALID_SPEC
CLAIM_STATUS_276_BUILD_ERROR_CODESClaimStatus276BuildErrorX12_276_BUILD_INVALID_HIERARCHY, X12_276_BUILD_INVALID_SPEC
CLAIM_STATUS_277_BUILD_ERROR_CODESClaimStatus277BuildErrorX12_277_BUILD_INVALID_HIERARCHY, X12_277_BUILD_INVALID_SPEC
AUTH_278_BUILD_ERROR_CODESServicesReview278BuildErrorX12_278_BUILD_INVALID_HIERARCHY, X12_278_BUILD_INVALID_SPEC
PREMIUM_820_BUILD_ERROR_CODESPremium820BuildErrorX12_820_BUILD_INVALID_SPEC
ENROLLMENT_834_BUILD_ERROR_CODESEnrollment834BuildErrorX12_834_BUILD_UNKNOWN_MAINTENANCE_TYPE, X12_834_BUILD_INVALID_SPEC
REMIT_835_BUILD_ERROR_CODESRemit835BuildErrorX12_835_BUILD_BALANCE_MISMATCH, X12_835_BUILD_INVALID_SPEC
CLAIM_837_BUILD_ERROR_CODESClaim837BuildErrorX12_837_BUILD_INVALID_HIERARCHY, X12_837_BUILD_INVALID_SPEC
ACK_BUILD_ERROR_CODESAckBuildErrorX12_ACK_INVALID_DISPOSITION, X12_ACK_INVALID_SPEC, X12_ACK_ACCEPT_WITH_ERRORS, X12_ACK_COUNT_MISMATCH, X12_TA1_ACCEPT_WITH_NOTE
ATTACHMENT_275_BUILD_ERROR_CODESAttachment275BuildErrorX12_275_BUILD_NO_ATTACHMENT, X12_275_BUILD_EMPTY_DATA, X12_275_BUILD_FILTER_CODE_INVALID, X12_275_BUILD_DATA_NOT_OCTETS, X12_275_BUILD_INVALID_SPEC
RFAI_277_BUILD_ERROR_CODESRfai277BuildErrorX12_277_RFAI_BUILD_NO_LEVEL, X12_277_RFAI_BUILD_NO_REQUEST, X12_277_RFAI_BUILD_NO_TRACE, X12_277_RFAI_BUILD_STATUS_CODE_EMPTY, X12_277_RFAI_BUILD_NO_SERVICE, X12_277_RFAI_BUILD_INVALID_SPEC
CORE_CODE_COMBINATION_ERROR_CODESCoreCodeCombinationTableErrorX12_CORE_COMBINATION_TABLE_INVALID
X12_CODE_LIST_ERROR_CODESX12CodeListErrorX12_CODE_LIST_INVALID_DOCUMENT_DATE