ERA vs EOB: What Each One Is and Who Gets It

The Electronic Remittance Advice (ERA) is the X12 835 transaction that payers send to providers (or their clearinghouses) electronically detailing how a batch of claims was adjudicated. HHS has adopted ASC X12 835 version 005010X221 and its errata as the standard for the ERA transaction, and it applies to all HIPAA-covered entities (CMS, EFT and ERA Transactions Basics, read 17 September 2026). The 835 contains structured claim-level and line-level data including the billed charge, the contractually allowed amount, the payer payment amount, the patient responsibility (deductible, coinsurance, copay), the contractual write-off, and any adjustments coded with CARC (Claim Adjustment Reason Code) and RARC (Remittance Advice Remark Code). The ERA also carries the TRN (Reassociation Trace Number) that links the remittance to the corresponding EFT bank deposit. Timing is set by the federally mandated CAQH CORE Payment and Remittance operating rules — see “ERA Without EFT, EFT Without ERA” below for what the rule actually requires, which is a window around the deposit date rather than a deadline after it.

The Explanation of Benefits (EOB) is the patient-facing statement that payers send to patients explaining how a claim was adjudicated. It typically arrives by mail (older payers) or through the payer's patient web portal. The EOB lists the services the patient received, the billed charge, the allowed amount, what the plan paid, the patient's responsibility, and any reason codes for non-coverage in plain language ('this service is not covered by your plan,' 'you have not met your deductible'). Most EOBs carry a prominent line saying the document is not a bill, because patients otherwise confuse it with a provider invoice — but the wording is a plan convention, not a federally prescribed form. What federal law actually regulates is the notice a plan owes a claimant when it denies a claim: the Department of Labor's ERISA claims-procedure rules govern that notice for employer-sponsored plans, and the Affordable Care Act's internal claims and appeals requirements extend comparable notice and appeal rights to non-grandfathered coverage in the group and individual markets. Plans generally fold the required content into the same statement they call an EOB, which is why layouts differ from payer to payer while the content elements are broadly similar.

The provider's posting source of truth should always be the ERA, not the EOB. The ERA is structured, complete, and machine-readable — it carries the CARC and RARC codes, the contractual adjustments, and the TRN reassociation that lets posting systems automate the work. The EOB is the patient's plain-language version, lacks the structured adjudication codes, and is not designed for provider posting. Practices that wait for paper EOBs to post payments operate slower (because EOBs are mailed to the patient and copies sometimes drift to providers), are more error-prone (because manual interpretation replaces machine-readable codes), and miss the TRN reassociation that automates bank deposit matching. The ERA exists to be the provider's primary remittance source; the EOB exists to communicate with the patient.

The 835 ERA includes information critical to provider operations that does not appear on the patient EOB. CARC codes tell the provider exactly why an adjustment was made and trigger appeal workflows — code 197, for example, is the one payers return when a required precertification or authorization was not obtained before the service, and code 50 is the one they return when the payer's own coverage criteria did not find the service medically necessary (a payer determination, not a clinical finding). The official descriptions are maintained by X12 and published at x12.org; we paraphrase rather than reproduce them. RARC codes provide additional adjudication detail. Group codes (CO, PR, OA, PI) identify financial responsibility (provider write-off vs patient responsibility vs other). The TRN matches the remittance to the bank deposit. The provider-level adjustments section identifies forwarding balances, take-backs, and recoupments. Service-line-level detail breaks the adjudication out by individual procedure. None of this is on the patient EOB, which translates the same outcomes into 'you owe $X' or 'your plan paid $Y' without the underlying adjudication codes.

Two patterns of confusion appear frequently. First, a patient calls the practice asking about a charge on their EOB; the practice's billing team asks the patient to fax or email the EOB to investigate the discrepancy. The EOB is not the practice's primary record — the practice already has the corresponding ERA detail, and looking up the patient's claim in the practice management system using the date of service and member ID will produce the same adjudication detail with more granularity than the patient's EOB carries. Second, a practice is waiting to post a payment because 'the EOB hasn't arrived' — when the practice should be looking at the ERA imported from the clearinghouse. The EOB is going to the patient's home address; the ERA is going to the practice's clearinghouse. Different documents, different delivery.

ERA enrollment and EFT enrollment are usually paired but technically separate. A practice can be enrolled in ERA only (electronic remittance, paper check payment), in EFT only (electronic payment, paper remittance or none), or in both.

What the operating rules actually require. Operating rules for EFT and ERA, required by the Affordable Care Act, became mandatory on 1 January 2014, and CAQH CORE is the HHS-designated authoring entity for them. The rule that governs timing is the CAQH CORE Payment and Remittance (CCD+/835) Reassociation Rule — the federally mandated version of which was published as Phase III CORE 370, so you will see both names. Its requirement is a window, not a deadline: the health plan must release the 835 to the provider no sooner than three business days before the CCD+ effective entry date of the corresponding EFT, and no later than three business days after it. Two consequences matter operationally. First, the anchor is the EFT's effective entry date, not the day the money lands in your account or the day the claim was adjudicated. Second, an ERA that arrives before the deposit is compliant and normal — it is not an error, and a posting workflow that assumes remittance always follows money will strand those files. (Rule text read at caqh.org on 17 September 2026; CAQH describes the operating-rule requirements as a floor, not a ceiling, so an individual payer may do better.)

Enrolling in both is what makes automated posting work: TRN reassociation matches the EFT deposit to the ERA detail. ERA-only enrollment is workable but loses the deposit matching; EFT-only enrollment loses the structured adjudication detail. Under the administrative simplification rules, health plans must conduct the standard EFT and ERA transactions with a provider when the provider asks them to — so the practical question is usually whether you have enrolled, not whether the payer supports it.

ERA files arrive at the clearinghouse and flow to the practice management system either through automated import (most modern systems) or manual download. Each ERA file contains adjudication detail for a batch of claims paid in the same payer cycle — sometimes one claim, sometimes hundreds. The system parses the file, posts the payments and contractual adjustments to each claim, updates claim status, and routes coded denials to the denial work queue. Provider-level adjustments (take-backs, recoupments) post as separate transactions.

What decides whether any of that is trustworthy is the exception lane. We do not publish an auto-post percentage, because the honest answer is that it is a function of your payer mix, your contract load and your system's CARC mapping, not of the vendor — any single figure quoted without those three things is decoration. What is worth publishing is the exception report itself, and the rule that every line on it is worked by a person before the day closes.

Illustrative daily ERA/EFT exception report (the payers, amounts and dates below are invented to show the shape of the report, not drawn from any client file):

The human review lane. Automated posting handles the lines that match a known payer, a known contract rate and a known CARC. Everything else — every row above — goes to a person the same day. The failure mode worth naming is the opposite of the one people expect: it is not that automation posts too little, it is that a loosely configured system force-posts an exception as a contractual adjustment, which makes an underpayment or a recoupment disappear into a write-off bucket nobody reviews. Exceptions are where revenue leaks, and an exception that was auto-resolved is still an exception.