EOB vs ERA (835): what's actually in each.

What is the difference, in one table?

The consequence for anyone building against these: an EOB is a document to be read, an ERA is a file to be parsed. The EOB has no guaranteed structure across plans; the 835 has a published one.

What is an EOB?

An Explanation of Benefits is the summary a health plan sends a member after a claim is processed. It typically shows the provider's charge, the allowed amount, what the plan paid, and what the member may owe. It is not a bill — CMS is explicit about this, because the single most common misreading is treating the patient-responsibility figure as a demand for payment. A bill, if one is due, comes separately from the provider.

There is no national EOB standard. Layout, wording and the level of code detail are the plan's own design, which is why EOBs cannot be parsed generically the way an 835 can. Medicare's member-facing equivalent is the Medicare Summary Notice.

What is an ERA, and what is the 835?

An Electronic Remittance Advice is the payer's explanation of payment sent to the provider. Its format is the X12 835 Health Care Claim Payment/Advice. The version adopted as the HIPAA standard is 005010X221A1, and it is the version Medicare contractors send.

Where a provider needs the same information on paper, Medicare produces a Standard Paper Remittance (SPR). Under Chapter 22 of the Medicare Claims Processing Manual, the SPR mirrors the 835, but contractor software adds calculated fields that do not exist in the raw 835 — most notably the computed Net field (ProvPd plus interest, late-filing charges, less recoupments). CMS also distributes free software to read an 835 and print an SPR equivalent locally: MREP (Medicare Remit Easy Print) for professional providers and PC-Print for institutional providers, both obtained from the provider's Medicare contractor.

What is actually inside an 835?

An 835 is a nested structure: one payment, containing many claims, each containing service lines, each carrying adjustments. Six segments carry almost everything that matters for posting.

What are CARCs, RARCs and group codes?

Three different things, always read together, and routinely conflated.

• A Claim Adjustment Group Code (CAGC) says who bears the adjustment. Two alpha characters, internal to the X12 standard.
• A Claim Adjustment Reason Code (CARC) says why a claim or service line was paid differently than billed.
• A Remittance Advice Remark Code (RARC) adds explanation to an adjustment a CARC has already described, or conveys information about remittance processing. A RARC marked as an alert conveys information without an adjustment attached.

Both code lists are published as X12 external code lists: CARCs as list 139, and RARCs as list 411, which CMS maintains. They are updated three times a year, in early March, July and November, so a validation table built once and left alone will drift — a code deactivated in a November release will still arrive on remittances for claims adjudicated before it.

Beyond the raw lists, the CAQH (now DataSpring) CORE Uniform Use of CARCs and RARCs (835) rule — CORE 360 — constrains which combinations may be used, defining a set of business scenarios and the maximum set of CARC, RARC and group-code combinations permitted to convey each. It is the reason two payers describing the same denial should reach for the same codes.

How does an 835 balance?

At three levels, and a file that fails any of them is telling you something is missing rather than that the payer paid strangely.

• Service line level. The submitted charge for the line, less every adjustment reported against that line, equals the amount paid for it.
• Claim level. The claim's total charge, less every adjustment reported against it — at claim level and across its service lines — equals the claim payment amount.
• Transaction / Check level. The sum of all claim payment amounts, adjusted by the net of the provider-level adjustments in PLB, equals the total payment in BPR.

PLB signs are the single most common implementation trap: a positive PLB amount reduces the payment, and a negative amount increases it. A recoupment therefore appears as a positive number (e.g. 10.00) that subtracts from the claim total to produce the net BPR deposit. A reconciliation that ignores PLB will balance at claim level and fail at the bank.

How do you match a payment to its remittance?

The money and the explanation travel separately — an EFT through the banking system, the 835 through a clearinghouse or payer portal — and they arrive at different times. They are joined by a reassociation trace number: the value in the 835's TRN segment matches the trace number carried in the CCD+ addenda record of the EFT.

This is governed by the CAQH (now DataSpring) CORE EFT & ERA Reassociation (CCD+/835) rule, CORE 370, adopted by HHS. Sections of that rule oblige health plans to support the process and to address missing, delayed or incorrect reassociation data. When the trace numbers match, posting can be automated; when they do not, the payment sits unapplied in a suspense account.

Glossary

Official sources

• CMS — Health Care Payment and Remittance Advice: the 835, ERA, SPR, MREP and PC-Print.
• CMS — How to read a health insurance explanation of benefits.
• Medicare Claims Processing Manual, Ch. 22 — Remittance Advice (PDF).
• X12 — Claim Adjustment Reason Codes (List 139), including group code definitions, and X12 — Remittance Advice Remark Codes (List 411).
• X12 external code lists — the authoritative index, with maintainer and update schedule for each list.
• DataSpring (formerly CAQH) — CORE operating rules: CORE 360 (uniform use of CARCs and RARCs) and CORE 370 (EFT and ERA reassociation).
• CMS — EFT and ERA payment remittance reassociation basics (PDF).
• Related reference — Certified payroll electronic filing, state by state and WH-347, field by field.