Convert HIPAA 835 ERA to PDF Remittance Report (Guide & Example)

What Is the HIPAA 835 ERA?

The HIPAA 835 transaction — formally the Health Care Claim Payment/Advice — is the electronic equivalent of a paper Explanation of Benefits (EOB). Payers send 835 files to providers to explain how submitted claims were processed: what was paid, what was adjusted, and why.

A single 835 file typically contains payment information for many claims. The structure follows the X12 5010A1 standard:

ISA*00*          *00*          *ZZ*EMEDNYBAT      *ZZ*ETIN           *...
GS*HP*EMEDNYBAT*ETIN*20100101*...
ST*835*1740
BPR*I*45.75*C*ACH*CCP*01*111*DA*33*1234567890**01*111*DA*22*20100101
TRN*1*10100000000*1000000000
...
CLP*PATIENT ACCOUNT NUMBER*1*34.25*34.25**MC*1000210000000030*11
  NM1*QC*1*SUBMITTED LAST*SUBMITTED FIRST****MI*LL99999L
  SVC*HC:V2020:RB*6*6**1
  SVC*HC:V2700:RB*2.75*2.75**1
  CAS*CO*29*12
CLP*PATIENT ACCOUNT NUMBER*2*34*0**MC*1000220000000020*11
  SVC*HC:V2020*12*0**0
  CAS*CO*29*12
...

The key segments are:

• BPR — Financial information: payment amount, method (ACH, check), bank routing, account numbers
• TRN — Check or EFT trace number for payment reconciliation
• N1/N3/N4 — Payer and payee identification, addresses, contact information
• CLP — Claim-level payment: patient account, claim status, billed amount, paid amount
• SVC — Service line detail: procedure code, billed charge, paid amount
• CAS — Claim Adjustment Reason Codes explaining reductions or denials

Why There Is No Standard 835 PDF Form

Many engineers searching "convert 835 to PDF" expect a standard form, but no such form exists for the 835.

When you convert an 837P to PDF, the output maps directly to the CMS-1500 form — a government-defined, 33-box paper form that every professional claim must follow. The 837I maps to UB-04. The 837D maps to ADA J400.

The 835 has no such equivalent. There is no "CMS Remittance Form" with numbered boxes. Each payer designs its own EOB layout. Each clearinghouse formats remittance reports differently.

This makes 835-to-PDF a design problem, not just a mapping problem. You must decide:

• How to organize payment tracking data (bank routing, EFT trace numbers, payment dates)
• How to display payer and payee information side by side
• How to present claim-level payment alongside service line detail
• How to handle adjustment reason codes — show codes, descriptions, or both?
• How to manage page breaks when a batch 835 contains hundreds of claims

Redix solved this by designing a generic remittance report format — a landscape-oriented, multi-section PDF that maps every 835 data element into a structured, readable layout. This report design originated from real-world remittance workflows and has been used in production by large U.S. healthcare providers for over a decade.

The layout presented here is not theoretical — it is derived from production remittance processing systems and refined through real-world use.

Anatomy of a Remittance Report

The Redix 835 remittance report is a landscape-format PDF. It opens with a one-page payment summary, then breaks the full detail into distinct sections, each mapping to a specific set of 835 loops and segments.

Section 1: Remittance Payment Summary (Cover Page)

The first page is a one-page executive summary of the entire remittance, so a biller or auditor can check the payment total without reading every claim. It presents:

• Deposit callout — the net deposit amount, payment date, check/EFT trace number, and payment method, from the BPR and TRN segments
• Payer and payee — who issued the payment and who received it
• Financial summary — total submitted charges, adjustments grouped by responsibility (CO contractual, PR patient, PI payer-initiated, OA other, CR corrections), net claim payments, provider-level adjustments, and the net payment
• Payment-total balance check — the sum of claim payments, plus or minus provider-level adjustments (PLB), checked against the BPR payment amount, with a clear [ BALANCED ] or [ BALANCE REVIEW ] status
• Balance review flags — a count of any claims whose claim-level math does not tie out, surfacing exceptions on page one instead of burying them in the detail

