What Is the EDI 835?
The EDI 835 is the HIPAA-mandated electronic remittance advice (ERA) transaction used by health plans and insurers to communicate claim payment outcomes to healthcare providers. It reports adjudication results for submitted EDI 837 claims, including paid amounts, adjustments, patient responsibility, and payment trace information.
The EDI 835 is the electronic equivalent of an Explanation of Benefits (EOB). It represents the financial settlement stage of the healthcare claim lifecycle. It communicates how an EDI 837 claim was adjudicated — including:
- Amount billed
- Amount allowed
- Amount paid
- Adjustment codes
- Patient responsibility
- Payment method (EFT, check, etc.)
What Is the EDI 835 Used For?
The EDI 835 is used by healthcare payers to transmit electronic remittance advice (ERA) and payment information to providers. It communicates how submitted EDI 837 claims were adjudicated and enables automated payment posting, denial analysis, and financial reconciliation in healthcare revenue cycle systems.
What Does the EDI 835 Do?
The EDI 835 closes the financial loop of the claim lifecycle. It enables payers, insurers, and government agencies to transmit remittance and payment advice to healthcare providers, clinics, physicians, billing services, and managed care organizations by
- Communicating claim-level adjudication results
- Reporting service-line payment outcomes
- Explaining financial adjustments using standardized codes
- Enabling automated payment posting
- Supporting ACH/EFT payment instructions (BPR segment)
What Is an EDI 835 ERA?
An EDI 835 ERA file is the electronic remittance advice sent by a healthcare payer to a provider after a claim is adjudicated. It communicates payment results for an EDI 837 claim, including adjustments, patient responsibility, and payment trace information.
What Is the Difference Between EDI 835 and EOB?
The 835 is the electronic equivalent, a machine-readable version of an Explanation of Benefits (EOB)that replaces paper EOBs with machine-readable data. While an EOB is typically a paper or PDF document sent to patients, the 835 is a structured electronic transaction used by providers and billing systems for automated payment posting and reconciliation.
Who Uses the EDI 835?
The 835 is used by payers, insurers, and government agencies who transmit remittance and payment advice to healthcare providers, clinics, physicians, billing services, and managed care organizations who use it to perform various financial functions as illustrated below:
| Role | Usage |
| Commercial Payers | Send ERA & payment |
| Medicare / Medicaid | HIPAA-mandated remittance |
| Workers’ Compensation Programs | Settlement processing |
| Providers | Auto-post payments |
| Billing Services | Reconciliation & denial analytics |
| Clearinghouses | Routing & validation |
When Is the EDI 835 Required?
The EDI 835 is required when:
- A payer adjudicates a claim electronically
- HIPAA-covered entities exchange remittance advice
- Medicare / Medicaid issue electronic reimbursement
Is the EDI 835 Mandated Under Regulation?
Yes. Under HIPAA Administrative Simplification rules, covered entities must use the ASC X12N 835 (5010) standard for electronic remittance advice which aligns with X12 transaction structure as defined in the official implementation guide.
Why the EDI 835 Matters in Healthcare Revenue Cycle Management?
The EDI 835 is the financial control document of the healthcare reimbursement process. It converts claim adjudication results into structured remittance data that supports automated payment posting, denial analysis, reconciliation, and compliance reporting across healthcare revenue cycle systems.
How Does the EDI 835 Work?
The EDI 835 works by transmitting structured remittance data from a payer to a provider after claim adjudication. It links upstream EDI 837 claims to downstream payment reconciliation by reporting payment totals, adjustment codes, and patient responsibility in a standardized X12 format.
End-to-End Lifecycle Summary
The 835 is the financial control document of the healthcare EDI ecosystem.
- Provider submits EDI 837
- Payer adjudicates claim
- Payer generates EDI 835
- EFT initiated (BPR segment)
- Provider auto-posts payment
- Adjustments reconciled via CAS codes
- Accounts balanced
837 → Adjudication → 835 → Payment → Posting → Reconciliation → Close
Positioning the EDI 835 at the center of lifecycle, upstream transactions become those transactions that occur before the EDI 835 is issued and downstream transactions occur after the EDI 835 is sent.
Below are Upstream and Downstream transaction tables, expanded to fully account for Health Care Claim Payment/Advice workflows.
Upstream Transactions
Transactions that either prepare, submit, or monitor claims prior to financial adjudication and remittance.
| Transaction | Official Name | Mode | Role Relative to EDI 835 |
| 270 | Health Care Eligibility Benefit Inquiry | Inquiry (Request) | Verifies patient eligibility and coverage before claim submission; reduces denials later reflected in the 835 |
| 271 | Health Care Eligibility Benefit Response | Response | Returns benefit and coverage information that influences adjudication outcomes reported in the 835 |
| 837 | Health Care Claim | Submission | Primary upstream transaction; the financial adjudication of this claim is reported in the 835 |
| 276 | Health Care Claim Status Request | Inquiry (Request) | Requests adjudication status prior to remittance issuance |
| 277 | Health Care Claim Status Notification | Response | Communicates interim claim status before final financial outcome is delivered via the 835 |
Downstream Transactions
Positioning the EDI 835 at the center of the lifecycle, downstream transactions become those transactions that confirm receipt, validate structure, manage exceptions, or initiate correction workflows after remittance transmission
| Transaction | Official Name | Mode | Role Relative to EDI 835 |
| 999 | Implementation Acknowledgment | Technical Response | Confirms structural compliance of the received 835 transaction |
| 997 | Functional Acknowledgment | Technical Response | Legacy acknowledgment confirming syntactic receipt of the 835 |
| TA1 | Interchange Acknowledgment | Technical Response | Confirms receipt of the ISA/IEA envelope containing the 835 |
| 824 | Application Advice | Business-Level Response | Reports business-rule validation errors related to remittance processing |
| 837 (Corrected/Resubmission) | Health Care Claim | Submission | Initiated when denial or adjustment information in the 835 requires claim correction or appeal |
Industry-Specific Workflow Variations
| Industry | Variation |
| Medicare | Part A vs Part B filing indicators (CLP06) |
| Medicaid | State companion guide constraints |
| Workers’ Compensation | WC indicator in CLP06 |
| Commercial PPO | Multi-payer coordination |
How does PartnerLinQ use the EDI 835?
PartnerLinQ uses the EDI 835 to enable payers, insurers, and government agencies to transmit remittance and payment advice to healthcare providers, clinics, physicians, billing services, and managed care organizations. The PartnerLinQ EDI 835 integrates directly with downstream accounting, reconciliation, and revenue cycle systems, replacing paper remittances and manual payment notifications. The transaction supports both healthcare and workers’ compensation workflows, including Ohio Bureau of Workers’ Compensation settlement processes. PartnerLinQ:
- Centralizes 835 ingestion across payers
- Validates against v5010 and/or applicable schemas
- Automates automated posting integration
- Surfaces denial analytics through alerting
- Preserves 837 ↔ 835 traceability
- Reduces reconciliation exception volume
Where Is the EDI 835 Used?
The EDI 835 – Health Care Claim Payment/Advice is used anywhere healthcare claims are adjudicated and reimbursed electronically. It operates within the financial settlement layer of the healthcare revenue cycle and is mandated under HIPAA for covered entities transmitting electronic remittance advice.
| Environment | How the 835 Is Used | Why It Matters |
| Commercial Insurance (PPO, HMO, EPO, Indemnity) | Communicates adjudication results, contractual adjustments, and patient responsibility | Enables structured remittance and automated posting |
| Medicare Programs (Part A & B) | Delivers HIPAA-mandated Electronic Remittance Advice (ERA) | Required for compliance and standardized reimbursement |
| Medicaid (State & Managed Care) | Transmits remittance results under federal 5010 standards with state-specific companion rules | Ensures regulatory alignment and payment transparency |
| Workers’ Compensation | Reports injury-related medical payment outcomes | Supports state-regulated settlement workflows |
| Dental Insurance | Communicates ADA-based service adjudication and payment | Enables service-line transparency for dental claims |
| Clearinghouses & EDI Networks | Routes, validates, and normalizes remittance files | Ensures structural compliance and reliable delivery |
| Provider Revenue Cycle Systems | Automates payment posting, reconciliation, denial tracking, and reporting | Reduces manual effort and improves cash visibility |
| Financial Institutions (EFT/ACH Processing) | Correlates payment movement with remittance advice via BPR/TRN segments | Aligns bank settlement with claim-level reconciliation |
Are there Industry-Specific Responses to the EDI 835?
Yes — but not in the form of a direct paired X12 “response transaction.” The EDI 835 is a financial outcome transaction, meaning it represents the payer’s adjudication decision. It does not require a formal business response in the way that an 837 generates a 277 or a 270 generates a 271. Different healthcare sectors trigger industry-specific downstream actions and workflows based on the content of the 835, for example:
| Industry / Environment | Typical Trigger | Industry-Specific Response | Response Type |
| Commercial Health Insurance | Contractual adjustments (CO), patient responsibility (PR), denials (CLP02 = 4), multi-payer forwarding | Secondary claim submission, patient billing, appeal or corrected 837 resubmissions | Operational / Financial |
| Medicare | Coverage limitation denials, DRG adjustments, Part A/B filing indicators | Formal Medicare appeal (Redetermination), cost reporting reconciliation, crossover to supplemental insurer | Regulatory / Financial |
| Medicaid (State Programs) | State-specific policy adjustments, managed care denials | State reconsideration workflow, corrected claim resubmission, managed care escalation | Regulatory / Operational |
| Workers’ Compensation | WC filing indicator (CLP06), injury-related reductions | State bureau dispute filing, medical bill review escalation, settlement reconciliation | Regulatory / Legal |
| Dental Insurance | ADA code reductions, frequency limitations, annual maximum limits | Preauthorization resubmission, alternate benefit billing, patient balance billing | Operational / Financial |
| Clearinghouse / Technical Environment | Structural validation errors, companion guide non-compliance | 999 Implementation Acknowledgment, 997 Functional Acknowledgment, 824 Application Advice | Technical |
| Revenue Cycle Analytics (All Industries) | Recurring CAS denial patterns, underpayment indicators, high adjustment ratios | Denial trend analysis, contract performance auditing, revenue integrity review, payer negotiation | Analytical / Strategic |
What Is the Purpose, Key Features, and Business Use Cases of the EDI 835?
The EDI 835 – Health Care Claim Payment/Advice is the standardized X12 transaction used to communicate claim adjudication results and payment information from a payer to a healthcare provider. It represents the financial settlement layer of the healthcare revenue cycle.
The primary purpose of the EDI 835 is to:
- Communicate how a submitted EDI 837 claim was adjudicated
- Report payment amounts and adjustments
- Allocate patient financial responsibility
- Correlate remittance advice with EFT or check payment
- Provide a structured, auditable Explanation of Benefits (EOB)
Operational Purpose
Provide structured, auditable remittance advice tied to adjudicated claims.
Key Features of the EDI 835
Claim-Level Reporting (CLP Segment)
- Claim status (paid, denied, reversed, forwarded)
- Total charges submitted
- Total amount paid
- Patient responsibility
- Filing indicator (Medicare, Medicaid, Commercial, WC)
Service-Level Detail (SVC Segment)
- Procedure code (CPT/HCPCS/ADA)
- Submitted service charge
- Allowed amount
- Paid amount
- Units of service
Adjustment Explanation (CAS Segment)
- Adjustment group code (e.g., CO, PR)
- Adjustment reason code
- Adjustment amount
Payment & Trace Control (BPR & TRN Segments)
- Payment method (ACH, check, non-payment data)
- Payment effective date
- Trace number for bank reconciliation
Compliance & Standardization
- HIPAA-mandated remittance standard (ASC X12 5010)
- Structured audit trail
- Companion guide alignment
Business Use Cases
The EDI 835 communicates healthcare claim payment outcomes, including amounts paid, adjustments, and patient responsibility. It enables automated posting, denial management, reconciliation, and HIPAA-compliant remittance processing—forming the financial control layer of the healthcare revenue cycle.
The 835 supports multiple operational and financial workflows such as
| Use Case | Description | Business Impact |
| Electronic Remittance Advice (ERA) | Replaces paper Explanation of Benefits (EOB) with standardized, machine-readable remittance data | Faster processing, reduced manual entry, improved transparency |
| Automated Payment Posting | Revenue cycle systems automatically match 835 data to original 837 claims and post payments and adjustments | Lower labor costs, reduced posting errors, accelerated cash application |
| Denial & Adjustment Management | Uses CAS adjustment codes to identify denials, reductions, and patient responsibility allocations | Reduced revenue leakage, improved denial recovery, stronger contract oversight |
| Financial Reconciliation | Aligns BPR payment totals with claim-level remittance data and bank deposits | Improved cash forecasting, faster close cycles, stronger audit controls |
| Coordination of Benefits (COB) | Identifies primary/secondary payer sequencing and supports automated crossover workflows | Faster secondary reimbursement reduced manual follow-up |
| Underpayment Detection | Compares allowed vs paid amounts against payer contracts | Increased revenue recovery, payer performance accountability |
| Revenue Cycle Analytics | Enables trend analysis of adjustments, denial patterns, and payer behavior | Data-driven revenue optimization and contract negotiation leverage |
| Regulatory Compliance & Audit Support | Provides standardized adjudication documentation aligned with HIPAA requirements | Reduced regulatory risk, defensible financial reporting |
Industry Applications
X12The EDI 835 Electronic Remittance Advice (ERA) standardizes healthcare claim payment reporting across commercial insurance, Medicare, Medicaid, workers’ compensation, and dental plans. By normalizing adjudication and adjustment data under the HIPAA 835 format, organizations maintain consistent revenue cycle execution control across multi-payer reimbursement environments.
Operational Visibility
The EDI 835 provides structured visibility into claim payment outcomes, including paid amounts, contractual adjustments, denials, and patient responsibility. Unlike bank deposit summaries, 835 remittance data delivers transaction-level insight. Execution control transforms ERA data into measurable performance indicators across the healthcare revenue cycle.
Compliance Reporting
The HIPAA-mandated EDI 835 ensures standardized electronic remittance advice (ERA) reporting across covered entities. Structured adjustment codes, trace numbers, and claim-level detail create an auditable financial record. Execution governance ensures remittance processing aligns with regulatory requirements and companion guide constraints.
Financial Reconciliation
The EDI 835 acts as the financial control document for healthcare payment reconciliation. It links EFT payment instructions to adjudicated claim totals, enabling automated posting and variance monitoring. Execution-level oversight reduces reconciliation discrepancies and strengthens cash forecasting within the revenue cycle.
Claim Coordination
Within the healthcare reimbursement ecosystem, the EDI 835 connects payers, providers, clearinghouses, and financial institutions through standardized remittance exchange. It links upstream EDI 837 claims to downstream financial reconciliation. Execution control ensures synchronized, traceable settlement workflows across multi-party trading partner networks.
Exception Management
The EDI 835 supports denial management and revenue integrity by exposing structured CAS adjustment and reason codes. These codes trigger appeals, corrected claims, and contract performance analysis. An execution-control model ensures remittance exceptions are monitored, categorized, and resolved systematically to reduce revenue leakage.
What Information Is Required in the EDI 835?
An EDI 835 must include key control and financial segments such as ST, BPR, TRN, CLP, CAS, and SE. These segments identify the transaction, communicate total payment amounts, link remittance advice to bank settlement, and explain claim-level and service-level payment adjustments.
Below is a structured breakdown of required information.
Required Control Segments
These segments ensure structural validity, financial traceability, establish transaction integrity and payment control.
| Segment | Purpose | Why Required |
| ST | Transaction Set Header | Identifies the 835 transaction |
| BPR | Beginning Segment for Payment Order/Remittance Advice | Communicates total payment amount and payment method (EFT, check, non-payment) |
| TRN | Trace | Provides payment trace number for reconciliation |
| *SVC | Service adjudication | Reports service-level adjudication results for individual procedures within a claim |
| *CAS | Adjustment reason | Explains why the paid amount differs from the billed amount |
| SE | Transaction Set Trailer | Validates segment count and closes transaction |
*Compliance requirements – where ‘User Option’ = Must Use
Required Party Identification
The 835 must clearly identify payer and payee. This ensures remittance is correctly attributed to the proper legal and financial entities.
- N1 (PR / PE) - Payer and Payee Identification
- N3 / N4 - Address and geographic information
- REF - Payer identification numbers, tax IDs, NPI (as applicable)
Required Dates
Date fields establish payment timing and reporting alignment.
- BPR16 - Payment effective date
- DTM - Claim statement period or service date
Required Financial Totals
These values ensure payment reconciliation and audit defensibility.
| Element | Description |
| BPR02 | Total payment amount |
| AMT (as applicable) | Allowed amount, coverage amount, net billed amount |
Are there Required Reference Numbers or Optional Segments in the EDI 835?
Yes, essential for reconciliation, references are critical for automated posting.
Required Reference Numbers (Core Identifiers)
These identifiers are essential for reconciliation and audit control, without these references, automated posting and audit defensibility break down.
| Segment | Element | Purpose | Why Required |
| TRN | TRN02 | Payment Trace Number | Links remittance to EFT or check |
| CLP | CLP01 | Claim Submitter’s Identifier | Links 835 to original 837 claim |
| CLP | CLP07 | Payer Claim Control Number | Internal payer tracking reference |
| N1 / REF | Tax ID / NPI / Payer ID | Identifies payer and payee entities | Ensures remittance attribution |
Common Optional (Situational) Segments
“Optional” does not mean unimportant —. These segments are not always present but are widely used depending on payer requirements, many payers treat these as required in practice:
| Segment | Purpose | When Used |
| CUR | Currency | Multi-currency environments |
| DTM (Claim-Level) | Claim statement period dates | Institutional billing |
| NM1 (2100 Loop) | Patient / Insured identification | Detailed claim context |
| REF (Multiple Qualifiers) | Policy numbers, authorization numbers, group IDs | Companion guide driven |
| PER | Contact information | Appeals or payer contact routing |
| AMT | Additional monetary values (allowed amount, net billed) | Enhanced financial reporting |
Claim-Level vs Line-Level Detail (if applicable)
| Level | Segment | Function |
| Claim | CLP | Total submitted / paid / patient responsibility |
| Service | SVC | Per CPT/HCPCS service payment |
| Adjustment | CAS | Reduction explanation |
Required Claim-Level Data (CLP Loop)
Claim-level data forms the financial foundation of reconciliation. Each adjudicated claim must include:
| Element | Description |
| CLP01 | Claim identifier (links to 837) |
| CLP02 | Claim status code (paid, denied, reversed, forwarded) |
| CLP03 | Total claim charge amount |
| CLP04 | Total amount paid |
| CLP05 | Patient responsibility amount (if applicable) |
| CLP06 | Claim filing indicator (e.g., Medicare, Medicaid, Commercial, WC) |
Required Service-Level Detail (SVC Loop)
Service-level reporting supports granular posting and denial management. When service-line reporting is used, the following are required:
| Element | Description |
| SVC01 | Procedure code (HCPCS, CPT, ADA, etc.) |
| SVC02 | Submitted service charge |
| SVC03 | Paid amount per service |
| DTM (472) | Service date |
Summary Table of Key Segments
The EDI 835 – Health Care Claim Payment/Advice is structured to communicate payment, adjudication, and adjustment information at both the claim and service levels. Below is a consolidated summary of the key segments that drive financial control, reconciliation, and denial management.
| Segment | Level | Primary Function | Why It Matters Operationally |
| ST | Transaction | Identifies start of the 835 transaction | Enables structural validation and control |
| BPR | Transaction | Communicates total payment amount and payment method (EFT/check) | Drives financial reconciliation and cash application |
| TRN | Transaction | Provides payment trace number | Links remittance to bank deposit or EFT |
| CUR | Transaction (Optional) | Identifies currency used | Required in multi-currency environments |
| N1 (PR / PE) | Header | Identifies payer and payee | Ensures proper remittance attribution |
| REF | Header / Claim | Provides policy numbers, payer IDs, authorizations | Enables traceability and companion guide compliance |
| LX | Detail | Establishes claim grouping loop | Controls claim-level structure |
| CLP | Claim-Level | Reports total charges, paid amount, patient responsibility, claim status | Forms the financial foundation of posting |
| NM1 | Claim-Level | Identifies patient, insured, or provider | Provides contextual claim identity |
| SVC | Service-Level | Reports procedure-level billed and paid amounts | Enables line-level auto-posting and analytics |
| DTM | Claim / Service | Provides service or statement dates | Aligns financial timing and reporting |
| CAS | Claim / Service | Explains payment reductions using adjustment codes | Drives denial management and reconciliation logic |
| AMT | Claim / Service | Reports additional monetary values (allowed amount, net billed, etc.) | Enhances financial visibility and contract validation |
| SE | Transaction | Closes the transaction and validates segment count | Ensures transaction integrity |
What Status and Reason Codes Are Used with the EDI 835?
The EDI 835 uses standardized status and adjustment codes to explain claim payment outcomes. Claim Status Codes appear in CLP02, Adjustment Group Codes appear in CAS01, Claim Adjustment Reason Codes (CARCs) appear in CAS02, and Remittance Advice Remark Codes (RARCs) appear in the LQ segment.
There are three primary code categories (and one ‘often paired’ ) used within the 835:
- Claim Status Codes (CLP02)
- Claim Adjustment Group Codes (CAS01)
- Claim Adjustment Reason Codes (CAS02 – CARCs)
- (Often paired) Remittance Advice Remark Codes (RARCs)
Status Codes - Claim Status Codes (CLP02)
Claim Status Codes appear in the CLP segment and indicate the overall adjudication outcome of the claim. CLP02 drives downstream workflows such as posting, appeals, or secondary billing.
| Code | Meaning | Operational Interpretation |
| 1 | Processed as Primary | Claim paid as primary insurer |
| 2 | Processed as Secondary | Paid after primary insurer |
| 3 | Processed as Tertiary | Third-level payer |
| 4 | Denied | No payment issued |
| 19 | Processed as Primary, Forwarded | Payment issued; forwarded to another payer |
| 20 | Processed as Secondary, Forwarded | Secondary payment; forwarded onward |
| 22 | Reversal of Previous Payment | Payment recoupment or correction |
| 23 | Not Our Claim, Forwarded | Routed to different payer |
| 25 | Predetermination – No Payment | Informational only |
Reason Codes - Claim Adjustment Group Codes (CAS01)
Adjustment Group Codes categorize financial responsibility. Group codes determine whether balances are written off, appealed, or billed to the patient.
| Code | Meaning | Business Interpretation |
| CO | Contractual Obligation | Contract rate reduction |
| PR | Patient Responsibility | Deductible, copay, coinsurance |
| OA | Other Adjustment | Miscellaneous adjustment |
| PI | Payer Initiated Reduction | Administrative or policy-based reduction |
Reason Codes - Claim Adjustment Reason Codes (CAS02 – CARCs)
CARCs explain the specific reason for the adjustment. These are maintained by industry governance (CMS/X12). CARCs drive denial management, appeal decisions, and revenue analytics.
| CARC | Description | Typical Workflow Trigger |
| 45 | Charge exceeds fee schedule/maximum allowable | Contract validation |
| 97 | Included in payment for another service | Bundling review |
| 96 | Non-covered charge(s) | Patient billing or appeal |
| 109 | Claim not covered by this payer | Payer routing correction |
| 18 | Duplicate claim/service | Billing correction |
| 50 | Medical necessity not met | Clinical documentation appeal |
Industry-Specific Code Sets - Remittance Advice Remark Codes (RARCs)
Operationally powerful, Remittance Advice Remark Codes (RARCs) are not financial amounts but a supplemental narrative that enhances interpretability. RARCS are used to provide an additional explanation for an adjustment. RARCs provide context when the CARC (CAS02) is insufficiently descriptive. RARCs are aligned with a specific message found in the Remittance Advice Remark Code List (e.g., X12 External Code Source 411)
Remittance Advice Remark Codes (RARCs)
Remittance Advice Remark Codes (RARCs) appear in the LQ segment of the EDI 835, with qualifier HE. They supplement Claim Adjustment Reason Codes (CARCs) found in the CAS02 by providing additional explanatory detail at the claim or service level, and do not carry financial amounts.
For more information or a detailed code list see the X12 External Code Source 411.
Sample Remittance Advice Remark Codes (RARCs)
* for illustrative purposes only (Not from a specific payer or CMS publication)
CLP*123456789*1*500*350*50*12*987654321~ CAS*CO*45*100~ CAS*PR*2*50~ SVC*HC:99213*200*150~ DTM*472*20240215~ CAS*CO*45*30~ LQ*HE*N130~ LQ*HE*M15~ |
What This Means:
CLP02 = 1 → Processed as Primary
CASCO45*100 → (CARC 45) $100 contractual reduction
CASPR2*50 → $50 patient deductible
SVC → Service 99213 billed $200, paid $150
CAS (service-level) → $30 reduction
LQHEN130 → Remark: "Consult plan benefit documents…"
LQHEM15 → Remark: "Separately billed services…"
How Status and Reason Codes Work Together?
Status and Reason Codes work together at the claim level (CLP) and service level (SVC), together, they explain the paid amount, in short the Submitted Amount – Adjustments = Paid Amount.
Claim Status (CLP02) - Overall adjudication outcome
Adjustment Category (CAS01) - Financial responsibility bucket
Adjustment Reason (CAS02) - Specific reason for reduction
Adjustment Amount (CAS03) - Dollar amount
Remark Code [RARC] (LQ02) - Additional narrative explanation(s)
What are the Benefits of the EDI 835?
The EDI 835 improves healthcare revenue cycle efficiency by enabling automated payment posting, standardized remittance advice, and structured denial analysis. It replaces paper explanations of benefits (EOB) with machine-readable financial settlement data aligned with HIPAA electronic transaction standards
Operational Benefits
Reduced manual effort and increased transaction-level control.
| Benefit | Description | Business Outcome |
Structured/Standardized Remittance Format | Provides consistent structure across all payers under HIPAA 5010 | Reduced variability in posting workflows |
| Automated Payment Posting - Faster posting cycles | Enables systems to post payments and adjustments directly from the file | Lower labor costs and fewer keying errors |
| Line-Level Visibility | Service-level detail (SVC) supports granular reconciliation | Improved denial analysis accuracy |
| Structured Adjustment Codes | CAS and RARC codes explain payment reductions | Faster exception routing |
| Reduced manual data entry | Accurate, consistent, normalized data | Fewer errors |
Financial Benefits
Improved cash flow stability and revenue integrity.
| Benefit | Description | Business Outcome |
| Accelerated Cash Application | Links remittance to EFT trace numbers (TRN) | Faster revenue recognition Improved cash visibility |
| Improved Reconciliation Accuracy | Aligns total payment (BPR) with claim totals | Reduced reconciliation errors, variance, and write-offs |
| Underpayment Detection | Enables comparison of allowed vs paid amounts | Revenue recovery opportunities |
| Better Forecasting | Structured remittance data improves financial visibility | Predictable settlement cycles, more accurate cash projections |
Denial & Revenue Integrity Benefits
Improved reimbursement performance with fewer revenue leaks
| Benefit | Description | Business Outcome |
| Denial Trend Monitoring | Adjustment reason codes identify recurring patterns | Targeted appeal strategies |
| Contract Compliance Validation | Confirms payer adherence to negotiated rates | Stronger negotiation leverage |
| Patient Responsibility Clarity | Identifies deductible and coinsurance allocations | Accurate patient billing |
Compliance & Audit Benefits
Strengthens governance and reporting integrity.
| Benefit | Description | Business Outcome |
| HIPAA Standardization | Federally mandated electronic remittance format | Aligned data structure that’s regulatory defensibility |
| Traceable Audit Trail | Structured claim and payment identifiers | Simplified audit response with auditable adjustment codes |
| Companion Guide Alignment | Supports payer-specific constraints | Reduced rejection risk |
What are the Benefits of Automating the EDI 835?
Automating the EDI 835 enables direct payment posting, real-time reconciliation, denial routing, and scalable multi-payer processing. By transforming remittance files into system-driven workflows, organizations reduce manual errors, accelerate cash application, strengthen compliance, and improve revenue integrity across the healthcare revenue cycle.
| Automation Benefit | What Automation Does | Operational Impact | Strategic Outcome |
| Faster Cash Application | Automatically posts claim and service-level payments from 835 data | Reduces posting cycle time | Improves cash velocity and reduces Days Sales Outstanding (DSO) |
| Reduced Manual Errors | Eliminates keying of payment and adjustment data | Fewer posting discrepancies | Lower write-offs and rework costs |
| Real-Time Reconciliation Control | Validates BPR totals against posted claim payments and EFT trace numbers | Immediate variance detection | Stronger financial governance and faster close cycles |
| Denial & Underpayment Detection | Routes CAS/CARC-based reductions to structured work queues | Detects systemic underpayment and hastens appeal initiation processing | Reduced revenue leakage and stronger payer accountability |
| Exception-Based Workflow Management | Auto-posts clean claims and isolates only flagged remittances | Lower operational workload | Scalable revenue cycle operations - enables real-time revenue dashboards |
| Scalable Multi-Payer Processing | Normalizes remittance files across commercial, Medicare, Medicaid, and WC payers | Consistent processing rules | Enterprise-level execution consistency |
| Improved Compliance & Audit Traceability | Preserves structured identifiers, timestamps, and adjustment codes | Clear audit trail | Reduced regulatory risk |
| Revenue Cycle Analytics Enablement | Converts 835 data into denial, contract, and cash performance metrics | Real-time KPI visibility | Data-driven contract optimization and forecasting accuracy |
Are there Regulatory and Compliance Requirements for the EDI 835?
Yes, HIPAA Administrative Simplification (1996) mandates national standards for electronic health care transactions, code sets, and identifiers to reduce costs and administrative burdens for providers and health plans. It streamlines billing and communication through standardized electronic data interchange (EDI), reducing paperwork and enabling automated workflows across the healthcare industry
EDI 835 Technical Structure, Format, and Versions
The EDI 835 follows the ANSI ASC X12 transaction standard and is structured using hierarchical loops that organize payment information, claim adjudication details, and service-level adjustments. Core segments include BPR for payment totals, CLP for claim results, and CAS for adjustment explanations.
EDI 835 Segments List
The EDI 835 contains several core segments that communicate payment and adjudication results. Key segments include BPR (payment information), TRN (payment trace), CLP (claim payment information), SVC (service-level detail), CAS (adjustments), and SE (transaction trailer).
Hierarchical Loop Structure
EDI 835 structures that group related information together, organizing payment, claim adjudication, and adjustment data into hierarchical loops that allow automated reconciliation and posting within healthcare revenue cycle systems.
| Loop | Level | Key Segments | Purpose |
| ISA/IEA | Interchange | ISA, IEA | Envelope for EDI transmission |
| GS/GE | Functional Group | GS, GE | Groups healthcare payment transactions |
| ST/SE | Transaction | ST, SE | Defines the start and end of the 835 transaction |
| 1000A | Header | N1, N3, N4 | Identifies the payer |
| 1000B | Header | N1, N3, N4 | Identifies the payee (provider) |
| 2000 | Claim Loop | LX | Groups adjudicated claims |
| 2100 | Claim Detail | CLP, CAS, NM1 | Contains claim-level adjudication data |
| 2110 | Service Detail | SVC, CAS, DTM | Contains procedure-level payment details |
File Format and Delimiters
The EDI 835 follows standard ANSI X12 delimiter conventions and is transmitted within Functional Group HP where typical production delimiters include:
- Segment Separator - hex 15 (NAK) or hex 7E (~)
- Element separator - hex 7C (|) or hex 2A (*)
- Sub-element Separator - hex 3E (>)
Version Differences
There are different version and version differences of the EDI transactions referred to by the HIPAA Administrative Simplification Regulation Text as of the March 2013 publication date. The EDI 835 appears to be stable at v5010 however upstream and downstream transactions may use other versions.
- Companion guides generally override base standard.
| Version | Description | Status |
| 4010 (004010X091A1) | Early HIPAA implementation | Largely deprecated |
| 5010 (005010X221A1) | Current HIPAA-mandated standard | Widely used today |
| 6020+ | Newer X12 releases | Limited healthcare adoption |
What are the Limitations of the EDI 835?
The EDI 835 provides standardized remittance advice but has limitations, including reliance on payer adjudication accuracy, companion guide variability, batch processing cycles, and limited narrative explanation. While it delivers structured payment outcomes, organizations must integrate it with other transactions and workflows to manage reconciliation, appeals, and revenue integrity.
| Limitation | Description | Operational Impact |
| Informational Transaction | Reports adjudication results but does not trigger corrective actions | Requires separate appeal workflows |
| Payer Adjudication Dependency | Reflects payer logic, even when incorrect | Requires custom contract-oriented validation |
| Companion Guide Variability | Payer-specific constraints modify the standard | Increased integration complexity |
| Limited Narrative Detail | Codes provide structured explanation but minimal context | Payment cycle driven – payment monitoring, alerting and a human review process may be required |
| Batch Processing Timing | Often delivered on payer settlement cycles | Delayed financial visibility |
| Limited Claim Context | Focuses on payment results rather than full claim history | Requires cross-transaction correlation - Does not initiate disputes by itself |
| Multi-Payer Variability | Different payer implementation patterns | Higher reconciliation effort |
Version or Companion Guide Constraints
Although the X12 specification defines the base structure, real-world implementations are governed by payer companion guides. Companion guides may define:
- Required reference numbers
- Segment usage constraints
- Adjustment code expectations
- Service-level reporting requirements
- Transmission schedules
Jurisdiction-Specific Requirements
The most effective data carrier structure of an 835 is a combination of:
- X12 standard rules
- HIPAA implementation guides
- Trading partner companion guides
Timing and Frequency Limitations
The EDI 835 – Health Care Claim Payment/Advice is typically generated after a payer completes claim adjudication and prepares payment settlement. While the transaction standard supports structured remittance communication, its timing and frequency are governed primarily by payer processing cycles rather than real-time system events.
Are Implementation Guidelines and Sample Files Available for the EDI 835?
Yes. PartnerLinQ provides sample transactions and implementation guides. EDI 835 implementation guides illustrate both inbound and outbound flows, segment layouts, and valid data examples and support testing and partner onboarding.
Companion Guides
Customized specification documents for use in on boarding and technical development are available through PartnerLinQ Support and Guideline Management.
Trading Partner Requirements
Customized mapping, testing, and validation documentation are also available.
EDI 835 Example File (X12 Sample)
* for illustrative purposes only (Not from a specific payer or CMS publication)
What are the more common EDI errors and rejection scenarios for the EDI 835?
Common EDI 835 errors include structural validation failures, data integrity issues, identifier mismatches, version compliance problems, and trading partner companion guide violations. These errors can trigger 997 or 999 acknowledgments and may prevent automated payment posting or financial reconciliation within healthcare revenue cycle systems. Below is a structured overview of the most common error categories.
| Error Category | Example Error Scenario | Typical Cause | Operational Impact |
| Structural Errors (997 / 999) | Segment count mismatch between ST and SE | Incorrect segment total or missing segments | Transaction rejected before processing |
| Invalid segment order | Segments appear outside defined loop hierarchy | File fails X12 structural validation | |
| Missing required segment (BPR, TRN, CLP) | Required segment omitted | Remittance cannot be interpreted | |
| Data Validation Errors | Invalid or missing claim identifier (CLP01) | Incorrect mapping from adjudication system | Auto-posting failure |
| Invalid adjustment code (CAS02) | Non-standard CARC value used | Denial classification errors | |
| Missing payment amount in BPR02 | Remittance lacks financial totals | Reconciliation cannot occur | |
| Identifier Mismatch Errors | Claim number in 835 does not match original 837 | Incorrect cross-reference mapping | Payment cannot be posted |
| Payer control number mismatch (CLP07) | Internal payer reference mismatch | Manual reconciliation required | |
| NPI or provider ID mismatch | Provider identifiers differ from enrollment records | Posting rejected by billing system | |
| Version Compliance Errors | Incorrect transaction version (e.g., 4010 instead of 5010) | Outdated trading partner configuration | Transaction rejected by validation engine |
| Invalid segment usage for version | Segment used outside permitted loop | Non-compliance with implementation guide | |
| Industry-Specific Rejections | Companion guide violation | Missing payer-required REF qualifier | Trading partner rejection |
| Service-level reporting mismatch | SVC segments missing where required | Remittance incomplete for posting | |
| Adjustment codes inconsistent with payer rules | Payer-specific CARC constraints violated | Claim posting exceptions |
What are the Basic Questions for EDI Integration with the EDI 835?
- Are 835 implementation guides and companion specs available?
- Are sample 835 files available for testing and mapping?
- What is the general direction of the EDI 835 transaction?
- Is the 835 inbound to the client, outbound from the client, or both?
- Are multiple trading partners exchanging 835 files?
- Are there intermediary clearinghouses involved?
- Are there other interested parties beyond payer and provider?
- What additional transactions might these parties exchange?
- Is the EDI 835 a timed event?
- What upstream transaction initiates the 835?
- What downstream workflow depends on the 835?
- Are remittance notifications required?
- Is there an SLA governing 835 delivery timing?
- Is there an SLA governing acknowledgment (999/997) turnaround?
- Are notifications triggered by specific 835 events?
- How are remittance totals monitored?
- Are automatic alerts triggered for reconciliation mismatches?
- Is 835 processing automated or manually reviewed?
- Are 835 files system-triggered upon adjudication completion, or batch scheduled?
- Are remittance updates (reversals, corrections) automatically generated?
- How are adjustments (CAS segments) handled — automated posting or review required?
- How does the client handle CLP02 Claim Status Codes?
- How does the client handle Claim Filing Indicator (CLP06)?
- Are substitute or payer-specific adjustment reason codes permitted?
- Are payer-specific companion guide overrides required?
- Is customization required per payer for adjustment mapping?
- How are denial-related CAS codes routed internally?
- Are underpayments automatically flagged against contract terms?
- How are reversals and recoupments managed?
- Is manual review required for high-risk remittances?
- How is 837 ↔ 835 traceability preserved?
- How long are remittance records retained for audit?
- Is reconciliation tied to EFT trace numbers?
- Is revenue integrity reporting derived directly from 835 data?
What are the Best Practices for using the EDI 835?
Practice | Why It Matters |
Preserve 837 linkage | Ensures traceability |
Automate posting | Reduces cost |
Analyze CAS trends | Identify systemic denials |
Enforce companion guide validation | Reduce rejection |
Archive remittance data | Compliance readiness |
What Transactions are associated with the EDI 835?
| Transaction | Official Name | Role Relative to EDI 835 |
|---|---|---|
| 270 | Health Care Eligibility Benefit Inquiry | Verifies patient eligibility and coverage before claim submission; reduces denials later reflected in the 835. |
| 271 | Health Care Eligibility Benefit Response | Returns benefit and coverage information that influences adjudication outcomes reported in the 835. |
| 837 | Health Care Claim | Primary upstream transaction; the financial adjudication of this claim is reported in the 835. *Also initiated when denial or adjustment information in the 835 requires claim correction or appeal. |
| 276 | Health Care Claim Status Request | Requests adjudication status prior to remittance issuance. |
| 277 | Health Care Claim Status Notification | Communicates interim claim status before final financial outcome is delivered via the 835. |
| 997 | Functional Acknowledgment | Legacy acknowledgment confirming syntactic receipt of the 835. |
| 824 | Application Advice | Reports business-rule validation errors related to remittance processing. |
EDI 835 FAQS
What is the EDI 835 transaction?
The EDI 835 is the electronic remittance advice (ERA) transaction used by healthcare payers to communicate claim payment results to providers. It reports adjudication outcomes for submitted EDI 837 claims, including payment amounts, contractual adjustments, patient responsibility, and payment trace information.
Is the EDI 835 required under HIPAA?
Yes. The EDI 835 is mandated under HIPAA Administrative Simplification rules for electronic remittance advice. Covered healthcare entities must use the ASC X12N 835 transaction standard when transmitting electronic payment and remittance information.
What is the difference between EDI 835 and EOB?
An EDI 835 is the electronic version of an Explanation of Benefits (EOB). While an EOB is typically a paper or PDF document sent to patients, the 835 is a structured electronic transaction used by providers and billing systems for automated payment posting and reconciliation.
What segments are required in the EDI 835?
Key required segments in the EDI 835 include ST (transaction header), BPR (payment information), TRN (payment trace number), CLP (claim payment information), CAS (adjustment codes), and SE (transaction trailer). These segments communicate payment totals, claim adjudication results, and adjustment explanations.
How does the EDI 835 relate to the EDI 837 claim?
The EDI 837 is used to submit healthcare claims from providers to payers. After adjudication, the payer sends an EDI 835 to report the payment outcome of the 837 claim, including amounts paid, adjustments, and patient responsibility.
What are adjustment codes in the EDI 835?
Adjustment codes in the EDI 835 appear in the CAS segment and explain why the paid amount differs from the billed amount. These codes include Claim Adjustment Reason Codes (CARCs), adjustment group codes, and Remittance Advice Remark Codes (RARCs).
Explore Our Integration Solutions
PartnerLinQ Integration Solutions
Connect Everything. Integrate Intelligently.
Future-Proof Your Business with Composable, AI Powered Connectivity.