What Is the EDI 835 and How Does It Relate to ERA?
The EDI 835, formally titled "Healthcare Claim Payment/Advice," is the HIPAA- mandated electronic transaction that payers use to explain how they processed a healthcare claim — what they paid, what they adjusted, what they denied, and why. When you hear billing professionals refer to an "ERA" (Electronic Remittance Advice), they are talking about the information contained in an 835.
The relationship is direct: every 835 is an ERA, but the 835 is the EDI format used to transmit it. Practice management systems typically parse the 835 and display the content as a human-readable ERA; what your billing staff sees in the "ERA viewer" inside your PM system is a visual representation of the 835 data.
Under HIPAA (and the ACA's Operating Rules), payers who remit payments electronically must also send a corresponding 835. This linkage means that once you enroll in EFT (Electronic Funds Transfer) with a payer, you should also enroll in ERA/835 delivery — they travel together by regulation.
Key 835 Facts
- Transaction Set Identifier: 835
- Functional Identifier Code (GS01): HP
- Governing Standard: X12 005010X221A1
- Direction: Payer → Provider (or payer → clearinghouse → provider)
- HIPAA Mandate: Required when payment is made electronically (EFT or check with EFT enrollment)
- Typical delivery frequency: Daily batch or triggered per payment run
The 835 File Structure: Loops and Hierarchy
An 835 file is organized into nested loops. Understanding the loop hierarchy is essential for building robust parsing logic — most auto-posting failures trace back to parsing code that does not properly handle loop boundaries.
835 Loop Hierarchy (X12 005010X221A1)
ST*835*0001~ ← Transaction Set Header
BPR*I*12450.00*C*ACH*...~ ← Payment info (amount, EFT details)
TRN*1*835291048*1234567890~ ← Trace number (check/EFT reference)
DTM*405*20260414~ ← Production date
Loop 1000A (Payer Identification)
N1*PR*BLUE CROSS BLUE SHIELD*XV*87726~
N3*PO BOX 100~
N4*CHICAGO*IL*60601~
Loop 1000B (Payee Identification)
N1*PE*ACME MEDICAL GROUP*XX*1234567890~ ← Your NPI
N3*100 MAIN ST~
N4*SPRINGFIELD*IL*62701~
REF*TJ*123456789~ ← Your Tax ID
Loop 2000 (Header Number — one per payment)
LX*1~ ← Assigned number
Loop 2100 (Claim Payment Information)
CLP*CLM-001*1*1500.00*1050.00**MC*CLMPAYER001~ ← Claim-level payment
NM1*QC*1*DOE*JANE****MI*MEMBER123456~ ← Patient
NM1*82*1*SMITH*JOHN****XX*9876543210~ ← Rendering provider
SVC*HC:99213*150.00*105.00**1~ ← Service line 1
DTM*472*20260301~ ← Service date
CAS*CO*45*45.00~ ← Contractual adjustment
REF*6R*SVC-LINE-001~ ← Line item control number
AMT*B6*105.00~ ← Allowed amount
SE*28*0001~A single 835 file can contain multiple Loop 2100 (CLP) segments, each representing a different claim. Within each CLP loop, there can be multiple SVC (service line) segments. The hierarchy is: file → interchange → functional group → transaction set → Loop 2000 → Loop 2100 (per claim) → Loop 2110 (per service line).
The CLP Segment: Claim-Level Payment Data
The CLP segment (Claim Level Data) is the most important segment in the 835 for billing purposes. It contains the claim status code that tells you what happened to the entire claim, and the financial summary of what was charged, allowed, paid, and pended.
CLP02 Claim Status Codes You Must Understand
CLP02 is the first thing your posting engine should check. A status code of 4 (denied) means the claim payment is $0 regardless of what CLP04 shows — do not post a payment. Common codes:
Processed as Primary
Claim adjudicated as primary payer — normal payment scenario
Processed as Secondary
COB — primary payer information from original 837 was used
Processed as Tertiary
Third payer in COB chain
Denied
Claim denied in full — check CAS segments and reason codes
Processed as Primary, Forwarded
Primary payment made and claim forwarded to secondary
Reversal of Previous Payment
Previous payment is being taken back — triggers a takeback workflow
The CAS Segment: Claim Adjustment Groups and Reason Codes
The CAS (Claim Adjustment) segment explains why the payment differs from the billed amount. It appears at both the claim level (inside CLP) and the service line level (inside SVC), and it uses two codes in combination: the Claim Adjustment Group Code (CAS01) and the Claim Adjustment Reason Code (CARC, CAS02).
Claim Adjustment Group Codes (CAS01)
Most Common Claim Adjustment Reason Codes (CARCs)
There are over 300 CARCs published by the CARC/RARC Committee. These are the ones your billing team will encounter most frequently:
Write Off
Charges exceed your contracted/legislated fee arrangement
Action: Write off — this is the standard contractual adjustment. Do NOT bill patient.
Bill Patient
Deductible Amount
Action: Bill patient. Verify deductible status on last 271 response.
Bill Patient
Coinsurance Amount
Action: Bill patient for the stated percentage.
Rework
The procedure code is inconsistent with the modifier used
Action: Review modifier; refile with corrected modifier if appropriate.
Rework
The diagnosis is inconsistent with the procedure
Action: Review coding. Refile with corrected diagnosis or procedure.
Rework
Claim lacks information required for adjudication
Action: Review remittance for RARC (reason additional code) explaining what is missing.
Rework
This care may be covered by another payer
Action: Check COB order. Refile as secondary if appropriate.
Appeal
The time limit for filing has expired
Action: Appeal with proof of timely filing (TA1/997 from original submission).
Appeal
Non-covered service because this is not deemed a medical necessity
Action: Appeal with supporting clinical documentation or ABN.
Rework
Payment included in allowance for another service
Action: Identify the bundled service. May need to unbundle with modifier -59/-XU.
The SVC Segment: Service Line Detail
If CLP is the claim-level summary, SVC is the line-item detail. Each SVC segment corresponds to one service line on the original claim and shows what was billed vs. what was allowed and paid at the procedure level.
SVC Segment Breakdown
SVC*HC:99213*150.00*105.00**1~
│ │ │ │ └─ SVC05: Quantity
│ │ │ └──── SVC04: (not used in 835)
│ │ └────────── SVC03: Service payment amount (allowed)
│ └────────────────── SVC02: Service charge amount (billed)
└──────────────────────────── SVC01: Compound Service Code
HC = HCPCS/CPT
99213 = procedure code
SVC01 format: QualifierCode:ProcedureCode:Modifier
Examples:
HC:99213 → Office visit, established, moderate complexity
HC:99213:25 → Office visit with modifier 25 (significant separate E/M)
HP:90837 → Procedure code (psychotherapy 60 min)
NU:A4253 → HCPCS medical supply codeAfter the SVC segment, CAS segments appear at the service line level explaining adjustments on that specific procedure code. Then REF segments carry the line item control number — critical for matching back to the original 837 service line. The DTM*472 segment provides the service date for that line.
One important parsing gotcha: the SVC segment can appear without service-line-level CAS adjustments if all adjustments happened at the claim level. Your parser must handle both patterns — claim-level-only adjustments and mixed claim/line-level adjustments.
Auto-Posting Workflows: How 835 Integrates with Your PM System
Auto-posting — having your PM system automatically apply 835 ERA data to open claims — is the single highest-ROI workflow improvement for a busy billing department. A billing team handling 500 claims per day cannot manually post every remittance; auto-posting takes that work from hours to minutes.
The Auto-Posting Decision Tree
A well-designed auto-posting engine follows this logic for each CLP segment:
Match the claim
Match CLP01 (patient control number) back to the original open claim. If no match, route to a worklist for manual review — never create a claim from the 835.
Check CLP02 status
If CLP02 = 4 (denied), post a $0 payment with denial reason. Flag for follow-up based on the CAS codes — do not write anything off automatically on a denial.
Validate the payment amount
Confirm CLP04 (payment) + CLP05 (patient responsibility) + all CAS adjustment amounts equal CLP03 (total charges). If they do not balance, route to exception queue.
Apply contractual adjustments
CAS segments with group code CO → write off. CAS segments with group code PR → post as patient responsibility balance. CAS segments with OA → review rules for whether to write off or balance-bill.
Post service-line payments
For each SVC segment, apply the SVC03 payment to the corresponding procedure line. Match using SVC01 (procedure code) and REF*6R (original line item control number from the 837).
Close or balance forward
If all lines are posted and no balance remains, close the claim. If a PR patient responsibility amount remains, leave open and send a patient statement. If the claim had COB forwarding (CLP02=19), leave open for secondary.
Auto-Posting Rates: What to Expect
A well-tuned auto-posting configuration typically achieves 85–92% straight-through processing (STP) — meaning that percentage of ERA lines are posted without human intervention. The remaining 8–15% go to exception queues for manual review.
Common Denial Codes and What to Do About Them
Denials are where the 835 delivers its most actionable intelligence. The CARC code tells you why the claim was denied; the RARC (Remittance Advice Remark Code, found in the REF*HE segment) provides supplemental explanation. Together, they give you enough information to triage every denial automatically.
Building a denial management workflow starts with categorizing denials by root cause. The most common actionable categories:
Eligibility Denials (CO-27, CO-31, CO-96)
~28% of denialsRoot cause: Patient was not eligible at date of service; policy terminated; payer not primary
Fix: Implement pre-visit eligibility verification via 270/271. See our guide on real-time eligibility to eliminate this category entirely. EDI 270/271 Eligibility Guide
Authorization Denials (CO-15, CO-57)
~18% of denialsRoot cause: Service required prior authorization that was not obtained
Fix: Implement 278 prior authorization workflows. Build PA requirement lookups into scheduling workflows. HIPAA EDI Compliance Guide
Coding Denials (CO-4, CO-11, CO-97)
~22% of denialsRoot cause: Procedure/diagnosis mismatch, modifier error, or bundling issue
Fix: Real-time coding validation at point-of-care. Use claims editing software to catch errors before submission.
Timely Filing (CO-29)
~12% of denialsRoot cause: Claim not submitted within payer's filing deadline (typically 90–365 days from DOS)
Fix: Monitor unfiled claims daily. Always retain 997/999 acknowledgments as timely filing proof.
Duplicate Claims (CO-18)
~8% of denialsRoot cause: Claim submitted more than once with same patient/provider/DOS/procedure combination
Fix: Implement duplicate claim detection before submission. Track ICN numbers to prevent resubmission of paid claims.
Reconciliation Best Practices
The 835 is the source of truth for reconciling EFT deposits against your general ledger. Each BPR segment (Basic Property / Payment) in the 835 contains the payment amount (BPR02), the payment method (BPR04: ACH for EFT, CHK for check), and the payment trace number (TRN segment that follows) which matches to your bank statement.
835-to-Deposit Reconciliation Workflow
- Pull all 835 files received in the target period. Extract BPR02 (payment amount) and TRN02 (trace/check number) for each transaction set.
- Match TRN02 values to your bank statement transaction IDs. Each EFT deposit should correspond to one 835 TRN segment.
- Verify that the sum of all claim-level payments (CLP04) in the 835 equals BPR02. If not, the 835 has a segment-level error — report to the payer.
- After posting all CLP payments, verify that your PM system's posted payment total for that ERA equals BPR02. Any discrepancy indicates a posting error.
- For payments received in month N but applying to claims from month N-1, ensure your month-end process captures these correctly — critical for accrual accounting.
- Retain all 835 files for at least 7 years for audit purposes. Many practices store them in a document management system cross-referenced by payer and TRN number.
Related Reading
Frequently Asked Questions
Q: How is the 835 different from an EOB (Explanation of Benefits)?
An EOB is the consumer-facing document that payers send to patients explaining how their claim was processed. An ERA (835) is the provider-facing electronic version containing the same financial information in a structured machine-readable format. They cover the same claim data but are structured for different audiences. The 835 includes machine-parseable segment codes (CARCs, RARCs) designed for billing software, while the EOB uses plain English.
Q: Can I receive a 835 for every payer I work with?
Technically yes — HIPAA requires covered payers to send 835s when paying electronically. However, some smaller payers may still send paper EOBs with paper checks, which is technically non-compliant but enforcement is limited. For major commercial payers, Medicare, and Medicaid, 835 ERAs are universally available. You typically enroll through the payer's provider portal or through your clearinghouse's ERA enrollment service.
Q: What is the difference between a CARC and a RARC?
A CARC (Claim Adjustment Reason Code) explains why the payment differs from the billed amount — it appears in the CAS segment. A RARC (Remittance Advice Remark Code) is supplemental information that further clarifies a CARC, often providing patient-friendly language or additional detail. RARCs appear in REF*HE segments and in the LOIN code on Medicaid 835s. The most important RARC to know is N-6 (used with CO-197) which indicates bundling.
Q: How do I handle 835 reversals (CLP02 = 22)?
A reversal (takeback) is the payer recovering a previous payment. When you receive CLP02=22, you must: 1) Reverse the original payment posting in your PM system, 2) Restore the claim balance to the original amount, 3) Determine if the reversal is correct (sometimes payers reverse by mistake), 4) If correct, determine the root cause and whether to refile. Many reversals happen due to coordination of benefits issues or post-audit recoupments.
Q: What auto-posting rate should I expect, and how do I improve it?
Most practices see 75–85% auto-posting rates initially, with well-optimized configurations reaching 90–92%. The biggest improvements come from: consistent patient control numbers (making claim matching reliable), comprehensive payer-specific balance billing rules (so PR adjustments are handled automatically), and proactive eligibility verification (reducing the eligibility denials that require manual review). Each manual exception should be analyzed — if the same pattern recurs, it should become an auto-posting rule.