TL;DR (fast answer)
Claims go out
An EDI 837 is a healthcare claim submission file. Providers send it to payers or clearinghouses to request payment.
- Think: “Here’s what we’re billing you for.”
- Contains diagnoses, procedures, charges, providers, subscribers, and service lines.
- Forms: 837P (professional), 837I (institutional), 837D (dental).
Payments come back
An EDI 835 is an ERA (Electronic Remittance Advice) file. Payers send it back to explain what they paid (or denied) for each claim line.
- Think: “Here’s what we paid, and why.”
- Contains paid amounts, adjustments, denial reasons, and patient responsibility.
- Used for posting payments and reconciling claims.
What is an EDI 837 file?
The ASC X12 837 transaction is the industry standard for sending healthcare claims electronically. A provider (doctor, hospital, lab, etc.) sends an 837 to a payer (insurance company, Medicaid, Medicare, etc.) to request reimbursement.
What’s inside an 837?
An 837 is basically a structured “billing packet.” It includes:
- Patient/Subscribers (member IDs, demographics)
- Provider info (NPI, taxonomy, billing/rendering)
- Claim header (claim control numbers, dates)
- Service lines with procedure codes (CPT/HCPCS), modifiers, charges, and units
- Diagnosis codes (ICD-10)
Short 837 example
Don’t worry about every element yet — just notice the CLM claim header and SV1 service line:
CLM*26463774*100***11:B:1*Y*A*Y*I~ HI*ABK:K352~ SV1*HC:99213*100*UN*1***1~ DTP*472*D8*20250110~
CLM= claim header (claim ID, total charges, place of service)HI= diagnosesSV1= professional service line (procedure + charge)DTP= service date
837P vs 837I vs 837D
- 837P (Professional) — doctor/clinic claims. Uses segments like
SV1. - 837I (Institutional) — hospital/facility claims. Uses
SV2and revenue codes. - 837D (Dental) — dental claims. Specialized dental loops and tooth data.
What is an EDI 835 file?
The ASC X12 835 transaction is the standard for Electronic Remittance Advice (ERA). After a payer processes an 837 claim, they reply with an 835 telling you what they paid and why.
What’s inside an 835?
An 835 contains:
- Payment totals (EFT/check amounts)
- Claim payment results per claim and per service line
- Adjustments / denials with reason codes
- Patient responsibility amounts (copay/deductible/coinsurance)
Short 835 example
Look for CLP claim payment and CAS adjustments:
BPR*I*80*C*ACH*CCP************20250115~ TRN*1*1234567890*9876543210~ CLP*26463774*1*100*80*20*MC*12345~ CAS*PR*1*20~ SVC*HC:99213*100*80~ DTM*472*20250110~
BPR= payment method and total paidTRN= trace number (ties to EFT/check)CLP= claim paid/denied breakdownCAS= adjustments (group + reason code + amount)SVC= service line paidDTM= service date
835 vs 837 side-by-side comparison
| Feature | 837 (Claim) | EDI 835 (Remittance/ERA) |
| Direction | Provider → Payer / Clearinghouse | Payer → Provider |
| Purpose | Submit claim for payment | Explain payment/denial for submitted claim |
| When used | Before adjudication | After adjudication |
| Key segments | CLM, HI, SV1/SV2, NM1, DTP |
BPR, TRN, CLP, CAS, SVC, DTM |
| Contains | Diagnosis codes, procedures, charges, provider/subscriber details | Paid amounts, adjustment reasons, patient responsibility |
| Common outputs | Claim line table, diagnosis list, provider/member identifiers | Payment posting table, denial/adjustment summary |
| Other names | X12 837P / 837I / 837D | X12 835 / ERA / Remit |
Common segments you’ll see in each file
EDI files are built from segments separated by a terminator (often ~). Each segment begins with a 2–3 letter tag.
Common 837 segments
ISA / GS / ST— envelope headersNM1— names (patient, subscriber, provider)CLM— claim header (claim ID, total charge, POS)HI— diagnosis codesSV1— service line in 837PSV2— service line in 837IDTP— dates
Common 835 segments
BPR— payment total and methodTRN— payment trace/check numberN1 / N3 / N4— payer & payee infoCLP— claim payment statusCAS— adjustments / denials (deductible, coinsurance, etc.)SVC— service line paid/allowed amountsDTM— service/receipt dates
Why CLP and CAS matter in 835
If you’re doing payment posting or denial analysis, CLP tells you what happened to the claim overall, and CAS tells you why money moved.
CLP03= total chargeCLP04= amount paidCLP05= patient responsibilityCAS*PR= patient responsibility adjustmentsCAS*CO= contractual obligationsCAS*OA= other adjustments
Why convert 835/837 to CSV or Excel?
Raw EDI is great for computers, but rough for humans. Converting to CSV/Excel lets you:
- Open files in Excel and filter/sort by claim, member, procedure, denial reason, etc.
- Post payments faster (835 → readable payment tables)
- Audit claims before sending (837 → clear claim line review)
- Bulk analyze denials and patient responsibility trends
- Share with teams who don’t read raw X12
Use the client-side EDI 835/837 to CSV & Excel converter. Tip: Supported browser-local processing reduces the need to transmit EDI file contents to the application server.
Compare all EDI tools to choose a viewing, parsing, conversion, or validation workflow.
FAQ: common beginner questions
Can an 837 have multiple claims?
Yes. An 837 usually includes many claims, each with its own claim loop (2300) and service line loop (2400).
Does every 837 get an 835 back?
Typically yes, unless the claim is rejected before adjudication or paid through a different reporting channel. For most payers, every accepted 837 yields an 835 response.
Why are my 835 adjustments confusing?
Because a single claim can have multiple CAS segments. Each CAS includes a group code (PR/CO/OA) and one or more reason codes with amounts.
What’s the easiest way to read EDI files?
Inspect the file in the Client-Side EDI Viewer, or convert it to CSV/Excel. Once tabular, you can filter by claim ID, CPT, denial reason, paid amount, and more.