What Is an EDI 835 File? Complete Guide to Electronic Remittance Advice (ERA)

A clear, accurate guide to EDI 835 remittance files – what they are, how they’re structured, and how to convert them to CSV or Excel for billing and analytics.

Quick Table of Contents

TL;DR – quick definition

An EDI 835 file, also called an Electronic Remittance Advice (ERA), is the HIPAA-standard transaction that payers send to providers to explain how each healthcare claim was paid, adjusted, or denied.

  • Who sends it? Health plans, Medicare, Medicaid, TPAs, clearinghouses.
  • Who receives it? Providers, hospitals, billing companies, revenue cycle teams.
  • What it contains? Payment totals, claim-level and line-level payments, adjustments, and patient responsibility.
  • What it’s used for? Payment posting, reconciliation, denial analysis, and financial reporting.

What is an EDI 835 file?

The ASC X12 835 Health Care Claim Payment/Advice transaction is the standard electronic format that payers use to communicate the results of claim adjudication. After a provider submits a claim in an EDI 837 file, the payer processes it and sends back an 835 that answers:

  • Was the claim paid, partially paid, or denied?
  • How much was paid on each claim and each service line?
  • Which adjustments were applied? (contractual write-offs, non-covered services, etc.)
  • How much is the patient responsible for? (copay, coinsurance, deductible)
  • What payment or EFT does this remit belong to? (check/EFT trace number)

835 = the payer’s “receipt” for your claims

If the 837 is “Here’s what we’re billing you for.”, the 835 is “Here’s what we paid (or didn’t pay), and why.”

Who uses 835 ERA files, and why?

EDI 835 files are used across the revenue cycle:

  • Billing teams use them to post payments and update patient balances.
  • Revenue cycle managers use them to track denials, underpayments, and adjustment trends.
  • Finance and accounting reconcile 835 data with bank deposits and general ledger entries.
  • Data & analytics teams convert 835s into tables to drive dashboards and performance metrics.
  • Clearinghouses and software vendors use them to feed practice management and hospital billing systems.
The challenge: raw 835 files are not easy for humans to read. They’re optimized for systems, not people. That’s why conversion to CSV/Excel is so valuable.

Anatomy of an EDI 835 file

An 835 file is a plain-text document made up of segments separated by a terminator (often ~). Each segment consists of data elements separated by an element separator (often *).

Under the hood, the file is organized into a hierarchy:

  • File-level envelope – ISA, GS
  • Transaction set – ST to SE (each ST/SE pair is an 835 transaction)
  • Payment header – BPR (payment amount/method), TRN (trace number)
  • Payer & payee information – N1, N3, N4, REF, PER
  • Claim-level detail – CLP, related NM1, DTM, REF, AMT
  • Line-level detail – SVC, line-level CAS, DTM, AMT, QTY, LQ
  • Provider-level adjustments – PLB segments

Key 835 segments and what they mean

Segment Purpose Example
ISA Interchange control header – file-level envelope ISA*00*...~
GS Functional group header – groups 835 transactions GS*HP*PAYER*PROVIDER*...~
ST Transaction set header – identifies the transaction as an 835 ST*835*0001~
BPR Payment amount, credit/debit flag, method (check/EFT), and payment date BPR*C*1500.00*C*ACH*CCP************20250131~
TRN Trace number used to match the ERA to a specific EFT or check TRN*1*1234567890*9876543210~
N1 / N3 / N4 Payer and payee identification and address information N1*PR*BIG HEALTH PLAN*PI*12345~
CLP Claim payment information (status, total charge, amount paid, patient responsibility) CLP*PCN12345*1*200*150*50*MC*12345~
CAS Adjustments grouped by category (PR, CO, OA, PI) with reason codes and amounts CAS*PR*1*20.00*1~
SVC Service line with procedure/revenue code, line charge, line paid amount, units SVC*HC:99213*100*80**1~
DTM Dates (service dates, statement dates, received dates, coverage dates) DTM*472*20250110~
PLB Provider-level adjustments like take-backs, interest, or bulk offsets PLB*1234567890*20231231*WO:12345*-25.00~

Reading an 835 at a glance

Begin with BPR and TRN for payment and trace context, confirm payer and payee loops, then follow each CLP claim into its CAS adjustments and SVC service lines. Review PLB separately because provider-level adjustments may affect the payment without belonging to one claim.

This overview explains the major contents. For a field-by-field workflow, reconciliation sequence, and interpretation cautions, use the dedicated How to Read an EDI 835 File guide.

Converting EDI 835 files to CSV or Excel

Raw EDI is efficient for machines, but difficult for humans. Most billing, finance, and analytics workflows benefit from having 835 data in a flat table format that tools like Excel, Power BI, or SQL can easily consume.

Converting 835s to CSV or Excel makes it easy to:

  • Filter by claim ID, member ID, CPT/revenue code, or payer
  • Summarize payments, adjustments, and patient responsibility
  • Build denial and underpayment dashboards
  • Share readable outputs with non-technical teams

Browser-local processing boundary

835 files usually contain Protected Health Information (PHI) and other sensitive identifiers. Uploading them to random websites introduces privacy and compliance risk unless you have a strong security agreement in place.

The Client-Side EDI 835/837 converter handles this differently:

  • Everything runs in your browser. The file is parsed with JavaScript on your machine.
  • Application-server boundary. Supported file contents are processed locally in the browser rather than sent to the application server for conversion.
  • Optional de-identification mode. You can mask PHI while preserving financial accuracy.
  • Flexible output. Export Key Fields or All Fields for 835 files as CSV or Excel.

For the browser-local processing boundary and remaining user responsibilities, see the Safety & Privacy page.

FAQ: common questions about EDI 835 files

Is an EDI 835 the same as an Explanation of Benefits (EOB)?

They contain similar information, but they’re not exactly the same. The 835 is the standardized, machine-readable transaction used between payers and providers. An EOB is a human-readable document for patients or providers that explains how a claim was processed in plain language.

How is an 835 different from an 837?

An 837 is the claim submission transaction – providers send it to request payment. The 835 is the payment and remittance response – payers send it back to explain what was paid or denied. In most workflows, every accepted 837 eventually leads to an 835.

Can I open an 835 file directly in Excel?

You can technically open it as a text file, but it won’t be structured in a useful way. 835 files are hierarchical and delimited; Excel doesn’t know how to interpret the loops and segments. A purpose-built converter is needed to flatten the data correctly into rows and columns.

Is it safe to upload 835 files to online tools?

Because 835s usually contain PHI and financial data, uploading them to third-party servers can create HIPAA and security concerns unless those services are specifically designed, contracted, and audited for that purpose. A client-side converter that keeps files on your device is a safer option.

Can I de-identify 835 files for training or analytics?

Yes. Many organizations remove or mask patient names, IDs, and contact details while keeping claim, line, and payment amounts intact. The Client-Side EDI converter includes an optional de-identification mode so you can generate realistic but privacy-safe training and analytics data from your 835 files.