X12 837 and 835 Files Explained: How to Actually Open and Read One

By OYNX · October 12, 2026 · 9 min read

Someone sends you a healthcare EDI file and says "can you check why this claim denied?" You open it and see a single line of dense text: ISA00 00 ZZ903314521 ZZNMMAD 0402020823U004010001000731P:. No file explorer preview, no spreadsheet, no app wants to open it. That moment of "how do I even open this file" is exactly what this guide answers.

Here's the short version before we go deep: an X12 837 file is a healthcare claim sent from a provider to a payer, and an X12 835 file is the payer's payment and explanation sent back. Both are plain text files — you can open either one in any text editor (Notepad, VS Code, Notepad++) — and both follow a segment-and-delimiter structure you can learn to read in about twenty minutes. No special software is required to read one; the tools only matter when you want to process thousands of them.

Key Takeaways

- 837 = the claim a provider sends to an insurance payer; 835 = the payment advice (electronic remittance advice) the payer sends back. They are the request and the answer in healthcare billing.

- Both are plain ASCII text. Right-click → Open With → any text editor. They're readable because X12 uses delimiters: * separates elements, ~ (usually) ends each segment.

- Every file nests three envelopes: ISA/IEA (interchange), GS/GE (functional group), ST/SE (transaction set). Read the ST segment to know what transaction you're looking at.

- An 835 payment trace follows three codes: CLP (claim-level payment), SVC (service-line payment), and CAS (adjustment reasons using standard CARC/RARC codes).

- The most common beginner trap is thinking one file equals one claim. One 837 file can hold thousands of claims; one 835 can hold every claim paid in a single check or EFT deposit.

What X12 Actually Is (in One Paragraph)

X12 is the American National Standards Institute's family of electronic data interchange (EDI) standards — a shared grammar so that a hospital's billing system and an insurer's claims system can talk without either one seeing the other's database. In healthcare, HIPAA law requires covered transactions to use specific X12 formats, which is why these files show up everywhere claims and payments move (X12, health care transaction flow overview). The standard defines the structure — segments, elements, loops — while industry implementation guides define what each segment must contain for claims (837) and payments (835).

If you've ever seen a BC prefix on a driver's license or wondered why hospital software looks ancient, X12 is part of that story: the standard dates to the late 1970s, and it was built for machines, not humans. Everything about its design — fixed positions, terse three-letter segment IDs, delimiters instead of XML tags — assumes a computer is the reader. You're about to read one anyway, and it's easier than it looks.

837 vs 835: Which File Am I Holding?

Before opening anything, identify the transaction by its first line of business meaning:

One more wrinkle that trips people up constantly: the 837 family splits by care setting. A physician office claim travels as an 837P under implementation guide 005010X222, a hospital facility claim as an 837I under 005010X223, and dental as an 837D. Historically these replaced the paper CMS-1500 (HCFA), UB-92, and ADA forms respectively, per the Indian Health Service's 837 training guide (IHS Quick Reference Guide, revised 2005). The segment vocabulary overlaps heavily between them, so once you can read one, you can roughly read all three.

Opening the File: Your First Five Minutes

No special software needed. Any plain text editor works — Notepad on Windows, TextEdit on Mac (set to plain text), or better, a code editor like VS Code or Notepad++ which handle very long single-line files more gracefully.

Step 1: Open it and break the line. Many X12 files are one enormous line. In Notepad++, do Search → Replace, replace ~ with ~\n (with "Extended" search mode) to put each segment on its own line. Instantly the file becomes a readable list of segments.

Step 2: Confirm the delimiters. The character after ISA in position 4 is the element separator (almost always ), and the character ending most segments is the segment terminator* (almost always ~). X12 actually declares its delimiters inside the ISA segment itself, so if a file looks scrambled, check position 4 and the last character of the ISA line — the file is telling you how to read it.

Step 3: Read the envelope stamps. Find the ST segment — it names the transaction type. ST8370001 means "this transaction set is an 837, sequence 1." The GS segment tells you the functional group (GSHC = health care claims; an 835 file will show GSHP = health care payment). If someone sends you a mystery file, ST and GS identify it in seconds.

<!-- Photo: Pexels — free to use -->

Step 4: Trace one claim, not the whole file. Beginners try to read the file start to finish. Don't. Search for CLM in an 837 (each match is one claim) or CLP in an 835 (each match is one adjudicated claim). Read from one CLM/CLP to the next; everything above the first one is header, everything after the last is trailer.

Reading an 837: The Envelope, the Loops, and One Real Claim

Every 837 nests three envelopes, and the structure is genuinely this simple:

