
In healthcare billing, 835 refers to the ASC X12N 835 Health Care Claim Payment/Advice, the HIPAA-standard electronic remittance advice (ERA) a payer sends a provider after adjudicating claims. The 835 file details what was paid, adjusted, or denied on each claim, including patient responsibility and adjustment reason codes, so payments can be posted and reconciled electronically instead of keyed by hand.
An 835 file is the electronic remittance advice a health plan transmits to a provider after processing a batch of claims. “835” and “ERA” are two names for the same transaction: ERA is the business term, 835 is the X12 transaction set number.
The flow is always payer to provider. After adjudication, the payer generates an 835 covering every claim in that payment cycle (paid, adjusted, reversed, or denied) and delivers it through a clearinghouse or directly to the provider.
The 835 should not be confused with the EOB. An explanation of benefits is the human-readable version of the same adjudication decision, often on paper. The 835 is structured data a computer can post; the EOB is prose a person has to read. We cover the distinction in EOB vs ERA: what’s the difference.
The 835 is a HIPAA-mandated standard, not an optional convenience. Under 45 CFR Part 162, covered entities that send electronic remittance advice must use the ASC X12N 835 transaction set, currently in version 5010 (technically, TR3 005010X221A1).
A standard format does not mean identical files, though. Every payer publishes a companion guide that constrains how it populates the 835 within the TR3: which situational fields it sends, how it batches claims, how it reports certain adjustments. In 20 years at Revenue Management Solutions, we often see payers whose 835 look very different, which is why posting logic that works flawlessly for one payer can misfire on another.
An 835 is built from a handful of segments, and a few of them do almost all the work. Knowing what each one carries makes remittance problems far easier to diagnose.
BPR: the money. The BPR segment states the payment method (ACH, check, or non-payment notification), the total payment amount, and the payment date. BPR02 is the dollar figure the entire file must balance to.
TRN: the trace number. The TRN segment carries the reassociation trace number that uniquely ties the remittance to its payment. The same number appears in the bank’s ACH record, letting you match a deposit to its 835.
CLP: what happened to each claim. Each claim gets one CLP segment (Loop 2100) reporting the patient control number (CLP01), claim status (CLP02), billed amount (CLP03), paid amount (CLP04), and patient responsibility (CLP05). The CLP02 status codes: 1, 2, and 3 mean processed as primary, secondary, or tertiary; 4 means denied; 22 means a reversal of a previous payment. One nuance the 835 TR3 itself spells out: status 4 “denied” applies only when the payer does not recognize the patient. A recognized patient whose claim paid $0 still reports as 1, 2, or 3, so posting logic that treats every zero-pay claim as a denial will misclassify it.
CAS: why paid differs from billed. CAS segments explain every dollar of difference between billed and paid using triples of a group code, a claim adjustment reason code (CARC), and an amount. The group codes seen in practice are CO (contractual obligations), PR (patient responsibility), OA (other adjustments), and PI (payer-initiated reductions). X12 maintains the CARC and RARC lists and updates them three times a year, so code mappings need scheduled maintenance, not a one-time setup.
SVC: line-level detail. SVC segments (Loop 2110) break the claim payment down to individual service lines, so systems can post at the procedure level.
PLB: adjustments that belong to no claim. The PLB segment carries provider-level adjustments: interest, overpayment recoupments, withholds, and cost report settlements. One sign convention trips up nearly every posting team we work with at RMS: a positive PLB amount decreases the payment. A $500 recoupment shows as positive $500 and subtracts from the check.
The balancing rule ties it all together: the total payment in BPR02 must equal the sum of all claim payment amounts (CLP04) net of PLB adjustments. That arithmetic guarantee is what makes automated posting and reconciliation possible.
The 837 is the electronic claim a provider sends to a payer; the 835 is the electronic remittance the payer sends back. If the 837 is the bill going out, the 835 is the itemized statement of what was actually paid, and why, coming back.
The two are linked by design: the patient control number a provider submits on the 837 comes back in CLP01 of the 835, which is how posting systems match remittances to the original claims.
The 835 exists so that payment posting can run without human keying: every element a poster needs is machine-readable. CLP04 posts the payment, CAS triples route adjustments and denials to the correct buckets, SVC lines post at the procedure level, and TRN reconciles the file to the bank deposit.
Reassociation is the reconciliation half of that equation. HIPAA standards require the payer to carry the same TRN trace number in the 835 and in the addenda record of the ACH CCD+ payment, according to CMS’s guidance on EFT and ERA reassociation. The CAQH CORE 370 rule, part of the operating rules that took effect January 1, 2014, requires health plans to release the ERA within three business days of the EFT effective date, close enough that payment and remittance can actually be matched.
In practice, clean auto-posting rates never reach 100%. What falls out: PLB entries whose sign convention gets misread, reversals (CLP02 = 22) that need the original posting backed out first, claims split across multiple 835s, and payer companion-guide quirks. At Revenue Management Solutions, we work these exceptions daily for health systems and catalog the failure patterns in payment posting: what goes wrong.
The biggest gap in 835 processing is the remittance volume that never arrives as an 835 at all. According to the 2023 CAQH Index, fully electronic remittance advice adoption reached 88% in the medical industry in 2023, yet roughly 161 million remittances were still handled manually and another 365 million only partially electronically. That is over half a billion remittances a year arriving as paper EOBs, faxes, and portal downloads instead of clean 835s. CAQH estimates full electronic adoption would save medical providers $701 million annually and about five minutes per remittance transaction.
Two levers close the gap. ERA and EFT enrollments move every payer that supports the 835 onto it, and EOB-to-ERA conversion turns the residual paper and portal remittances into posting-ready 835 files. This is the core of what RMS does as a remittance management specialist: founded in 2006, US-based and AI-first, we have processed over 1 billion healthcare transactions in the last 5 years, converting paper EOBs into postable ERAs so the entire remittance stream, not just the electronic share, flows through one automated posting process.
Yes. ERA (electronic remittance advice) is the business name and 835 is the technical name for the same transaction: the ASC X12N 835 Health Care Claim Payment/Advice mandated under HIPAA. An EOB, by contrast, is the human-readable version, often on paper.
The 837 is the electronic claim a provider sends to a payer; the 835 is the electronic remittance the payer sends back. Think of the 837 as the bill and the 835 as the itemized statement of what was actually paid, and why.
Usually because of PLB adjustments (recoupments, interest, or withholds applied at the provider level) or because the ERA and EFT arrived separately. The TRN trace number in the 835 matches the trace number in the ACH addenda record, letting you reassociate each deposit with its remittance.
No. While 88% of medical remittance advice was fully electronic per the 2023 CAQH Index, hundreds of millions of remittances still arrive each year as paper EOBs or portal downloads. Providers typically close that gap with ERA enrollments and EOB-to-ERA conversion.
If your posting team is still keying remittances that should arrive as 835s, or working exception queues full of PLBs and reversals, we can help. Talk to RMS about what your 835 workflow could look like.
Sources cited: 2023 CAQH Index Report (caqh.org) · CMS.gov guidance on EFT and ERA reassociation · ASC X12N 835 TR3 005010X221A1 · 45 CFR Part 162 (HIPAA transaction standards) · CAQH CORE 370 EFT & ERA Reassociation Rule
Explore the latest RMS news, insights, and resources in one place.