Healthcare EDI 835: Understanding Remittance Advice Files

The EDI 835 is the electronic equivalent of an Explanation of Benefits (EOB). When a health insurance payer processes a claim, the 835 transaction is how they communicate the payment decision back to the provider — what was paid, what was adjusted, what was denied, and why. Every provider organization that submits electronic claims receives 835 files, and parsing them correctly is essential for accurate revenue cycle management.

The 835 is formally known as the Health Care Claim Payment/Advice transaction, defined by the ASC X12 standard and mandated by HIPAA for electronic remittance processing. Despite its importance, the 835 file format is notoriously difficult to work with. Its hierarchical loop structure, dense segment encoding, and hundreds of possible adjustment reason codes make it one of the more challenging EDI transactions to implement correctly.

This guide explains what the 835 is, how it fits into the claims lifecycle, how its X12 structure works, and how to build reliable 835 processing workflows.

What Is EDI 835?

EDI 835 (Electronic Data Interchange 835) is an X12 transaction set used by health insurance payers to send payment information to healthcare providers. It tells the provider:

• Which claims were processed
• How much was paid for each claim and each service line
• What adjustments were applied (contractual obligations, patient responsibility, denials)
• What adjustment reason codes explain each adjustment
• How the payment was delivered (check, EFT, virtual card)

The 835 is the response to an 837 claim submission. When a provider submits an 837 (claim), the payer adjudicates it and returns an 835 (remittance advice). This 837-to-835 round-trip is the core of electronic claims processing in US healthcare.

HIPAA Mandate

HIPAA’s Administrative Simplification provisions require all covered entities (health plans, clearinghouses, and providers who conduct electronic transactions) to use the X12 835 for electronic remittance advice. The current mandated version is X12 005010X221A1. Payers cannot use proprietary formats for electronic remittance — they must produce compliant 835 files.

The 835 in the Claims Lifecycle

Understanding where the 835 fits in the overall claims workflow helps contextualize its structure and content.

End-to-End Claims Flow

1. Patient encounter. A patient receives healthcare services from a provider.
2. Charge capture. The provider’s practice management system captures the charges, diagnosis codes (ICD-10), and procedure codes (CPT/HCPCS).
3. 837 claim submission. The provider (or their billing service) generates an EDI 837 transaction and submits it through a clearinghouse to the payer.
4. Claim adjudication. The payer processes the claim against the patient’s benefit plan, applying allowed amounts, deductibles, copays, coinsurance, and contractual adjustments.
5. 835 remittance advice. The payer generates an 835 transaction containing the adjudication results and sends it back through the clearinghouse to the provider.
6. Payment posting. The provider’s billing system parses the 835 and posts the payments, adjustments, and denials to the patient accounts.
7. Denial management. Claims that were denied or underpaid are identified from the 835 data and worked through the appeals process.

The 835 is the critical feedback loop. Without it, providers would not know whether their claims were paid, denied, or adjusted — and they would not know why.

835 File Structure

An 835 file uses the X12 EDI format — a hierarchical, segment-based structure where each segment is identified by a 2-3 character code and fields are separated by delimiters. The structure is organized into envelopes and loops.

Envelope Structure

Every X12 transaction is wrapped in three concentric layers of envelopes. Each layer has its own opening and closing segment.

ISA*00*          *00*          *ZZ*SENDER_ID      *ZZ*RECEIVER_ID    *260327*1200*^*00501*000000001*0*P*:~
GS*HP*SENDER_ID*RECEIVER_ID*20260327*1200*1*X*005010X221A1~
ST*835*0001~

  [Transaction content — claims, payments, adjustments]

SE*45*0001~
GE*1*1~
IEA*1*000000001~

• ISA/IEA (Interchange Envelope): The outermost envelope. ISA identifies the sender, receiver, date/time, and interchange control number. The last characters of the ISA segment define the delimiters — element separator (*), sub-element separator (:), and segment terminator (~).
• GS/GE (Functional Group): Groups related transactions. GS*HP identifies this as a Health Care Claim Payment/Advice functional group.
• ST/SE (Transaction Set): Contains a single 835 transaction. ST*835 identifies this as an 835 transaction set.

