EDI 835 Remittance Advice: Complete Guide for Healthcare IT

June 11, 2026 · 11 min read

The X12 835 transaction set — the electronic remittance advice (ERA) — is the payer's response to a claim submission. It tells the provider what was paid, what was adjusted, what was denied, and why. For revenue cycle teams, the 835 is the foundation of payment reconciliation. For EDI implementation teams, testing 835 processing is one of the highest-stakes components of any go-live.

This guide covers everything: the 835 structure, the key segments, claim adjustment reason codes (CARCs), remittance advice remark codes (RARCs), reconciliation logic, and how to build a comprehensive 835 test suite before go-live.

What is the X12 835?

The 835 Health Care Claim Payment/Advice is the HIPAA standard electronic remittance advice. Payers send 835 files to providers or their billing systems after adjudicating claims — whether payment is being issued, denied, or pended.

The governing implementation guide is ASC X12 005010X221A1. Every covered entity transmitting remittance data electronically is required to use this format under HIPAA.

Claim Payment Cycle

📤

Provider submits 837

→

⚙️

Payer adjudicates

→

📄

835 ERA generated

→

✅

Payment posted + reconciled

835 Structure: How the File Is Organized

An 835 file is organized around a single payment. At the top, the interchange and group headers identify the payer and the payee (the provider or billing entity receiving the money). Inside that, the file identifies who is being paid and how — check or EFT, amount, date, bank routing details for electronic payment. Nested inside the payment, each adjudicated claim gets its own block: claim status, billed amount, paid amount, and patient responsibility. And nested inside each claim, every individual service line that was billed gets its own repeating block showing what was paid and adjusted for that specific procedure.

That nesting is why 835 reconciliation logic has to work at three levels at once — matching the payment as a whole, then each claim within it, then each service line within each claim — rather than treating the file as a flat list of numbers. A reconciliation engine that only matches at the payment level will miss a single service line that got denied inside an otherwise-paid claim.

Key Segments in the 835

BPR

Financial Information

The payment segment. Contains payment method (check, EFT), payment amount, payment date, and bank account details for EFT.

TRN

Reassociation Trace Number

Links the 835 back to the claim. TRN02 is the check or EFT trace number. Critical for reconciliation.

CLP

Claim Level Data

One CLP per adjudicated claim. Contains claim ID, status code (1=processed, 2=adjusted, 3=denied), billed/paid/patient responsibility amounts.

CAS

Claim Adjustment

Contains adjustment group code (CO, OA, PI, PR) and Claim Adjustment Reason Code (CARC). This is where denials and adjustments are explained.

NM1

Entity Names

Identifies patient, insured, rendering provider, and service facility within the 835.

SVC

Service Payment Information

Service-line level payment data. Contains procedure code, billed amount, paid amount, and revenue code for institutional.

MOA

Medicare Outpatient Adjudication

Medicare-specific segment for outpatient adjudication data. Only present in Medicare 835s.

PLB

Provider Level Adjustment

Adjustments at the provider level rather than claim level — recoupments, prior period adjustments, interest.

Claim Adjustment Reason Codes (CARCs)

CARCs explain why a claim or service line was adjusted. They appear in the CAS segment. Testing your system's handling of common CARCs is essential before go-live.

Contractual Adjustments (CO)

CO-45

Charge exceeds fee schedule

CO-97

Paid by capitation

CO-167

Insufficient/incomplete documentation

Patient Responsibility (PR)

PR-1

Deductible

PR-2

Coinsurance

PR-3

Copay

Other Adjustments (OA)

OA-23

Impact of prior payer(s) adjudication

OA-94

Benefits administered by a separate plan

OA-96

Non-covered charges

Payer Initiated (PI)

PI-6

Claim/service denied. Billed procedure

PI-16

Claim/line was previously paid

PI-22

This care may be covered by another payer

835 Reconciliation Logic

The core reconciliation challenge is matching 835 payments back to the original 837 claims. The TRN segment trace number and CLP01 (claim control number) are the keys. Your reconciliation logic must handle:

Split payments: One 837 claim may be paid across multiple 835 files if the payer splits the payment
Bundled payments: Multiple claims paid in one check/EFT — one BPR, many CLP loops
Reversals: PLB adjustments that recoup previously paid amounts
COB scenarios: 835 from secondary payer references primary payment in CAS*OA*23
Zero-pay ERAs: Denial 835s where CLP04 (paid amount) is 0.00

Testing Your 835 Processing Before Go-Live

A comprehensive 835 test suite must cover at minimum:

Payment Scenarios

✓Full payment

✓Partial payment

✓Zero pay / denial

✓EFT vs check

Adjustment Scenarios

✓Deductible (PR-1)

✓Coinsurance (PR-2)

✓Contractual (CO-45)

✓Write-off required

COB Scenarios

✓Primary 835

✓Secondary 835 with OA-23

✓Medicare as secondary

✓Crossover claims

Synthibase generates 835 remittance advice transactions linked to 837 claims submitted from the same synthetic patient registry. This means your reconciliation testing uses the same member IDs, claim numbers, and provider NPIs as your 837 test — giving you end-to-end cycle validation without PHI.

→

How to Test 835 Remittance Reconciliation Before Go-Live

Step-by-step reconciliation testing guide

Test 835 reconciliation with synthetic linked claims

Generate 837 and 835 pairs from the same synthetic patient registry. No PHI. Ready for go-live testing.

Start free trial →