Understanding the 835 Electronic Remittance Advice (ERA) Form: A Complete Guide

5 min readMar 3, 2025

The 835 Remittance Advice is an electronic document used in the healthcare industry for detailing the payment and adjustment information for submitted medical claims. It is the standard format for electronic remittance advice (ERA) and is used by Medicare, Medicaid, and private insurance companies to inform healthcare providers about claim payments, denials, and adjustments.

The 835 file is transmitted using Electronic Data Interchange (EDI), ensuring seamless communication between healthcare payers and providers.

What is the 835 Electronic Remittance Advice (ERA) Form?

The 835 (Health Care Claim Payment/Advice) is part of the ASC X12N 835 standard, which is a HIPAA-compliant electronic transaction format. It provides healthcare providers with essential payment details, including:

Payment amounts for claims
Adjustments and denials
Deductibles and co-pays
Coordination of benefits (COB) details
Explanations of benefits (EOB)

The 835 file serves as the electronic equivalent of a paper Explanation of Benefits (EOB), making claim reconciliation more efficient.

Breaking Down the 835 Code

835: The ASC X12N standard for electronic remittance advice.
Remittance Advice: Indicates that the document provides payment details and explanations related to medical claims.

This structured format helps healthcare providers and billing systems automate the reconciliation of payments, reducing manual errors and processing time.Key Information Included in the 835 ERA Form

Key Information Included in the 835 Remittance Advice

The 835 transaction contains various details related to claim payments, adjustments, and explanations. Below are the key components:

Payment Information:

Payer name and contact information
Payment amount and date
Payment method (e.g., EFT, check)

Claim-Level Details:

Claim number and patient account number
Paid amount and allowed amount
Claim adjudication status (approved, denied, pending)
Claim adjustments and denial reasons

Service-Line Details:

CPT/HCPCS procedure codes
Service dates
Billed charges vs. paid amount
Adjustment codes and explanations

Patient Responsibility

Deductibles
Co-Payments
Co-Insurance

Adjustment Codes:

Reason Codes (CARC — Claim Adjustment Reason Codes): Explain payment reductions.
Remark Codes (RARC — Remittance Advice Remark Codes): Provide additional details about claim decisions.

Who Uses the 835 ERA Form?

The 835 ERA is widely used by healthcare stakeholders to streamline the payment reconciliation process:

1. Healthcare Providers

Hospitals
Physicians
Clinics
Laboratories

2. Medical Billing Companies

Entities handling claims submission and payment reconciliation.

3. Health Insurance Payers

Medicare, Medicaid, and private insurers use 835 to communicate payment details.

4. Clearinghouses

Third-party intermediaries that process and format ERAs for providers.

Key Components of the 835 ERA Form

The 835 ERA uses a structured loops, segments, and elements format to organize remittance data efficiently.

1. Loops (Grouped Data Sections)

Header Information (Loop 1000A): Identifies the sender (payer) and receiver (provider).
Payment Information (Loop 2000A): Contains details about the payment amount and method.
Claim Information (Loop 2100): Includes claim ID, patient details, and adjudication status.
Service Line Information (Loop 2110): Details each service line paid under a specific claim, including adjustment codes.

2. Segments (Contains Individual Payment Details)

BPR: Payment details (check number, EFT details).
TRN: Trace numbers for reconciliation.
CLP: Claim payment details.
CAS: Adjustments and denial reasons.
NM1: Name and identification of entities (payer, provider, patient).
DTM: Date-related information (payment date, service dates).

3. Elements (Specific Data Fields)

Provider NPI and Tax ID
Claim ID
Payment Amount
Service Codes (CPT, HCPCS)
Denial Codes (CARC, RARC)

This structured format ensures automated processing and reduces manual reconciliation efforts.

Importance of the 835 ERA in Medical Billing

Understanding the 835 ERA format is crucial for medical billing professionals as it automates payment posting and reduces administrative workload.

1. Optimized Payment Reconciliation

Matches payments to claims automatically.
Reduces manual entry errors.
Enhances efficiency in revenue cycle management.

2. Faster Claim Processing

Provides detailed explanations for adjustments and denials.
Helps providers identify trends in claim denials.

3. HIPAA Compliance and Data Security

Ensures secure transmission of payment data.
Reduces compliance risks for providers.

4. Reduced Administrative Costs

Eliminates paper-based remittance processing.
Improves efficiency in account receivables management.

EDI 835 Processing Methodology

This methodology outlines the process of loading, parsing, validating, and persisting an EDI 835 file in PostgreSQL using Python.

Step 1: Load and Read EDI File

Process the 835 ERA file efficiently to handle large datasets.