Key Segments and Loops

Inside the ST/SE envelope, the 835 organizes payment data into hierarchical loops:

BPR Segment (Beginning of Payment)

The BPR segment identifies the payment method and amount:

BPR*H*1250.00*C*ACH*CCP*01*999999999*DA*123456789*1234567890**01*999888777*DA*987654321*20260327~

Key fields:

• BPR01: Transaction handling code (H = payment with remittance, I = remittance information only, D = payment only). I must be paired with BPR04=NON; H and D are used when a real payment moves.
• BPR02: Total payment amount (1250.00)
• BPR03: Credit/Debit (C = credit)
• BPR04: Payment method (ACH = Automated Clearing House, CHK = check, FWT = Federal Wire Transfer, BOP = financial institution option, NON = non-payment data — required when BPR01=I)

TRN Segment (Reassociation Trace Number)

The TRN links the 835 to a specific payment:

TRN*1*TRACE123456*1234567890~

This trace number is used to match the 835 to the actual bank deposit or check. It is essential for payment reconciliation.

The BPR carries the money instruction and the TRN carries the matching key. Together they let the provider reassociate the remittance advice with the deposit that lands in the bank — the EFT trace number in TRN03 is the same value the originating bank stamps on the ACH transfer.

CLP Loop (Claim-Level Payment)

The CLP loop contains payment information for a single claim. An 835 typically contains multiple CLP loops — one per claim in the payment batch.

CLP*CLM12345*1*500.00*350.00**12*PAYERREF001*11*1~

Key fields:

• CLP01: Patient’s claim number (matches the CLM01 from the original 837)
• CLP02: Claim status code (1 = processed as primary, 2 = processed as secondary, 4 = denied, 22 = reversal)
• CLP03: Total charge amount (500.00)
• CLP04: Total payment amount (350.00)
• CLP05: Patient responsibility amount
• CLP06: Claim filing indicator code (12 = PPO, MC = Medicaid, MA = Medicare Part A)
• CLP07: Payer’s claim control number

CAS Segment (Claim Adjustment)

CAS segments detail the adjustments applied to a claim or service line:

CAS*CO*45*100.00~
CAS*PR*2*50.00~

Each CAS segment has:

• Group code: Why the adjustment was made
  • CO = Contractual Obligation (provider write-off per contract)
  • PR = Patient Responsibility (deductible, copay, coinsurance)
  • OA = Other Adjustment
  • PI = Payer Initiated Reduction
  • CR = Correction/Reversal
• Reason code: A specific CARC (Claim Adjustment Reason Code) explaining the adjustment
• Amount: The dollar amount adjusted

In the example above, CAS*CO*45*100.00 means the payer applied a $100.00 contractual adjustment with reason code 45 (“Charge exceeds fee schedule/maximum allowable or contracted/legislated fee arrangement”). CAS*PR*2*50.00 means the patient owes $50.00 due to reason code 2 (“Coinsurance Amount”).

SVC Loop (Service-Level Payment)

Within each CLP loop, SVC loops break down payment at the individual service line level:

SVC*HC:99213*150.00*120.00**1~
CAS*CO*45*30.00~
DTM*472*20260315~

Key fields:

• SVC01: Procedure code (HC:99213 = HCPCS/CPT code 99213, an office visit)
• SVC02: Line item charge amount (150.00)
• SVC03: Line item payment amount (120.00)
• SVC05: Units of service
• The CAS segment within the SVC loop adjusts this specific service line

Complete 835 Example

Here is a simplified but complete 835 showing the full structure:

ISA*00*          *00*          *ZZ*PAYER_ID       *ZZ*PROVIDER_ID    *260327*1200*^*00501*000000001*0*P*:~
GS*HP*PAYER_ID*PROVIDER_ID*20260327*1200*1*X*005010X221A1~
ST*835*0001~
BPR*H*350.00*C*ACH*CCP*01*999999999*DA*123456789*1234567890**01*999888777*DA*987654321*20260327~
TRN*1*TRACE789*1234567890~
DTM*405*20260327~
N1*PR*ACME HEALTH PLAN~
N1*PE*WEST PALM MEDICAL GROUP*XX*1234567890~
CLP*CLM001*1*500.00*350.00*50.00*12*PCN001*11*1~
CAS*CO*45*100.00~
CAS*PR*2*50.00~
NM1*QC*1*DOE*JOHN****MI*MEMBER001~
SVC*HC:99214*300.00*250.00**1~
CAS*CO*45*50.00~
DTM*472*20260310~
SVC*HC:85025*200.00*150.00**1~
CAS*CO*45*50.00~
DTM*472*20260310~
AMT*AU*350.00~
CLP*CLM002*4*200.00*0**12*PCN002*11*1~
CAS*CO*16*200.00~
NM1*QC*1*SMITH*JANE****MI*MEMBER002~
SVC*HC:99213*200.00*0**1~
CAS*CO*16*200.00~
DTM*472*20260312~
SE*22*0001~
GE*1*1~
IEA*1*000000001~

In this example:

• Claim CLM001 was paid $350.00 on $500.00 in charges. $100.00 was a contractual write-off (CO-45), and $50.00 is patient responsibility (PR-2 coinsurance). The claim had two service lines: an office visit (99214) and a CBC (85025).
• Claim CLM002 was denied. Payment is $0 with the full $200.00 adjusted under CO-16 (“Claim/service lacks information or has submission/billing error”). This claim needs to be corrected and resubmitted.

For every CLP loop, one rule has to hold: the billed charge must fully account for itself. Payment plus every CAS adjustment has to sum back to the original charge, or the claim does not balance.

835 vs Paper EOB

The 835 and the paper Explanation of Benefits (EOB) contain the same information, but in very different formats.

Organizations that still process paper EOBs spend significantly more on payment posting labor and experience higher error rates. Converting to electronic 835 processing is one of the highest-ROI improvements in revenue cycle management.

835 Adjustment Reason Codes

Adjustment reason codes (CARCs and RARCs) are the language of the 835. Understanding the most common codes is essential for denial management and revenue cycle optimization.

Most Common CARCs

Group Codes and Financial Impact

The group code on the CAS segment determines who bears the financial responsibility for the adjustment. Reading it correctly is what separates clean revenue cycle accounting from compliance violations.

• CO (Contractual Obligation): Provider write-off. The provider agreed to this adjustment through their contract with the payer. Do not bill the patient.
• PR (Patient Responsibility): Bill the patient for this amount. Includes deductibles, copays, and coinsurance.
• OA (Other Adjustment): Varies — may be provider liability, patient liability, or informational. Review on a case-by-case basis.
• PI (Payer Initiated Reduction): The payer reduced payment for a reason other than contractual obligation. May be appealable.

Getting group codes wrong has direct financial consequences. Billing a patient for a CO adjustment violates the provider’s contract. Writing off a PR adjustment leaves money on the table.

835 Processing Workflow

A robust 835 processing pipeline involves several steps beyond simple file parsing.

1. File Receipt

835 files arrive from payers through clearinghouses, payer portals, or direct EDI connections. Most providers use a single clearinghouse that aggregates 835s from all their payers into a single delivery channel. Files are typically delivered daily, either pushed to an SFTP server or pulled from a clearinghouse portal.

2. Parsing and Normalization

Parse the X12 835 into a structured data format (database records, JSON objects, or in-memory models). Key parsing considerations:

• Handle multiple claims per 835 file (a single 835 can contain hundreds or thousands of claims).
• Match CAS segments to their parent CLP or SVC loops correctly.
• Parse the BPR segment to extract payment method and amount for bank reconciliation.
• Extract the TRN trace number for payment matching.

3. Claim Matching

Match each CLP loop in the 835 to the corresponding claim in your practice management system. The primary matching key is CLP01 (the patient’s claim number), which should correspond to the CLM01 from the original 837. Secondary matching may use the payer’s claim control number (CLP07), patient name, dates of service, or charge amounts.

Matching failures are common. Payers sometimes modify or truncate the claim number, use their own reference numbers, or return claims under a different patient identifier. Build your matching logic to handle these variations and route unmatched claims to a manual review queue.

4. Payment Posting