ISA ... IEA     ← interchange envelope (one per transmission, carrier-level)
  GS ... GE     ← functional group (one per transaction type)
    ST ... SE   ← transaction set (the actual 837; may repeat inside one GS)

Inside the ST envelope, data is organized in loops — repeating groups of segments about one entity. The billing provider is one loop, the subscriber (insured person) another, the patient another, and then the claim itself with its service lines. The IHS quick reference guide's annotated example shows how the whole 837 transaction assembles from segments — here's a trimmed real example from that guide, one claim for a $206 office visit (IHS QRG, page 4, annotated example):

ST*837*0001                                     ← transaction set: this is an 837
BHT*0019*00*100073*20040202*0823*CH             ← file creation date/time
NM1*41*2*UNSPECIFIED SERVICE UNIT*****46        ← submitter name loop
HL*1**20*1                                      ← billing provider hierarchical level
PRV*BI*ZZ*261QP0904X                            ← billing provider taxonomy (clinic)
NM1*85*2*UNSPECIFIED SERVICE UNIT*****24*903314521  ← billing provider + NPI
N3*123 ABC ST                                   ← billing provider street
N4*OCEAN*NM*33333                               ← city, state, zip
HL*2*1*22*0                                     ← subscriber level
SBR*P*18*******MC                               ← payer relationship, Medicare
NM1*IL*1*STEELE*DANIELLE****MI*555551010        ← subscriber name + member ID
DMG*D8*19880501*F                               ← birth date, gender
NM1*PR*2*NMMEDICAID*****PI*NMMAD                ← payer name + payer ID
CLM*45404A-JSU-99091*206.00***13:A:1*Y*A*Y*Y    ← THE CLAIM: id + total charge
DTP*434*RD8*20030510-20030510                   ← statement dates
HI*BK:486                                       ← principal diagnosis (ICD code)
NM1*71*1*SMITH*USER****24*903314521             ← rendering provider
LX*1                                            ← service line 1 begins
SV2*0519**206.00*UN*1                           ← service: CPT 0519, $206, 1 unit
DTP*472*D8*20030510                             ← date of service
SE*35*0001                                      ← end of transaction (35 segments)

Reading tips that cover 90% of beginner confusion:

• NM1 is always a name. The second element after NM1 says whose* name: 85 = billing provider, 87 = pay-to provider, IL = subscriber/insured, PR = payer, 71 = rendering provider. When a claim rejects for "missing or incomplete names," this is the segment family to inspect first — the IHS guide lists NM1 errors among the most common 837 rejection causes.

• REF is an identifier (tax ID, license number, patient account), and DTP is a date — the qualifier right after DTP* tells you which date (472 = service date, 434 = statement period).

• Loops repeat for each patient/claim. A file with 500 claims is just the provider loops once, then 500 subscriber/claim blocks. Count CLM* occurrences to see how many claims you're holding.

• The rejection codes hide in segments you can read. Missing taxonomy (PRV), missing patient relationship (SBR02/PAT01), wrong claim totals vs. service-line sums, and invalid diagnosis codes (HI) are the classic causes of 837 rejections listed in the IHS guide — all visible in plain text once you know the segment IDs.

Reading an 835: Following the Money

The 835 is the payer's answer, and it's structured around a single business fact: one 835 transaction set equals one payment to one payee — one check or one EFT deposit — though it can report many claims under that payment, and one physical file can hold many transaction sets (CAQH CORE / X12, Introduction to the 835, 2019). That's why a Friday deposit of $43,000 arrives as one 835 with hundreds of CLP segments, not hundreds of files.

The reading order for one claim's money trail:

1. BPR — the total payment amount and payment method for the whole transaction. This is the number that should match the bank deposit.

1. TRN — the trace number, the thread linking the 835 to the EFT/check. If you're reconciling "which deposit is this file about," TRN is your join key.

1. CLP — one per claim: claim identifier, status code (4 = denied, 19/20/21 = processed variously), billed amount, paid amount, patient responsibility.

1. SVC — one per service line: the procedure, billed charge, and line-level paid amount.

1. CAS — the adjustment segments, and the part everyone actually needs: each CAS carries a CARC (Claim Adjustment Reason Code) and optionally a RARC (Remittance Advice Remark Code) explaining exactly why the paid amount differs from the billed charge. CO-45, PR-1, CO-97 — those cryptic codes on your EOB live here, standardized nationally instead of using each payer's proprietary codes (CAQH CORE 835 introduction).

So the money-tracing question "why did I get $150 on a $206 claim?" resolves like this: find the CLP, read its paid amount, scan the CAS segments under it, look up the CARC codes in the CMS CARC/RARC list (public, searchable), and you have the payer's stated reason — in plain text, no portal login required.

