EOB vs ERA in Medical Billing: What Is the Difference?

Short answer

An EOB (Explanation of Benefits) is a human-readable document a payer sends to the patient after adjudicating a claim. It states what was billed, what was allowed, and what the patient owes. An ERA (Electronic Remittance Advice) is the machine-readable equivalent sent to the provider's billing team as an X12 835 transaction, the HIPAA-adopted standard. Both describe the same adjudication event for different audiences. The ERA arrives through a clearinghouse, carries standardized Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs), and can post automatically in a practice management system. The EOB lands in a patient's mailbox or member portal and cannot be auto-posted without manual rework. For a billing company running dozens of client practices, that gap decides how the team spends its day: keying paper remittances or working denials.

Sources: CMS — Health Care Payment and Remittance Advice · CMS MLN ERA/EFT Resources

---

What is an EOB, exactly?

The Explanation of Benefits is a summary the payer sends to the patient after a claim is adjudicated. It is not a bill. It tells the patient which services were covered, the payer's allowed amount, any contractual write-offs, amounts applied to deductible or coinsurance, and the remaining balance.

Format varies by payer. Medicare sends paper or PDF EOBs through its Medicare Summary Notice. Commercial payers usually display them in a member portal, and some still mail physical copies. None of it is structured in a way a billing system can ingest.

Providers sometimes receive an EOB alongside or in place of a paper remittance, often from smaller payers or during enrollment delays. That paper still requires a person to read it and key the payment and denial data into the PM system by hand.

Sources: CMS Medicare Summary Notice information

---

What is an ERA, and why does the 835 matter?

The Electronic Remittance Advice is the structured file that tells a provider's billing system how a claim was paid or denied. The HIPAA-adopted standard for it is the ASC X12 835 Version 5010, usually called "the 835" or "an ERA."

Covered payers must use this standard for ERA transactions. The 835 encodes the same adjudication data as an EOB (amounts billed, allowed, adjusted, and paid) in a format a practice management system or billing platform can parse, match to outstanding claims, and post automatically.

The 835 uses CARCs (Claim Adjustment Reason Codes) to explain every line-level adjustment: code 45 for a fee-schedule contractual write-off, code 97 for a service bundled into another procedure's payment. RARCs add supplemental context. These codes are maintained by X12 and the industry's code list maintainers and are the same across payers, which is what makes 835 posting automatable.

Sources: CMS — ERA/EFT Administrative Simplification · X12.org EDI Examples

---

How do EFT and the 835 fit together?

EFT (Electronic Funds Transfer) and the ERA are two transactions that describe the same payment from different angles. EFT moves the money, typically via ACH CCD+, from the payer's bank to the provider's bank. The 835 explains what that money covers: which claims, which lines, what was adjusted.

The link between them is the TRN segment. Under CAQH CORE Phase III operating rules, mandatory since January 1, 2014, payers must embed the same TRN (Trace Number) segment in both the ACH CCD+ addenda record and the matching 835 file. The billing system uses it to reassociate the deposit with the remittance, confirming the ERA explains exactly what hit the bank account.

The X12 820 is worth distinguishing here. It is a separate standard for premium payment, such as an employer paying a health plan for group coverage. It is not a remittance document and plays no role in claim payment posting. It lives in benefits administration, not provider RCM.

Sources: CMS EFT and ERA Reassociation Basics · CAQH CORE Phase III EFT & ERA Operating Rules

---

EOB vs ERA: side-by-side comparison

---

How does ERA posting actually work?

After a payer adjudicates claims and issues payment, the 835 travels from the payer through a clearinghouse to the billing company's PM system. The posting workflow runs roughly like this:

• The 835 is ingested and parsed. CLP (Claim Payment) segments map to individual claims; SVC (Service Payment) segments map to individual service lines.
• The system matches each CLP to an open claim by the payer's claim control number or the original claim ID.
• Allowed amounts, contractual adjustments (identified by CARC), and paid amounts post at the line level.
• Denied lines post with $0 payment and the applicable CARC, which tells the poster why the line was rejected, not just that it was.
• The ERA is reconciled against the EFT deposit using the shared TRN trace number.
• Claims with no matching open claim in the system queue for manual review.

A well-built billing platform surfaces denied-line CARCs in the work queue so staff act on them without opening the raw 835. That closes the loop between payment received and denial worked in one session.

Sources: FCSO Medicare — Electronic Remittance Advice · CMS ERA/EFT Operating Rules

---

Why do billing companies standardize on ERA over paper EOBs?

A billing company running twenty client practices cannot have staff hand-key payment data from paper or PDF remittances. Every manual entry risks a keying error, delays A/R close, and can bury a denial that never gets worked.

ERA enrollment with payers, requesting that remittances arrive as 835 files instead of paper, pays back faster than almost any other setup step. Once a payer connection is active, posting becomes a confirmation step instead of data entry, and staff time moves to the exceptions: short-pays, coordination-of-benefits claims, and denied lines that need a second look.