Section 2: Batched Claims Remittance Summary

The report header on the page where the claim detail begins. Shows the generation date and the title "BATCHED CLAIMS REMITTANCE SUMMARY." Below it, X12 tracking data displays the ISA, GS, and ST control numbers for tracing back to the original electronic transaction.

Section 3: 835 Payment Tracking

A two-column layout showing all financial details from the BPR (Beginning Payment) segment:

• Transaction handling code — Payment accompanies remittance, notification only, or prenotification
• Actual provider payment — The payment amount, formatted as currency
• Payment method — ACH, check, wire transfer, with format codes translated to descriptions
• Banking details — Payor and receiver ABA routing numbers, account numbers
• Check/EFT trace number — From the TRN segment, for reconciliation
• Effective date — When the payment was issued or will post
• Currency and exchange rate — For international transactions

Section 4: Payor and Payee Details

Side-by-side display of the payer (insurance company) and payee (provider). Includes organization name, address, phone, fax, email, and identifier codes (NPI, Payer ID, Tax ID).

Section 5: Transaction-Level Adjustments

Provider-level adjustments from the PLB (Provider Level Balance) segment. These are adjustments not tied to any specific claim — such as interest, late filing penalties, or recoupments from prior periods.

Section 6: Per-Claim Remittance Detail

A new page for each claim payment, containing:

• Claim header — Patient account number, claim status (paid, denied, reversed), filing indicator, facility code
• Patient information — Subscriber and patient names, member ID, statement dates
• Rendering provider — NPI, name, taxonomy code
• Service lines — Each procedure with billed amount, paid amount, allowed amount, and adjustment details
• Adjustment reason codes — CARC and RARC codes with human-readable descriptions
• Claim totals — Total billed, allowed, paid, patient responsibility, and adjustments

Test with a sample 835 file; your own de-identified files need an evaluation key.

Use sample or de-identified files on the online demo. Do not upload production PHI. Licensed deployments run inside your environment.

835 Segments to Report Sections

The following table shows how each major 835 segment maps to a section of the remittance report:

Adjustment Reason Codes and Denials

The 835 uses standardized adjustment codes to explain payment differences. These appear in CAS segments at both the claim level and service line level.

Adjustment Groups

Common Claim Adjustment Reason Codes (CARC)

The remittance report translates CARC codes into human-readable descriptions. For example:

CAS*CO*29*12        →  CO-29: The time limit for filing has expired ($12.00)
CAS*CO*251*2.75     →  CO-251: The attachment/other documentation was not received ($2.75)
CAS*PR*1*50         →  PR-1: Deductible amount ($50.00)
CAS*PR*2*25         →  PR-2: Coinsurance amount ($25.00)

The conversion engine maintains a built-in lookup table that maps standard CARC, RARC, and group codes to their official descriptions, ensuring that the PDF report is immediately readable without cross-referencing code tables. The code descriptions are current as of the July 1, 2026 X12 code list update.

Batch Processing and Index Files

In production, 835 files are rarely single-claim. A typical 835 from a large payer contains payments for dozens or hundreds of claims. The conversion engine handles this by:

1. Parsing the entire ISA/GS/ST envelope — identifying all CLP (claim) loops within the transaction
2. Generating per-claim detail pages — each claim gets its own section with service lines, adjustments, and totals
3. Managing page breaks automatically — when content exceeds the page boundary, the engine creates a new page with continuation headers
4. Creating a companion index file — a pipe-delimited file listing every claim with its page count, patient ID, payer ID, medical record number, and error status

The index file enables programmatic access to the PDF. A billing system can parse the index to find a specific patient's remittance detail, jump to the correct page, or flag claims that had errors:

