Overview
The 835 file is the HIPAA-standardized electronic data interchange format that payers use to transmit remittance advice to providers. The full ANSI name is ASC X12N 835 Health Care Claim Payment/Advice. Where the 837 carries claims from provider to payer, the 835 carries the payer's adjudication results back — by claim, by service line, with the full set of adjustments, reason codes, and payment references.
Structurally, an 835 opens with a payer-level envelope describing the payer, the total payment (check or EFT amount), and the payment method. It then iterates over claims (CLP segments), each followed by service-line adjustments (SVC segments) and claim adjustment reasons (CAS segments). Each CAS segment specifies an adjustment group (CO — contractual obligation, PR — patient responsibility, OA — other adjustment, PI — payer-initiated) and a CARC (claim adjustment reason code). Supplementary RARC remark codes provide further detail via LQ segments.
The 835 is the data source for automated payment posting. Practice management and hospital billing systems parse the 835, match each CLP to the original claim via the patient account number, apply the payment to the matching charge, post contractual adjustments to the CO bucket, and pipe patient responsibility to the patient AR and statement cycle. When the 835's patient-account-number doesn't match (wrong account, duplicate payment), the claim goes to an exception queue for manual reconciliation.
Adjudication interpretation is non-trivial. A service line paid at half of billed might be fully contracted (CARC 45), partially denied for medical necessity (CARC 50), reduced for multiple-procedure reduction (CARC 59 or CARC 97), or reduced for patient coinsurance (CARC 2). Each requires different downstream work. A mature revenue cycle posts the payment, categorizes the adjustments correctly, routes denials to the appropriate work queue (medical necessity → clinical review, authorization → PA specialist, timely filing → escalation), and surfaces trends for process improvement.
835 processing is also the input to denial analytics. Shift in CARC distribution, spike in specific RARC, payer-level adjudication pattern changes — all show up first in the 835 stream. Mature RCM programs build denial dashboards directly from 835 data.
In day-to-day revenue-cycle operations, 835 File (Electronic Remittance Advice) is most useful as a diagnostic — a sudden move in 835 File (Electronic Remittance Advice) almost always points upstream to a front-end workflow that has drifted: eligibility coverage, scheduling, registration, charge capture, or coding turnaround. Reviewers on this site therefore pair every 835 File (Electronic Remittance Advice) reading with era 835 and 837 file in the same weekly dashboard view, so the story a single metric tells cannot hide a broader pattern. The most common mistake teams make with 835 File (Electronic Remittance Advice) is reacting to the headline number rather than decomposing it by payer, provider, and specialty; once the outlier segments are visible, the remediation step is usually obvious and cheap.
Industry benchmark
ASC X12N TR3 835 5010. CAQH CORE ERA/EFT operating rules. HFMA: automated 835 posting rates of 85%+ are healthy; exception rates below 10% indicate good master-data hygiene between payer and provider.
Worked example
A payer issues a single EFT of $127,400 to a 12-physician practice. The accompanying 835 file contains 412 claims with 1,190 service lines. Auto-posting matches 1,155 lines to the correct patient accounts, applies $80,200 in line-level payments, posts $39,800 in contractual adjustments, and pipes $7,400 in patient balances to the statement cycle. 35 lines go to an exception queue — 10 for patient-account mismatches, 15 for denied claims needing work-queue routing, 10 for refund scenarios.
Frequently asked questions — 835 File (Electronic Remittance Advice)
Are 835 and ERA the same thing?
Effectively yes. 835 is the technical format name; ERA (Electronic Remittance Advice) is the business-function name. Most people use them interchangeably. When specificity matters, 835 refers to the file format and ERA to the adjudication information that the file carries.
How do 835 files get to providers?
Via clearinghouse — the payer generates the 835, the clearinghouse routes it to the provider's EDI channel, and the provider's practice management or hospital billing system ingests it. Direct payer-to-provider 835 delivery exists but is uncommon outside very large health systems.
What happens when a payment doesn't match a claim in the 835?
It goes to an exception queue. Common causes: patient account number typo, claim already closed or paid, duplicate payment, refund or take-back scenario. Manual reconciliation resolves most; patterns of exceptions often point to a payer master-data or claim-submission issue.
Does the 835 include denial reasons?
Yes, via CARC (Claim Adjustment Reason Codes) and RARC (Remittance Advice Remark Codes). Each line adjustment carries a CARC indicating the adjustment reason. RARCs are supplementary. Denial analytics built from 835 data is a core RCM reporting capability.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.