The 835 also closes the loop on the workflow: when a receiver gets an 835 (or a 837), their system returns a 999 functional acknowledgment confirming the file parsed, a pattern that applies to both directions of exchange (CAQH CORE). If your file "disappeared," the first thing to ask the payer for is the 999 — it tells you whether the file was even readable before any claim was evaluated.

The 11 Classic Ways an 837 Gets Rejected

The IHS quick reference guide catalogs the common data errors that cause 837 claims to bounce, and they're worth memorizing because they account for most beginner debugging sessions (IHS QRG, pp. 11–16):

1. Special characters or punctuation in any field (the delimiter characters especially — a stray * or ~ in a name corrupts everything after it)

1. Leading or trailing spaces

1. Missing or incomplete names (NM103, NM104, NM105 elements)

1. Missing or incomplete dates (DTP02, HI101)

1. Missing provider ID, UPIN, or license numbers

1. Missing provider taxonomy

1. Missing patient relationship codes (SBR02, PAT01)

1. Missing dates of birth or gender codes

1. Missing AO control numbers

1. Incorrect claim totals (CLM total ≠ sum of service lines)

1. Missing or incorrect diagnosis codes (HI segment)

Notice the pattern: rejections are overwhelmingly data hygiene failures in segments you've already learned to read. When a payer sends back a 999 or 277CA with an error, the error message references a segment position — and you can now open the 837, count segments, and find the offending line yourself.

Tools: When a Text Editor Stops Being Enough

Reading one claim in Notepad is fine. Reading 50,000 claims a month is a job for software. The progression:

• Free online viewers — tools like the EDI file viewer at edifileconverter.com render 837/835/270/271 segments into labeled tables (edifileconverter.com/viewer). Fine for occasional inspection; never paste production PHI into a web tool you don't control.

• Text editor + segment splitting — what you did above, plus regex searches. The workhorse for consultants.

• Parser libraries — Python (e.g., x12 parsers on PyPI), Node, Java, and C# all have open-source X12 parsers that convert segments to JSON/objects. This is where SparkSphear-style automation lives: parse the 835 feed nightly, post payments automatically, flag CARC patterns that predict denials.

• Clearinghouse report tools — most clearinghouses (Availity, Waystar, Office Ally) have native viewers; the raw file is your fallback when their UI hides what you need.

The uncomfortable truth the r/edi community keeps repeating: the tools help, but there's no substitute for reading segments yourself, because payer-specific quirks and companion-guide exceptions constantly break parser assumptions. Spend the twenty minutes.

Frequently Asked Questions

How do I open an .837 or .835 file with no extension or as a .dat/.txt file?

Exactly the same way — the extension is cosmetic. X12 files arrive as .837, .835, .edi, .dat, .txt, or no extension at all. If the first 3 characters are ISA, it's an X12 interchange; open it in a text editor and split on the segment terminator.

Which 837 is which — P, I, D?

837P is professional claims (physician, outpatient, the CMS-1500 world), 837I is institutional (hospital facility claims, the UB-04 world), 837D is dental. Check the GS08 or ST03 implementation-guide reference in the file — it names the exact guide version (e.g., 005010X222A1 = 837P 5010).

What's the difference between an 835 and an EOB?

The EOB (Explanation of Benefits) is the human-readable version usually sent to the patient; the 835 is the machine-readable Electronic Remittance Advice (ERA) sent to the provider. Same underlying adjudication data, two audiences. Providers work from the 835 for posting; patients read the EOB.

Why did my 835 payment not match my bank deposit?

Because the 835 (remittance data) and the EFT payment (money) travel separately and can arrive on different days — and one physical 835 file can contain multiple transaction sets. Match on the TRN trace number, which CAQH CORE operating rules require for EFT/ERA reassociation (CAQH CORE).

Do I need expensive software or a WEDI guide subscription to learn this?

No. The implementation guides (X12/WPC) and WEDI materials are the authoritative references and some are paid, but the free IHS and CAQH training materials cover the beginner layer completely, and sample files are widely available. Download a sample 837, split the segments, and read it against the annotated example above.

The Bottom Line

The 837 and 835 are not arcane formats — they're a claim and its answer, written in a text grammar simple enough to read in a text editor once you know that * separates elements, ~ ends segments, and ST/GS tell you what you're holding. Read the envelopes first, trace one CLM or CLP at a time, and let the CARC codes on the CAS segments explain the money. Everything else — parsers, viewers, clearinghouse portals — is convenience layered on a structure you can now read yourself.

If your practice or business is drowning in these files instead of reading them, SparkSphear Tech Solutions builds exactly this kind of automation: parsing 835 remittance feeds, reconciling payments against bank deposits, and flagging denial patterns before they repeat. Talk to our team and bring the file that started this article — we'll read it together.