EOB vs ERA in Medical Billing

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 a patient after adjudicating a claim — summarizing what was billed, what was allowed, and what the patient owes. An ERA (Electronic Remittance Advice) is the HIPAA-mandated machine-readable equivalent sent to the provider's billing team as an X12 835 transaction. Both documents describe the same adjudication event, but they serve different audiences and travel different paths. The ERA arrives via a clearinghouse, carries standardized Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs), and can drive automated payment posting in a practice management system. The EOB lands in a patient's mailbox or online portal and cannot be auto-posted without significant manual rework. For billing companies managing dozens of client practices, the distinction is operationally decisive: every hour spent keying paper EOBs is an hour not spent 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 document the payer generates and sends to the patient — not the provider — 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, the amounts applied to deductible or coinsurance, and the patient's remaining balance.

Format varies widely. Medicare sends paper or PDF EOBs through its Medicare Summary Notice. Commercial payers often display them in a member portal. Some mail physical copies. None of this is structured in a way a billing system can ingest directly.

Providers sometimes receive a copy of the EOB alongside or in lieu of a paper remittance — especially from smaller payers or during enrollment delays — but that paper document still requires a human to read it and key 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, machine-readable file that tells a provider's billing system exactly how a claim was paid or denied. The HIPAA-adopted standard for this transaction is the ASC X12 835 Version 5010 — often just called "the 835" or "an ERA."

Under HIPAA, covered payers are required to use this standard when conducting ERA transactions. The 835 file encodes the same adjudication information as an EOB — amounts billed, allowed, adjusted, and paid — but does so in a structured format that 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 included in another procedure's payment, and so on. RARCs add supplemental context. These codes are maintained by X12 and the industry's code list maintainers, and they are the same codes across payers — which is why 835 posting can be automated.

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

---

How do EFT and the 835 fit together?

EFT (Electronic Funds Transfer) and ERA (the 835) are two distinct transactions that describe the same payment event 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 the 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 corresponding 835 file. This allows the billing system to "reassociate" the deposit with the remittance, confirming that the ERA explains exactly what arrived in the bank account.

One more transaction worth knowing: the X12 820 is a separate EDI standard for premium payment — an employer paying a health plan for group coverage. The 820 is not a remittance document and plays no role in claim payment posting. It exists in the enrollment and benefits administration world, not in 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?

When a payer adjudicates claims and issues payment, the 835 file 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 — the file's CLP (Claim Payment) segments map to individual claims, and 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, not just that the claim was rejected.
• The ERA is reconciled against the EFT deposit using the shared TRN trace number.
• Unmatched claims — where the ERA has no corresponding open claim in the system — queue for manual review.

A well-structured billing platform surfaces denied-line CARCs directly in the work queue so staff can act on them without hunting through the raw 835 file. The goal is to close the loop between "payment received" and "denial worked" in the same session.

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

---

Why do billing companies standardize on ERA over paper EOBs?

The practical case is straightforward. A billing company managing twenty client practices cannot afford to have staff manually key payment data from paper or PDF remittances. Every manual entry is a potential keying error, a delay in closing A/R, and a missed denial that never gets worked.

ERA enrollment with payers — requesting that remittances arrive as 835 files rather than paper — is one of the highest-leverage administrative steps a billing company can take. Once a payer connection is active, posting becomes a confirmation step rather than a data-entry step. Staff time shifts from transcription to exception handling: the denied lines, the short-pays, the coordination-of-benefits claims that need a second look.

There is also an accuracy dimension. The CARC and RARC codes in a 835 are standardized across payers, so a billing system can apply consistent logic to route denial categories into the right work queue — CO-45 contractual adjustments close automatically, PR-96 non-covered charge gets billed to patient, CO-4 service-line mismatch goes to the coding queue. Paper EOBs require a human to interpret payer-specific language before any routing decision is possible.

Sources: CMS Administrative Simplification — ERA/EFT

---

How Medi handles ERA posting

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

Denied lines from an ERA feed directly into the denials work queue. A poster does not need to identify denials manually — the CARC drives routing. Lines with CO-45 contractual adjustments close without action. Lines with CARCs that require follow-up appear in the queue with the denial reason already attached.

For practices that still receive paper remittances from a minority of payers, Medi does not replace that manual step — a poster still keys those entries. The platform is built for ERA-first workflows and is most useful 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 — organizations that manage RCM across multiple client practices. It is not a good fit for:

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

If your operation fits one of those profiles, a practice management system with built-in billing features or a clearinghouse-adjacent tool may 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 contains the same adjudication data as an ERA, but it is formatted for a patient — not a billing system. Posting from an EOB means a human reads the document, identifies each service line, interprets the payer's written explanation of adjustments, and keys the amounts manually. That process takes significantly longer than importing a 835 file, introduces transcription risk, and makes it harder to route denials consistently because the language varies across payers. Some billing companies use EOBs as a fallback when a payer is not yet enrolled for ERA, but most treat ERA enrollment as a priority specifically to get off paper.

Is an ERA the same as an EFT?

No. ERA and EFT are two separate transactions that describe the same payment from different angles. The EFT moves money — an ACH transfer from the payer's bank to the provider's bank account. The ERA (the 835 file) explains what that money covers — which claims, which service lines, what was adjusted and why. CAQH CORE Phase III operating rules, mandatory since 2014, require payers to link the two using a shared TRN trace number so billing systems can match the deposit to the remittance. You need both to close out a payment properly: 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 — a contractual write-off, a non-covered service, a coordination-of-benefits reduction — carries a CARC that identifies the reason in a standardized code. CARCs are maintained by the industry's code list maintainers and are consistent across payers under HIPAA. This standardization is what makes automated denial routing possible: a billing platform can read CARC 45 (contractual obligation write-off) and close the adjustment automatically, or read CARC 4 (service described inconsistently) and route the line to a coding review queue. Without standardized 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 the patient owes, and what rights they have to appeal. Regulators require it because patients need to verify that their benefits were applied correctly. The ERA is an operational transaction — it gives the provider's billing team the machine-readable data they need to post payment and work denials. The content overlaps substantially, but the format, recipient, and regulatory purpose are different. A patient does not need a raw 835 file, 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 entirely separate from the claim payment cycle. The 820 moves money in the employer-to-payer direction; the 835 moves explanation in the payer-to-provider direction. Billing companies working provider RCM deal with 837 (claim submission), 835 (remittance), 270/271 (eligibility), and 276/277 (claim status) on a daily basis. The 820 is a benefits administration and enrollment transaction that almost never appears in a billing company's day-to-day workflow.

Does every payer have to send an ERA if requested?

Under HIPAA, covered health plans are required to support ERA transactions when a provider requests them. That said, some smaller payers — particularly state Medicaid programs for certain services or very small regional plans — may have technical limitations or slow enrollment processes. ERA enrollment through a clearinghouse is usually the practical path: the clearinghouse manages payer connections and can often receive 835 files even when a payer does not offer direct ERA enrollment to individual providers. For payers that genuinely cannot produce a 835, paper remittance remains the fallback, and billing staff post those manually.