X12 837 Generation From Extracted Claim Data

X12 837 generation turns extracted claim data into an electronic claim file. Choose the 837P for CMS-1500 data or the 837I for UB-04 data, place each field in its loop and segment, wrap the transaction in envelopes whose control numbers match, and validate syntax, balancing and code sets before the file leaves your system.

This is a developer guide to the file format. Schema Care offers no API, SDK, webhooks, FHIR output, 835 output or 837 output. Every segment, value and file shown below is a fictional example written for this post.

837P versus 837I for X12 837 generation

X12 837 generation starts with one decision: professional or institutional. The 837P carries the data a CMS-1500 holds, and the 837I carries the data a UB-04 holds. Each variant has its own implementation guide, and a generator that mixes them produces a file no payer will accept.

The version numbers come from Medicare's own list. Chapter 24 of the Medicare Claims Processing Manual on EDI support requirements names 005010X222A1 for the 837 professional claim, 005010X223A2 for the 837 institutional claim and 005010X224A2 for the 837 dental claim. The NUCC 1500 Reference Instruction Manual says its paper form instructions line up with the 005010X222 and 005010X222A1 professional reports, which is why most CMS-1500 boxes have a direct electronic home.

The institutional side is tied to the UB-04 in the same way. Chapter 25 of the Medicare Claims Processing Manual on completing the CMS-1450 covers the codes needed for "the Form CMS-1450 and compliant Accredited Standards Committee (ASC) X12 837 institutional claims." It describes form locator 4, the type of bill, as a four-digit code whose last digit is a frequency code. Nothing on a CMS-1500 supplies that value, so a professional record cannot be turned into an institutional claim by relabeling it.

In practice, keep the variant as a property of the extracted document, set when the form is classified. A generator should refuse to build an 837I from a record whose source was a CMS-1500, rather than guessing at missing facility fields. The billing team's side of this choice, and the full paper workflow, is covered in the guide to converting paper claims to 837 files.

The 837 loop structure from billing provider to service line

An 837 transaction is a hierarchy of loops. Submitter and receiver loops come first, then a billing provider level, a subscriber level, an optional patient level, the claim and its service lines. Each extracted claim field belongs to exactly one place in that tree, identified by a loop number, a segment and an element position.

The hierarchy is set by HL segments. In the X12 example of a commercial 837P claim, loop 1000A names the submitter and 1000B the receiver. Loop 2000A opens the billing provider level, with 2010AA holding the provider's name, address and tax ID. Loop 2000B opens the subscriber level, with 2010BA for the subscriber and 2010BB for the payer. The example adds loop 2000C, with 2010CA for the patient, because its patient is a different person from the subscriber. Loop 2300 holds the claim, and each 2400 loop holds one service line.

The table below maps a fictional CMS-1500 to 837P loops and segments. The loop and segment columns come from the Noridian JE Part B crosswalk of CMS-1500 items to 837 loops and segments, which says it is not an all-inclusive list, and from the CMS MLN job aid on CMS-1500 and 837P code sources. Every value is an example.

Three values change shape on the way in. The diagnosis loses its decimal point, because the NUCC manual says the decimal is implied. The diagnosis pointer letter A becomes the number 1, pointing at the first diagnosis in the HI segment. The date 10/02/2026 becomes 20261002. The meaning of each box on the paper form is covered in the guide to CMS-1500 form fields, and the code formats themselves in the section on which code systems appear in extracted medical data.

A short generated 837P, as an example

The transaction below is a fictional example built from the table, for a fictional patient. The table shows the first of its two service lines; the second, 87880 for $60, makes up the rest of the $185 total. It shows the transaction set only, from ST to SE. A real file also needs ISA and GS envelopes around it and the matching GE and IEA trailers after it, plus the payer and clearinghouse identifiers your trading partner assigns.

ST*837*0001*005010X222A1~
BHT*0019*00*EX0001*20261015*1200*CH~
NM1*41*2*EXAMPLE BILLING SERVICE*****46*EX12345~
PER*IC*EXAMPLE CONTACT*TE*5555550100~
NM1*40*2*EXAMPLE HEALTH PLAN*****46*EXPLAN01~
HL*1**20*1~
NM1*85*2*EXAMPLE FAMILY CLINIC*****XX*1234567893~
N3*100 SAMPLE ST~
N4*SPRINGFIELD*IL*62701~
REF*EI*990000001~
HL*2*1*22*0~
SBR*P*18*******CI~
NM1*IL*1*DOE*JANE****MI*EXM100200300~
N3*1 EXAMPLE AVE~
N4*SPRINGFIELD*IL*62704~
DMG*D8*19800214*F~
NM1*PR*2*EXAMPLE HEALTH PLAN*****PI*EXPLAN01~
CLM*EX-2026-0042*185***11:B:1*Y*A*Y*Y~
HI*ABK:J069~
LX*1~
SV1*HC:99213*125*UN*1***1~
DTP*472*D8*20261002~
LX*2~
SV1*HC:87880*60*UN*1***1~
DTP*472*D8*20261002~
SE*26*0001~

The two line charges, $125 and $60, add up to the $185 in CLM02. SE carries 26, the number of segments from ST to SE inclusive, and repeats the control number 0001 from ST.

