Two Files, One Conversation
Almost every dollar in US healthcare billing moves through a short conversation between two electronic documents. The provider sends an 837 — the electronic claim that says "here is what we did and what we are charging." The payer replies with an 835 — the remittance advice, or ERA (electronic remittance advice), that says "here is what we paid, what the patient owes, and why." Both are ANSI ASC X12 EDI transactions, and being fluent in how they fit together is the core of revenue-cycle work. If you want to see real structure while you read, open the X12 EDI 837/835 Viewer in another tab and load its built-in examples.
The Shared Envelope
Before looking at the differences, it helps to know that both files share the same envelope structure. An ISA/IEA pair wraps the whole interchange; a GS/GE pair wraps a functional group of like transactions; and an ST/SE pair wraps each individual transaction set. The ST01 element identifies the type — 837 or 835 — and a control number in ST02 is echoed by the SE so the two can be matched. Data inside is organized into segments (an identifier plus elements), with delimiters declared in the fixed-width ISA header. Once you can see that skeleton, both files stop looking like a wall of text.
Inside the 837 Claim
The 837 is built around a hierarchy: the billing provider, the subscriber (the insured person), and the patient. That hierarchy is expressed with HL segments, and the parties are named with NM1 segments — the billing provider, the payer, the subscriber, and the patient each get one. The claim itself lives in the CLM segment, which carries the claim ID, the total charge, and a composite describing the place of service and claim frequency. Diagnosis codes appear in HI segments, and each billable service is a line: SV1 for professional claims (a procedure code, charge, and units) or SV2 for institutional claims. Dates attach through DTP segments. Read top to bottom, an 837 answers: who is billing, for whom, for what diagnoses, and for which services at what charge.
Inside the 835 Remittance
The 835 is organized around a payment rather than a patient. It opens with a BPR segment carrying the total payment amount and the method (for example an ACH transfer), followed by a TRN trace number — the single most important field for reconciliation, because it links the ERA to the actual deposit that hits the provider's bank account. Then, for each claim, a CLP segment gives the claim-level story: the claim ID (matching the 837), the claim status, the amount charged, the amount paid, and the patient responsibility. Service-line detail follows in SVC segments. The parties are identified with N1 and NM1 segments. Read top to bottom, an 835 answers: how much was paid in total, against which claims, and how each claim's payment breaks down.
The Segment That Explains Everything: CAS
The reason a claim paid less than it was billed is almost always in a CAS segment. CAS — Claim Adjustment — combines three things: a group code, a reason code, and an amount. The group code says who bears the adjustment: PR for patient responsibility (deductible, copay, coinsurance), CO for contractual obligation (the negotiated write-off the provider agreed to and cannot bill the patient), OA for other adjustments, and PI for payer-initiated reductions. The reason code — a CARC (Claim Adjustment Reason Code) — gives the specific "why," and an optional RARC (Remittance Advice Remark Code) adds detail. So a line that reads CAS*PR*1*30.00 means $30 of patient responsibility under reason code 1 (deductible). Learning to read CAS segments is the difference between "the payment looks wrong" and "the patient owes their deductible."
How the Two Reconcile
Reconciliation is the act of matching an 835 back to the 837 that produced it and confirming the money balances. The workflow is straightforward once you know the fields: take each CLP in the 835, read its claim ID, and find the CLM with the same ID in the originating 837. Confirm that the charged amount matches, then read the paid amount and the CAS adjustments and verify that charge = paid + patient responsibility + contractual write-off + any other adjustments. When those add up, the claim is reconciled. When they do not, the CAS codes usually tell you exactly where the gap is. The TRN trace number, meanwhile, ties the whole 835 to the bank deposit so accounting can confirm the payment actually arrived.
Where Things Go Wrong
Most EDI headaches fall into two buckets. The first is structural: a clearinghouse rejects a file because the envelope is malformed — a missing SE, a control-number mismatch between ST and SE, or a segment count that does not agree with the trailer. These are quick to spot when you can see the segments grouped into transactions and get a warning about an unclosed transaction. The second is financial: a payment does not match expectations, and the answer is in the CAS adjustments and the CLP status code. Both kinds of problem are far easier to diagnose when you can open the raw file and see it broken into named segments and split composite elements rather than squinting at pipe-delimited text.
Reading Files Safely
Because claims and remittance files contain protected health information — patient names, member IDs, diagnosis and procedure codes — where you open them matters. A viewer that uploads the file to a server puts PHI on someone else's infrastructure. A client-side viewer that parses everything in your browser keeps the data on your machine, which is why the X12 EDI 837/835 Viewer does all parsing locally and never uploads anything. That makes it safe to inspect a real payer file during an investigation, on a locked-down workstation, or even offline.
Professional vs Institutional 837s
Not every 837 is the same. The 837P (professional) is what a physician practice, therapist, or independent provider submits; its service lines use SV1 segments carrying a procedure code (typically CPT or HCPCS) with modifiers, a charge, and units. The 837I (institutional) is what a hospital or facility submits; its service lines use SV2 segments organized around revenue codes, and it carries additional facility-specific data such as admission and discharge information. There is also an 837D for dental. The envelope and most of the hierarchy are identical, so once you can read one you can read them all — but knowing whether you are looking at a professional or institutional claim tells you which service segment to expect and how to interpret the codes on each line. When you open a claim in a viewer and see SV1, you know it is professional; SV2 means institutional.
A Field Glossary for Fast Reading
A handful of segment identifiers do most of the work, and memorizing them turns EDI from cryptic to routine. On the claim side: BHT begins the transaction, HL builds the provider/subscriber/patient hierarchy, NM1 names a party, CLM is the claim, HI holds diagnoses, and SV1/SV2 are the service lines. On the remittance side: BPR is the payment, TRN is the trace number, CLP is the claim payment, SVC is the service payment, and CAS is the adjustment. Across both: REF carries reference identifiers, DTP and DTM carry dates, and AMT carries monetary amounts. You do not need to memorize the hundreds of possible segments — these dozen cover the vast majority of what you will read day to day, and a viewer that names them means you can look up the rest as you go.
Before the Claim: 270/271 Eligibility
The 837/835 pair does not happen in isolation. Before a clean claim goes out, a provider often checks the patient's coverage with a 270 eligibility inquiry, to which the payer replies with a 271 eligibility response. These share the same X12 envelope and the same HL hierarchy and NM1 naming you already know from the 837, so they are easy to read once the claim structure is familiar. A 270 asks "is this member covered, and for what?"; the 271 answers with benefit details, active coverage dates, copay and deductible information. Catching an eligibility problem here — an inactive plan, a wrong member ID — prevents a denial later, which is why eligibility checking is the first line of defense in a healthy revenue cycle. The same viewer that reads your 837 and 835 will also parse a 270 or 271, so the whole conversation is legible in one place.
Putting It Together
The 837 and the 835 are two halves of one conversation: a claim goes out, an explanation of payment comes back. Learn the shared envelope (ISA/GS/ST), the handful of segments that carry the story (CLM and service lines on the way out; CLP, SVC, and CAS on the way back), and the CAS group and reason codes that explain every dollar of difference, and you can read almost any healthcare EDI file. Load the built-in 837 and 835 examples in the viewer and trace a single claim from charge to payment — it is the fastest way to make the structure stick.