# Read the EDI 835 file line by line
def load_edi_file(file_path):
    with open(file_path, 'r') as file:
        content = file.read().strip()
    return content.split("~")  # Splitting segments

Step 2: Identify Segments and Map to a Data Structure

Map 835 segments to a structured data model.

def map_segments_to_structure(segments):
    edi_data = {"payments": []}
    payment = {}
    
    for segment in segments:
        elements = segment.split("*")
        if elements[0] == "BPR":
            payment["payment_info"] = {
                "payment_amount": elements[2],
                "payment_method": elements[4]
            }
        elif elements[0] == "TRN":
            payment["transaction_control"] = {
                "check_eft_number": elements[2]
            }
        elif elements[0] == "CLP":
            claim = {
                "claim_id": elements[1],
                "patient_account_number": elements[2],
                "total_charge": elements[3],
                "amount_paid": elements[4]
            }
            payment.setdefault("claims", []).append(claim)
        elif elements[0] == "CAS":
            claim.setdefault("adjustments", []).append({
                "adjustment_reason_code": elements[1],
                "adjustment_amount": elements[2]
            })
        elif elements[0] == "SE":
            edi_data["payments"].append(payment)
            payment = {}
    return edi_data

Step 3: Build a Relational Data Model in PostgreSQL

Create a PostgreSQL schema to support 835 processing.

CREATE TABLE payments (
    id SERIAL PRIMARY KEY,
    payment_amount NUMERIC,
    payment_method VARCHAR(50),
    check_eft_number VARCHAR(50)
);

CREATE TABLE claims (
    id SERIAL PRIMARY KEY,
    claim_id VARCHAR(50) UNIQUE,
    patient_account_number VARCHAR(50),
    total_charge NUMERIC,
    amount_paid NUMERIC,
    payment_id INT REFERENCES payments(id)
);
CREATE TABLE claim_adjustments (
    id SERIAL PRIMARY KEY,
    claim_id INT REFERENCES claims(id),
    adjustment_reason_code VARCHAR(10),
    adjustment_amount NUMERIC
);

Step 4: Persisting Data in PostgreSQL

import psycopg2

def insert_835_into_db(parsed_data):
    conn = psycopg2.connect(dbname="edi_db", user="postgres", password="password", host="localhost")
    cur = conn.cursor()
    
    for payment in parsed_data["payments"]:
        cur.execute("INSERT INTO payments (amount, payment_date) VALUES (%s, %s) RETURNING id;",
                    (payment["payment_info"]["amount"], payment["payment_info"]["date"]))
        payment_id = cur.fetchone()[0]
        for claim in payment["claims"]:
            cur.execute("INSERT INTO claims (claim_id, total_charge, paid_amount, payment_id) VALUES (%s, %s, %s, %s);",
                        (claim["claim_id"], claim["total_charge"], claim["paid_amount"], payment_id))
    conn.commit()
    cur.close()
    conn.close()

How Are 835 and 837 Transactions Related?

The 837 (Healthcare Claim Submission) and 835 (Healthcare Claim Payment/Remittance Advice) transactions are closely linked within the medical billing and reimbursement cycle. These two HIPAA-compliant EDI (Electronic Data Interchange) transactions play a crucial role in processing healthcare claims and payments.

Understanding the Relationship Between 837 and 835 Transactions

837 Submission → 835 Response

A healthcare provider (doctor, hospital, clinic) submits an 837 claim to an insurance payer (Medicare, Medicaid, or private insurance).
The payer processes the claim and determines payment, adjustments, or denials.
The payer then generates an 835 remittance advice, detailing payments, adjustments, and denials.

One-to-Many or Many-to-One Mapping

One 837 can result in multiple 835 transactions: A single claim may be partially paid, adjusted, or split across multiple payments. Example: A hospital bill with multiple procedures may receive payments from primary, secondary, and tertiary insurance payers, generating multiple 835 responses.
One 835 can cover multiple 837 transactions:A payer may process multiple claims in a batch, issuing a single 835 file with payment details for several claims.

3. Reconciliation Challenges

Since 835 and 837 do not have a one-to-one match, reconciliation requires tracking Claim IDs (CLP segment in 835) and Claim Control Numbers (CLM segment in 837).
Providers must link submitted claims (837) with received payments (835) to detect Underpayments, Overpayments, Denials and reasons for non-payment.

Why the 837 and 835 Relationship Matters

Revenue Cycle Management: Ensures accurate payments and reduces denials.
Denial Management: Helps track and appeal claim denials.
Payment Reconciliation: Links services billed vs. payments received.

Conclusion

The 837 claim file initiates the billing process, while the 835 remittance file provides the payment outcome. Successful reconciliation between these files ensures proper financial tracking, reduces revenue loss, and improves billing efficiency for healthcare providers.