MCOUNT|CLMSUBID            |CLMPAYID                      |CLMMEDNO|CLMHASERROR|PGCNT|REMITFILE
     1|SUBMITTED LAST      |1000210000000030               |LL99999L|0          |1    |835.pdf
     2|SUBMITTED LAST      |1000220000000020               |LL88888L|1          |1    |835.pdf
     3|SUBMITTED LAST      |1000230000000020               |LL77777L|0          |1    |835.pdf

The same engine and layout handle a small test file or a large production batch. (The online demo accepts small sample files; high-volume batches run in a licensed on-premises or cloud deployment.)

Where the 835 map is installed, the Claims-to-PDF Workbench can run those batches from a desktop: it converts folders of 835 files to remittance-report PDFs locally, keeps each remittance with its original EDI in a searchable archive, and exports audit-support packages. Remittance reports are for review and archiving; they are not printed as claims.

835 vs 837: Payments vs Claims

The 837 and 835 are two sides of the same transaction. Understanding the difference is essential for anyone working with healthcare payment data:

Together, the 837 and 835 form the claims lifecycle: a provider submits an 837 claim, and the payer responds with an 835 explaining the adjudication. Converting both to PDF creates a complete, auditable paper trail from billing through payment.

835 and FHIR: ExplanationOfBenefit

In the FHIR R4 standard, the 835 remittance corresponds to the ExplanationOfBenefit (EOB) resource. While the 837 claim maps to a FHIR Claim resource, the 835 payment response corresponds to an EOB that captures the payer's adjudication decision — what was paid, denied, or adjusted, with coded reasons.

Organizations modernizing for FHIR interoperability often want both directions: 835 → PDF for human review, and 835 → FHIR for API-based workflows. Redix routes X12 through its RMap intermediate format, which is designed to feed both PDF and FHIR outputs. The 835-to-PDF remittance path described here is the established production path; FHIR EOB output is scoped per project against your target FHIR profile.

Use sample or de-identified files on the online demo. Do not upload production PHI. Licensed deployments run inside your environment.

Frequently Asked Questions

Is there a standard PDF form for the 835 like the CMS-1500?

No. Unlike the 837P which maps to the CMS-1500 form, or the 837I which maps to UB-04, there is no government-mandated paper form for the 835 remittance advice. Each organization must design its own remittance report layout. This makes 835-to-PDF a design problem, not just a mapping problem.

What is the difference between an 835 ERA and an EOB?

An EOB (Explanation of Benefits) is a paper document sent to the patient explaining what the insurance paid. An ERA (Electronic Remittance Advice) is the 835 X12 transaction sent electronically to the provider explaining how the payer adjudicated each claim. They contain similar information — payment amounts, adjustments, denial reasons — but the ERA is structured data in X12 format while the EOB is a human-readable document. Converting an 835 ERA to PDF creates a provider-facing remittance report.

How does the 835 remittance report handle denied claims?

Denied claims appear in the CLP segment with a claim status code of "4" (Denied) or "22" (Reversed). The CAS segments provide Claim Adjustment Reason Codes (CARC) explaining why the claim was denied — for example, CO-29 means the time limit for filing has expired. The remittance report translates these codes into human-readable descriptions alongside the raw code values.

Can you convert a batch 835 file with hundreds of claims to PDF?

Yes. A single 835 file often contains payments for hundreds of claims across multiple providers. The conversion engine processes the entire batch, generating a consolidated PDF report with per-claim detail pages, automatic page breaks, and a companion index file listing every claim with its page location, payment status, and file reference.

Does the 835 PDF report show whether the payment balances?

Yes. The remittance report opens with a one-page payment summary that checks the sum of claim payments, plus or minus provider-level adjustments (PLB), against the BPR payment amount, and displays a clear BALANCED or BALANCE REVIEW status. Any claim whose claim-level amounts do not tie out is flagged, so exceptions surface on the first page instead of deep in the claim detail.