Who this guide is for
This walkthrough is designed for:
- Billing and revenue cycle staff learning how to interpret 835 remittances
- Data analysts and engineers who support financial or denial reporting
- Software teams integrating 835 data into internal systems
You do not need to be an EDI expert. We’ll break down each part of the file in plain language.
High-level view: what’s inside an 835?
At a high level, an 835 tells you:
- How much was paid in a single EFT/check (payment header)
- Which claims were included in that payment
- Which lines were paid, denied, or adjusted
- Why adjustments were made (via CAS reason codes)
- How much the patient owes (patient responsibility)
- Any provider-level adjustments that affect the net payment
Step 1: Start with the payment header (BPR and TRN)
The BPR and TRN segments describe the overall payment:
- BPR02 – Total payment amount
- BPR04 – Payment method (check, ACH, etc.)
- BPR16 – Payment date
- TRN02 – Trace number used for bank/EFT reconciliation
Example: BPR and TRN segments
BPR*C*1500.00*C*ACH*CCP************20250131~ TRN*1*1234567890*9876543210~
Here, the payer is sending a credit (C) payment of $1,500.00 via ACH, dated 2025-01-31, with trace number 1234567890.
In practice, finance teams match the TRN value to the EFT deposit or check number
in the bank records.
Step 2: Identify the payer and payee (N1 loops)
The N1 loops identify the entities involved:
- N1*PR – Payer (e.g., a health plan)
- N1*PE – Payee (e.g., billing provider or group)
Example: N1 payer and payee
N1*PR*BIG HEALTH PLAN*PI*12345~ N3*100 MAIN STREET~ N4*ANYTOWN*NY*10001~ N1*PE*GREAT MEDICAL GROUP*XX*1234567893~ N3*500 CLINIC DRIVE~ N4*ANYTOWN*NY*10002~
This shows that BIG HEALTH PLAN is paying GREAT MEDICAL GROUP. Provider identifiers and addresses are included in these loops.
Step 3: Read each claim (CLP segment)
Every CLP segment corresponds to a claim. Important elements:
- CLP01 – Patient control number (your internal claim ID)
- CLP02 – Claim status code (1 = paid as primary, 2 = denied, 4 = zero pay, etc.)
- CLP03 – Total claim charge amount
- CLP04 – Claim payment amount
- CLP05 – Patient responsibility amount
- CLP07 – Payer claim control number
Example: CLP with paid claim
CLP*PCN12345*1*200*150*50*MC*PAYER12345~
Interpretation:
- Internal claim ID: PCN12345
- Status: 1 = paid
- Total charges: $200
- Paid amount: $150
- Patient responsibility: $50
- Payer claim ID: PAYER12345
At the claim level, you can quickly see which claims were paid, partially paid, or denied and how much remains the patient’s responsibility.
Step 4: Understand adjustments (CAS segments)
Immediately after a CLP, you’ll typically see one or more CAS segments. These break
down adjustments applied to the claim or line.
Each CAS segment includes:
- Group code – PR, CO, OA, PI
- Reason code – numeric code explaining the adjustment
- Amount – adjustment amount
- Quantity (optional)
Example: CAS for patient responsibility
CAS*PR*1*20.00*1~ CAS*PR*2*30.00*1~
Interpretation:
- PR*1 – Deductible of $20.00
- PR*2 – Coinsurance of $30.00
In combination with the CLP segment above, these two CAS lines explain the $50 patient responsibility.
Step 5: Drill down to service lines (SVC segments)
Within each claim, SVC segments represent individual service lines (CPT/HCPCS, revenue code,
or dental procedures). Key elements:
- Procedure or revenue code
- Line charge amount
- Line paid amount
- Units
Example: SVC with line-level adjustment
SVC*HC:99213*100*80**1~ CAS*CO*45*20.00*1~
Interpretation:
- Service line billed with CPT 99213 for $100
- Payer allowed and paid $80
- Contractual adjustment (CO*45) of $20 — typical fee schedule write-off
Reading SVC and CAS together tells you exactly how each procedure was adjudicated. This is the level most useful for denial, underpayment, and fee schedule analysis.
Step 6: Don’t forget provider-level adjustments (PLB)
At the end of the 835, PLB segments record adjustments at the provider level, such as:
- Bulk recoupments (take-backs)
- Interest payments
- Offsets not tied to a single claim
Example: PLB segment
PLB*1234567890*20231231*WO:12345*-25.00~
This shows a $25.00 write-off/offset applied at the provider level, which affects the net payment even though it doesn’t map to a single claim in the file.
Viewing the 835 in CSV or Excel (easier to read)
While reading the raw 835 segments is useful, most users prefer to view it as a flat table in CSV or Excel. A converter that understands the 835 structure can map CLP, CAS, SVC, and PLB data into columns.
Example: one service line as a CSV row
| claim_id | status | service_cpt | charge_amt | paid_amt | patient_resp | adj_group_1 | adj_reason_1 | adj_amt_1 |
|---|---|---|---|---|---|---|---|---|
| PCN12345 | Paid | 99213 | 100.00 | 80.00 | 50.00 | CO | 45 | 20.00 |
This is much easier to filter, pivot, and analyze than the raw X12 text, while still containing the same information.
The Client-Side EDI 835/837 Converter exports exactly this kind of flat structure, allowing you to:
- Filter by claim ID, CPT, payer, or denial reason
- Build pivot tables in Excel or BI tools
- Connect the output to Python or SQL for deeper analysis
FAQ: reading EDI 835 remittance advice
How do I know if a claim was fully paid?
Check CLP03 (total claim charge) versus CLP04 (claim payment) and the CAS segments:
if the only adjustments are normal contractual write-offs and patient responsibility, and CLP04 equals the
expected allowed amount, the claim was effectively paid as expected.
Where do I see patient responsibility?
At the claim level, CLP05 shows the patient responsibility amount. CAS segments with group code
PR break that into deductible, coinsurance, and copay using reason codes (e.g., PR*1, PR*2, PR*3).
How do I find denial reasons?
Denied or zero-paid claims typically have a CLP status code indicating denial (e.g., 2 or 4) and CAS segments with CO, OA, or PI groups. The CAS reason codes are the key to understanding why the payer did not pay.
Can I reconcile the 835 to my bank deposits?
Yes. The BPR segment contains the total payment amount and date, while the TRN segment contains the trace number used by your bank or clearinghouse. Matching these values to your bank records allows reconciliation at the payment level.
Do I need special software to read an 835?
You can open the raw file in any text editor, but reading it manually is slow and error-prone. Using a converter to flatten the data into CSV or Excel makes it much easier to work with. A client-side converter ensures that supported file contents are processed locally in the browser rather than sent to the application server for conversion.