For each matched claim, post the payment and adjustment data:

• Apply the payment amount from the CLP loop (or SVC loops for line-level posting).
• Record each CAS adjustment with its group code, reason code, and amount.
• Calculate patient responsibility (sum of PR group adjustments) and update the patient balance.
• Mark fully adjudicated claims as closed. Flag partially paid or denied claims for follow-up.

5. Bank Reconciliation

Match the total payment amount from the BPR segment to the actual bank deposit. The TRN trace number should correspond to the EFT trace number or check number. Reconciling 835 payments against bank deposits catches discrepancies — missing payments, overpayments, and duplicate deposits.

Denial Branch (off-stage-4)

Claims with denial status codes (CLP02 = 4) or zero-payment adjustments feed into the denial management workflow. Categorize denials by reason code to identify patterns — are most denials due to missing authorizations (CARC 197), coding errors (CARC 16), or medical necessity disputes (CARC 50)? Pattern analysis drives process improvements that reduce future denials.

Common 835 Parsing Errors

Several issues frequently cause problems when processing 835 files.

Delimiter misidentification. X12 delimiters are defined in the ISA segment, not fixed. While * (element), : (sub-element), and ~ (segment) are the most common, some payers use different delimiters. Always read delimiters from the ISA segment rather than hardcoding them.

Multi-transaction files. A single 835 file can contain multiple ST/SE transaction sets within a single GS/GE functional group, and multiple functional groups within a single ISA/IEA interchange. Parsers must handle nested envelopes correctly.

Claim-level vs line-level adjustments. CAS segments can appear at both the CLP level (claim-level adjustments) and the SVC level (service-line adjustments). Some payers put all adjustments at the claim level; others put them at the line level. Your parser must handle both patterns and avoid double-counting when adjustments appear at both levels.

Secondary payer complexities. When processing 835s from secondary payers, the adjustment logic changes. The secondary payer’s payment is calculated after the primary payer’s payment, and the CAS segments reflect coordination of benefits adjustments (CARC 22, 23). Posting secondary payments correctly requires understanding the primary payer’s adjudication.

Reversal and correction transactions. Payers sometimes reverse a previous payment (CLP02 = 22) and reissue it with corrections. Reversals produce negative payment amounts that must be applied against the original posting. Failure to process reversals correctly causes account balance errors.

HIPAA EDI Compliance

The 835 transaction is one of the HIPAA-mandated EDI transaction sets. HIPAA’s Administrative Simplification provisions established standard formats for electronic healthcare transactions to reduce administrative costs and improve efficiency.

HIPAA Transaction Sets

All covered entities that conduct these transactions electronically must use the X12 formats. The current mandated version is 005010, with specific implementation guides for each transaction set.

Compliance Requirements

• Standard format. All electronic 835s must conform to X12 005010X221A1.
• Code sets. Adjustment reason codes must use the X12 CARC and RARC code sets maintained by CMS and the Washington Publishing Company.
• Privacy and security. 835 files contain PHI (Protected Health Information) and must be transmitted and stored in compliance with the HIPAA Security Rule. Use encrypted SFTP or AS2 for file transfer. Encrypt 835 files at rest.
• Retention. HIPAA’s six-year documentation requirement under 45 CFR 164.530(j) applies to compliance documentation (policies, BAAs, training records, breach incident records) — not to the 835 files themselves. Retention of the actual remittance files is governed by state law and CMS rules, typically seven to ten years for billing records. Match retention policy to whichever requirement applies longest to your jurisdiction and contracted payers.

Next Steps

The EDI 835 is a complex but essential component of healthcare revenue cycle management. Whether you are building an 835 parser, optimizing your payment posting workflow, or troubleshooting reconciliation issues, understanding the X12 structure and adjustment code system is foundational.

• CMS Interoperability Services — We build payer integration pipelines including 835/837 processing, clearinghouse connectivity, and EDI compliance.
• Healthcare Interoperability Consulting — End-to-end interoperability strategy including EDI, HL7, and FHIR integration.
• Healthcare EDI 837: Claims Submission Guide — Understand the 837 claim submission that triggers the 835 remittance response.