Accuracy improves too. Because CARC and RARC codes are standardized across payers, a billing system can route denial categories consistently: CO-45 contractual adjustments close automatically, PR-96 non-covered charges bill to the patient, CO-4 service-line mismatches go to the coding queue. A paper EOB needs a person to interpret payer-specific wording before any of that routing can happen.

Sources: CMS Administrative Simplification — ERA/EFT

---

How Medi handles ERA posting

Medi imports 835 files through Stedi and maps them at the service-line level. Each SVC segment posts against its claim line. Denied lines land at $0 with the CARC shown on the line action surface, not buried in a raw file viewer. The TRN trace number sits alongside the payment record so staff reconcile against the EFT deposit without switching tools.

Denied lines feed straight into the denials work queue, and the CARC drives the routing, so a poster does not identify denials by hand. CO-45 contractual adjustments close without action. Lines that need follow-up appear in the queue with the denial reason already attached.

Medi does not replace the manual step for payers that still send paper. A poster keys those entries. The platform is built for ERA-first work and pays off most when the majority of a practice's payers are enrolled for 835 delivery.

See how posting works in Medi · Request a demo

---

When Medi is not the right fit

Medi is built for billing companies that manage RCM across multiple client practices. It is not a good fit for:

• Solo or small practices that bill in-house and do not need multi-practice management
• Operations whose main need is clinical documentation, coding assistance, or prior authorization
• Teams that need a patient-facing portal as the core product; Medi's patient tools support the billing workflow, not patient self-service
• Practices where most payers do not support 835 enrollment and paper remittance posting is the primary workflow

If your operation fits one of those, a practice management system with built-in billing or a clearinghouse-adjacent tool will likely serve you better than a billing-company platform.

---

Frequently asked questions

Can I use an EOB to post payments instead of an ERA?

You can, but it is slow and error-prone. An EOB carries the same adjudication data as an ERA, but it is formatted for a patient, not a billing system. Posting from one means a person reads the document, identifies each service line, interprets the payer's written explanation, and keys the amounts. That takes far longer than importing a 835, adds transcription risk, and makes consistent denial routing harder because the wording varies by payer. Some billing companies use EOBs as a fallback before a payer is enrolled for ERA, but most treat enrollment as a priority precisely to get off paper.

Is an ERA the same as an EFT?

No. They are two separate transactions for the same payment. The EFT moves money, an ACH transfer from the payer's bank to the provider's. The ERA (the 835) explains what that money covers: which claims, which service lines, what was adjusted and why. CAQH CORE Phase III rules, mandatory since 2014, require payers to link the two with a shared TRN trace number so billing systems can match the deposit to the remittance. You need both to close a payment cleanly: the EFT confirms the deposit arrived, the ERA tells you how to post it.

What are CARCs and why do they matter in ERA posting?

CARC stands for Claim Adjustment Reason Code. Every adjustment on a 835, whether a contractual write-off, a non-covered service, or a coordination-of-benefits reduction, carries a CARC that names the reason in a standardized code. CARCs are maintained by the industry's code list maintainers and stay consistent across payers under HIPAA. That standardization is what makes automated denial routing possible: a platform reads CARC 45 (contractual obligation write-off) and closes the adjustment, or reads CARC 4 (service described inconsistently) and routes the line to a coding queue. Without standard codes, every payer's remittance would need its own interpretation logic.

Why do payers send EOBs to patients and ERAs to providers — why not just one document?

They serve different purposes. The EOB is a consumer disclosure: it tells the patient what the insurer did with their claim, what they owe, and how to appeal. Regulators require it so patients can verify their benefits were applied correctly. The ERA is an operational transaction that gives the billing team the machine-readable data to post payment and work denials. The content overlaps, but the format, recipient, and regulatory purpose differ. A patient does not need a raw 835, and a billing system cannot auto-post from a PDF sent to a patient mailbox.

What is the X12 820, and is it related to ERA posting?

The X12 820 is the EDI transaction for premium payment, an employer or individual paying a health insurance premium to a payer. It is separate from the claim payment cycle. The 820 moves money employer-to-payer; the 835 moves explanation payer-to-provider. A billing company working provider RCM handles 837 (claim submission), 835 (remittance), 270/271 (eligibility), and 276/277 (claim status) daily. The 820 is a benefits administration transaction that almost never shows up in that workflow.

Does every payer have to send an ERA if requested?

Under HIPAA, covered health plans must support ERA transactions when a provider requests them. In practice, some smaller payers, such as certain state Medicaid services or very small regional plans, have technical limits or slow enrollment. Enrolling through a clearinghouse is usually the practical path: the clearinghouse manages payer connections and can often receive 835 files even when a payer offers no direct ERA enrollment to individual providers. For payers that genuinely cannot produce a 835, paper remittance stays the fallback, and staff post those by hand.