Which extracted claim fields block 837 generation when missing?

Some claim fields have no default. Without the billing provider's NPI, the subscriber's member ID, the payer, at least one diagnosis, and a date, procedure code and charge on every service line, a generator cannot build a valid claim. These are also the fields a scanned paper form most often shows faintly, partly or not at all.

The billing provider NPI is the first blocker. The CMS paper on NPI and NPI check digit requirements says an NPI is 9 digits followed by one check digit computed with the Luhn formula. A misread digit almost always breaks the check, so run it before generation and send failures to a person rather than to the payer.

Diagnosis codes block generation in two ways. A code may be missing, or it may be cut short. The FY 2026 ICD-10-CM Official Guidelines say a code is invalid if it has not been coded to the full number of characters it requires, including a 7th character where one applies. A smudged final character on paper produces exactly that kind of code. The NUCC manual also caps item 21 at 12 diagnoses and says a claim with more than 50 service lines must be split, so a generator needs a rule for splitting claims as well as a loop for writing them.

Some required values never appear on the paper form at all:

• The payer's electronic ID, which comes from your clearinghouse's payer list, not from the printed payer address.
• Qualifiers, such as the code that says an identifier is an NPI or that a diagnosis is ICD-10.
• Whether the claim is an original or a resubmission. The NUCC manual says item 22 is for resubmissions, with 7 for a replacement and 8 for a void, and is not used on original claims. A blank item 22 tells the generator nothing on its own, so the claim's status has to come from your billing system.
• Submitter and receiver IDs, assigned by the trading partner.

Treat each of these as configuration or reference data with its own owner. When an extracted field is present but uncertain, the decision belongs upstream: the guide to confidence scores in API responses shows how to hold a low-confidence member ID or diagnosis back for review before it ever reaches the generator. Schema Care sits before the generator, not inside it: it reads CMS-1500 and UB-04 fields with their diagnosis and procedure codes, gives every field a confidence score, and sends the uncertain ones to a person, as the list of documents Schema Care reads shows.

How do I validate an 837 file before submission?

Validate an 837 file in layers: X12 syntax first, then the implementation guide's rules, then balancing, situational rules and code sets, and finally the edits of the payer or clearinghouse that will receive it. Each layer catches a different class of error, and a file that passes one can still fail the next.

The layers have names. The Ohio Department of Medicaid's page on WEDI SNIP testing types quotes the WEDI SNIP white paper's seven types:

Run types 1 to 5 in your own pipeline. Types 1 and 2 need a translator or validator that knows the 005010X222A1 or 005010X223A2 guide. Type 3 is simple arithmetic you can write yourself: sum SV102 across the 2400 loops and compare with CLM02. Type 5 needs current code releases, which the guide to code system mapping in extracted data covers.

The receiver then runs its own checks and answers with acknowledgments. Chapter 24 of the Medicare manual says the front end decides whether an edit failure rejects the whole transaction set through a TA1 or 999 acknowledgment, or passes the claim on for claim-level rejection through a 277CA. When the 999 reports "Accepted, but Errors Noted", the transaction went through and the errors were passed on. Your system should parse all three responses, tie them back to the file and claim that produced them, and stop treating a claim as sent until the 277CA has accepted it.

837 generation mistakes: control numbers and segment counts

A generated 837 can be rejected outright for envelope errors, before any claim data is read. Control numbers that do not match between a header and its trailer, or a segment count in SE that does not equal the real count, can fail the whole interchange, functional group or transaction set at the receiver's translator.

Chapter 24 says translators edit the envelope segments (ISA, GS, ST, SE, GE and IEA) so they can reject an interchange, functional group or transaction set straight away, before the claims are mapped. Each header and its trailer form a pair, so a generator should write the trailer from the same stored value it used for the header, never from a second counter. The same chapter notes that Medicare contractors are not required to accept multiple functional groups with multiple transaction types in one transmission, so keep one transaction type per file unless the receiver's companion guide says otherwise.

Receivers also set their own limits on claims per transaction and file size. Those limits differ by trading partner and appear in each receiver's companion guide, so read the guide for each one and build the limits into configuration rather than code.

The segment count is the other common failure. In the X12 example claim, the trailer reads SE*42*0021: SE01 is 42, the number of segments from ST to SE inclusive, and SE02 repeats the control number 0021 from ST*837*0021. A generator that counts segments by hand, or forgets to recount after adding a segment, sends a wrong SE01. Compute the count from the segments you actually wrote, at the moment you write SE.

Other mistakes that show up in generated files:

• Reusing control numbers across days. Keep a persistent counter per trading partner. Restarting at 1 after each deployment produces duplicates.
• Writing extracted text unchanged. Lowercase letters, punctuation in codes and decimal points in diagnoses all need normalizing first. Chapter 24 notes that Medicare translators convert lower case to upper case, but other receivers may simply reject it.
• Building one huge transaction. Splitting claims across several ST to SE sets keeps you under receiver limits and makes a rejection smaller.
• Losing the link to the source. Store the file name, the control numbers and each claim's CLM01 with the extracted record, so a 999 or 277CA error can be traced to the page it came from.

The billing team's view of these rejections, and how to work them, is covered in the guide to converting paper claims to 837 files.