How to Convert EDI 835 & 837 Files to CSV or Excel (Step-by-Step)

A practical guide for billing, finance, and analytics teams that need readable, queryable data from EDI 835 remittances and 837 claim files — without compromising PHI.

Quick Table of Contents

Why convert EDI 835 & 837 to CSV or Excel?

EDI is designed for systems, not humans. A single 835 or 837 file can contain thousands of lines of segments like CLP, CAS, SVC, NM1, and HI. While billing systems use these directly, people usually need a flat, tabular view of the data.

Converting to CSV/Excel lets you:

  • Quickly filter by member, claim, procedure, or payer
  • Summarize payments, adjustments, and patient responsibility
  • Build denial/underpayment reports and dashboards
  • Validate payer behavior and provider contracts
  • Feed data warehouses, BI tools, or Python (pandas) pipelines

Why raw EDI files are hard to work with

A typical EDI file is a long text file with segments separated by ~, data elements separated by *, and important information spread across multiple loops.

Example: a tiny snippet of an 835 ERA

ST*835*0001~
BPR*C*1500.00*C*ACH*CCP************20250131~
TRN*1*1234567890*9876543210~
N1*PR*BIG HEALTH PLAN*PI*12345~
N1*PE*GREAT MEDICAL GROUP*XX*1234567893~
CLP*PCN12345*1*200*150*50*MC*12345~
CAS*PR*1*20.00*1~
SVC*HC:99213*100*80**1~
CAS*CO*45*20.00*1~
SE*10*0001~

Even in this tiny example, payment amounts, adjustments, and service-level details are spread across multiple segments. A converter has to understand the 835 structure to flatten this into a useful table.

Manually copying values from raw EDI into Excel is error-prone and not scalable. A structured converter that knows how to map segments and elements is a better solution.

Step-by-step: converting an EDI 835 ERA to CSV/Excel

1. Prepare a test 835 file

Start with a single sample 835 file from your payer or clearinghouse. If possible, use a de-identified or masked sample for testing.

2. Open the Client-Side 835/837 Converter

Go to the EDI 835/837 Converter page. Supported conversion processing occurs locally in the browser, reducing the need to transmit EDI file contents to the application server.

3. Drag and drop your 835 file

Drag the file onto the drop zone or use the file picker. The converter will parse the file in your browser using JavaScript and detect segment delimiters automatically.

4. Choose the output format

  • Select CSV or Excel (.xlsx) as the output type.
  • For 835 files you can pick Key Fields (simplified layout) or All Fields (full detail).

5. (Optional) Enable de-identification

If you’re using 835 data for training or analytics, follow organizational policy and enable the optional de-identification mode. This masks or removes names, street-level addresses, IDs, and other direct identifiers while preserving financial structure.

6. Download the CSV/Excel file

After conversion completes, click the download button. You’ll get a flat table where each row corresponds to a claim/line combination with columns such as:

  • Claim ID / Patient Control Number
  • Payer, Payee, Member identifiers
  • Service dates, statement dates
  • Charge amount, paid amount, allowed amount
  • Adjustment groups and codes (CO/PR/OA/PI)
  • Patient responsibility
  • Check/EFT trace number and payment date
At this point, you can filter, pivot, and graph your data in Excel, Power BI, or any other downstream tool.

Step-by-step: converting an EDI 837 claim file to CSV/Excel

Converting an 837 claim file is similar, but the structure is focused on billed services instead of payments. The converter flattens 837 loops (subscriber, patient, claim, service line) into rows and columns.

1. Get an 837 sample (837P, 837I, or 837D)

Use a professional (837P), institutional (837I), or dental (837D) file. Make sure you’re using test or de-identified data when experimenting.

2. Load the file into the converter

On the same EDI 835/837 Converter page, drag in your 837 file. The parser will detect that it’s an 837 and route it through the appropriate mapping logic.

3. Choose CSV or Excel output

Select your preferred format. The 837 output is typically “one row per service line,” with claim and member context repeated on each row for easier filtering and aggregation.

4. Use the output in your workflows

  • Analyze billed charges by provider, CPT, revenue code, or diagnosis
  • Compare submitted charges (837) with payments (835)
  • Feed into audit or risk models
  • Build operational dashboards (volumes, coding patterns, etc.)

Key Fields vs All Fields layouts

When working with 835 files specifically, you’ll often have a choice between a Key Fields layout and an All Fields layout.

Option Best for What it includes
Key Fields Everyday analysis, quick exports, Excel users Core identifiers (payer, payee, member, claim ID), key amounts (charge, paid, patient responsibility, allowed), top-level adjustments, and basic dates.
All Fields Data engineering, audit, complex analytics Full detail extracted from the 835, including multiple adjustment slots, supplemental amounts, contact fields, and additional identifiers.

If you’re not sure which to pick, start with Key Fields. You can always re-run the same file with All Fields when you need more detail.

Security & HIPAA considerations when converting EDI

EDI 835 and 837 files almost always contain Protected Health Information (PHI) and other sensitive identifiers. That means:

  • Uploading EDI files to a third-party server can create HIPAA exposure.
  • Storing remits or claims in unsecured cloud tools is risky.
  • Data handling should follow your organization’s privacy and security policies.

Why a client-side converter is different

The Client-Side EDI Converter processes supported EDI file contents locally in the browser. Browser-local parsing and transformation reduce the need to transmit those contents to the application server.

For a deeper discussion of how this works and what it means for PHI, see the Safety & Privacy page.

FAQ: EDI 835/837 to CSV & Excel

Can I just open an EDI file directly in Excel?

You can open it as a text file, but Excel will not understand the X12 structure. Segments and loops will appear as long, messy rows. A converter that understands the 835/837 format is required to create meaningful columns.

Is it safe to use an online EDI converter with real PHI?

It depends on where the conversion happens. If your files are uploaded to a server, you should treat that as a PHI-handling system and require appropriate security controls and agreements. A client-side converter using browser-local processing can reduce the need to transmit the file to the application server and thereby reduce that exposure.

Do I lose information when converting to CSV/Excel?

A properly designed converter preserves all relevant data by mapping segments and elements to columns. For everyday reporting, a Key Fields layout is usually enough. For deep analysis, you can use an All Fields layout to retain more granular details.

Can I automate EDI to CSV conversion?

At small scale, it’s often enough to drag-and-drop files into a browser-based tool and export on demand. At larger scale, many organizations incorporate EDI parsing into ETL pipelines using scripting languages like Python. The flat CSV outputs generated by a converter make that integration much easier.