Electronic Remittance Advice (ERA): Processing and Reconciliation

Electronic Remittance Advice (ERA) is the standardized electronic document that health plans transmit to providers after adjudicating a claim, detailing payment amounts, adjustments, and denial reasons for each service line. ERA processing and reconciliation sit at the operational core of the revenue cycle management workflow, translating insurer payment decisions into actionable accounting entries. Errors in ERA reconciliation are a primary driver of accounts receivable aging and underpayment accumulation. This page covers the regulatory framework, technical structure, processing mechanics, common operational scenarios, and decision boundaries that define ERA handling in the US healthcare billing environment.

Definition and scope

An ERA is the electronic equivalent of a paper Explanation of Benefits (EOB), formatted according to the HIPAA-mandated X12 835 transaction standard. The Centers for Medicare & Medicaid Services (CMS) and the Department of Health and Human Services (HHS) established the 835 transaction set as a covered transaction under 45 CFR Part 162, which implements the Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Any covered entity — including health plans, clearinghouses, and providers who transmit claims electronically — must be capable of conducting the 835 transaction when requested.

The scope of an ERA encompasses four core data domains:

1. Claim-level data — patient name, claim control number, date of service, total billed amount, total paid amount
2. Service-line data — individual procedure codes (CPT or HCPCS), submitted charge, allowed amount, contractual adjustment, patient responsibility, and payment
3. Adjustment reason codes — Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs), maintained by the Washington Publishing Company (WPC) under contract with X12 and CMS
4. Provider and payer identification — National Provider Identifier (NPI), Tax Identification Number (TIN), and payer ID

CARCs and RARCs are the machine-readable vocabulary of ERA data. CARCs explain why a payment differs from the billed amount (e.g., CARC 45 indicates a contractual adjustment); RARCs supply supplemental narrative. CMS publishes the CARC and RARC code sets through its Medicare Administrative Contractors (MACs) and updates them quarterly. Understanding these codes directly governs whether a denial enters the claim denial management workflow or is posted as a final, correct underpayment.

How it works

ERA processing follows a discrete sequence from payer transmission to final posting in the provider's practice management system (PMS) or hospital information system (HIS).

Step 1 — Transmission. After a payer adjudicates a claim, the ERA is transmitted via an enrolled trading partner relationship. Most providers receive ERAs through a clearinghouse, which translates and routes the X12 835 file. Direct payer-to-provider EDI connections exist but are less common among smaller practices.

Step 2 — File receipt and parsing. The clearinghouse or billing system ingests the 835 file and parses it into loops and segments per the X12 Technical Report Type 3 (TR3) implementation guide. The 835 transaction is organized into hierarchical loops: the header loop (BPR/TRN segments carrying payment amount and check/EFT number), the payee loop (REF, N1 segments), the claim loop (CLP segment), and the service line loop (SVC segment).

Step 3 — Auto-posting. Billing software matches ERA data to open claims using the payer's claim control number (ICN/DCN) or the provider's internal claim number. When a match is found and the payment equals the expected contractual rate, the system auto-posts the payment, writes the contractual adjustment, and moves the patient balance to the patient responsibility column.

Step 4 — Exception handling. Claims that cannot be auto-matched, or where the paid amount deviates from the expected contractual rate, are flagged as exceptions and routed to manual review queues. This step is the primary touchpoint for the accounts receivable management team.

Step 5 — Reconciliation. The total of all ERA payment amounts must reconcile to the corresponding Electronic Funds Transfer (EFT) deposit under CMS's EFT and ERA Enrollment Operating Rules, established under Section 1104 of the Affordable Care Act (ACA) and implemented by the Council for Affordable Quality Healthcare (CAQH) CORE. CAQH CORE Rule 380 requires payers to include a matching trace number in both the ERA (TRN segment) and the EFT (addenda record), enabling one-to-one reconciliation of the 835 file to the bank deposit (CAQH CORE Operating Rules).

Step 6 — Secondary billing or patient statement generation. After posting, the system identifies claims with remaining balances and routes them to secondary payer billing (see coordination of benefits) or to patient billing statements if no secondary coverage exists.

Common scenarios

Scenario 1: Contractual adjustment only (no denial)
The most routine ERA scenario. The payer pays the contracted rate, CARC 45 is applied to the difference between billed and allowed amounts, and no patient balance remains after deductible or copay. Auto-posting rates in well-configured billing environments exceed 85% for this scenario type, per operational benchmarks published by MGMA (Medical Group Management Association).

Scenario 2: Partial denial — medical necessity
A service line is denied with CARC 50 (not medically necessary) and RARC M127. The claim does not auto-post for that line. The denial routes to the medical billing appeals process queue. The adjudicated claim must be matched to the original medical necessity documentation before an appeal letter is generated.

Scenario 3: Bundling adjustment
A payer applies CARC 97 (payment included in allowance for another service), reflecting a bundling edit. This scenario is governed by CCI (Correct Coding Initiative) edits maintained by CMS. The billing team must determine whether an unbundling modifier applies — a process detailed under bundling and unbundling rules.

Scenario 4: Coordination of benefits (COB) secondary ERA
When a secondary payer issues an ERA, the SVC segments reflect the primary payer's payment as a prior payer adjustment (CARC 23). The secondary ERA must be reconciled against the primary ERA to verify correct application of cross-over logic, particularly relevant in medical billing for Medicare dual-eligible populations.

Scenario 5: ERA/EFT mismatch
The total paid across all CLP segments in the 835 file does not match the EFT deposit. This can indicate a split payment arrangement, a voided check, or a transmission error.

ERA vs. paper EOB — key contrast

Decision boundaries

ERA processing intersects with two distinct decision thresholds that determine downstream action.

Threshold 1: Accept vs. dispute the payment
A payment is accepted when the ERA-adjudicated amount matches the contracted fee schedule rate for the payer. Providers should maintain current fee schedule data (fee schedule reference) to automate this comparison. When the paid amount is below the contracted rate without a valid CARC justification, the underpayment qualifies for a medical billing appeals process under contractual dispute provisions — not a clinical appeal. The distinction between a coding denial (clinical/medical necessity) and a contractual underpayment (administrative/contractual) governs which workflow receives the exception.

Threshold 2: Post vs. hold pending correction
Auto-posting logic must be configured to hold claims when:
- The NPI on the ERA does not match any enrolled provider in the system
- The service date falls outside the claim submission window
- CARC 4 (late filing) is present, which may be disputable depending on payer contract terms and state prompt payment statutes
- The claim control number is unmatched (orphan ERA transaction)

Orphan ERA transactions — 835 files containing payments for claims not found in the practice management system — are a recognized reconciliation risk category. They can indicate cross-posting to the wrong provider account, duplicate claim adjudication, or clearinghouse routing errors.

HIPAA compliance layer
All ERA transactions fall under HIPAA's electronic transaction standards. A covered entity that receives an 835 transaction must be able to process it per the applicable implementation guide. Failure to maintain ERA processing capability is a compliance deficiency under 45 CFR Part 162, which CMS enforces. ERA data also contains Protected Health Information (PHI) subject to the HIPAA Privacy Rule (45 CFR Part 164), making access controls and audit logging requirements of HIPAA compliance in medical billing directly applicable to ERA storage and transmission workflows.

References

• [CMS: HIPAA