Every insurance claim and payment in US healthcare travels as X12 EDI. The 837 transaction carries claims from providers to payers, and the 835 returns payment and adjustment details. Developers building billing software, revenue cycle tools or clearinghouse integrations must understand both, because small structural errors cause rejected claims, unposted payments and cash flow problems. This guide explains the 837 and 835 in practical terms, how they connect and how to implement them reliably. It supports our revenue cycle analytics platform work. Building claims workflows? Request a free EDI architecture review.
X12 Basics for Healthcare Developers
X12 is a standard for electronic data interchange. HIPAA requires specific X12 transactions for administrative healthcare data, currently based on version 5010. Before working with claims or remittances, developers need to understand how X12 files are structured and validated.
Envelopes and structure
X12 files use nested envelopes. The ISA and IEA segments wrap the interchange, GS and GE wrap functional groups, and ST and SE wrap each transaction set. Control numbers in each envelope must match, or receivers reject the file before reading its content.
Segments, elements and delimiters
Each line is a segment made of elements separated by delimiters, with segment terminators ending each line. Delimiters are defined in the ISA segment. Parsers must read delimiters dynamically, because partners may use different characters, and hard-coded assumptions cause failures.
Loops and hierarchy
Transactions organize segments into loops, which group related information such as billing provider, subscriber and claim details. Hierarchical level segments link these loops. Understanding loop structure is essential, because the same segment means different things in different loops. Document every rule clearly.
Implementation guides
HIPAA transactions follow detailed implementation guides, often called TR3s, defining required segments, codes and situational rules. Payers may publish companion guides with additional requirements. Developers should treat implementation and companion guides as the true specification for each transaction. Test these cases with partners.
The 837 Claim Transaction
The 837 carries claims from providers to payers, either directly or through clearinghouses. There are three variants for different claim types. Getting the 837 right determines whether claims are accepted, adjudicated quickly and paid correctly.
837P, 837I and 837D
The 837P carries professional claims, such as physician services. The 837I carries institutional claims from hospitals and facilities. The 837D carries dental claims. Each variant has different required data, so software must generate the correct type for each claim. Small errors here cause costly rejections.
Key claim loops and segments
Important parts include billing provider and subscriber loops, the claim loop with the CLM segment, diagnosis codes in the HI segment, and service lines with procedure codes and charges. Accurate provider identifiers and patient details are essential for payer matching.
Acknowledgments after submission
After submission, receivers return acknowledgments. The 999 confirms whether the file was syntactically valid, and the 277CA reports whether individual claims were accepted or rejected at the front end. Track both, because rejected claims never reach adjudication. Validate this carefully before go-live.
Common rejection causes
Claims are often rejected for invalid identifiers, mismatched subscriber information, missing diagnosis codes, invalid procedure codes or payer-specific rules. Validate claims before submission using implementation guide and companion guide rules, catching errors while they are still easy to fix. Billing teams rely on this accuracy daily.
The 835 Remittance Transaction
The 835, also called the Electronic Remittance Advice or ERA, tells providers what payers paid, adjusted or denied for each claim. Accurate 835 processing drives payment posting, denial management and financial reporting across the revenue cycle.
Payment and trace information
The BPR segment describes the payment, including amount and method, while the TRN segment carries a trace number. Organizations use the trace number to match ERAs with electronic funds transfers deposited in bank accounts, a process called reassociation. Monitor results continuously after launch.
Claim-level details
The CLP segment reports each claim’s status, charges and payment amount, linking back to the original claim through identifiers. Accurate matching to submitted claims is essential, because unmatched payments require manual research and delay financial reconciliation. Partner companion guides often add stricter requirements here.
Adjustments and reason codes
CAS segments explain adjustments using Claim Adjustment Reason Codes and group codes, while Remittance Advice Remark Codes add detail. These codes reveal why payments differ from charges. Analyzing them is the foundation of denial management and payer performance analysis. Clear documentation helps new team members ramp up faster.
Provider-level adjustments
The PLB segment captures adjustments not tied to specific claims, such as interest, recoupments or overpayment recoveries. These can confuse posting if ignored. Handle provider-level adjustments explicitly so account balances and financial reports remain accurate. Automated checks catch most problems before submission.
How 837 and 835 Work Together
Claims and remittances form a loop: claims go out, payments and explanations come back. Connecting them accurately allows organizations to track every claim from submission to payment, identify problems quickly and improve future claims based on payer feedback.
Matching claims to payments
Use claim identifiers sent in the 837 to match 835 claim payments. Consistent identifier formats are essential. Matching enables automatic payment posting and shows which claims remain unpaid, guiding follow-up work for billing teams. Review these rules whenever payers publish updated companion guides.
Tracking claim status
Between submission and payment, claim status inquiries using 276 and 277 transactions show where claims stand. Combining acknowledgments, status responses and remittances creates a complete view of each claim’s lifecycle, supporting proactive follow-up instead of reactive firefighting. Consistent handling here keeps financial reports accurate and trustworthy.
Learning from denials
Denial codes in 835 files reveal patterns, such as missing authorizations or coding issues. Feeding these patterns back into claim validation reduces future denials. Our denial trend analytics platform work turns remittance data into prevention. Staff time saved here compounds quickly across thousands of claims each month.
Reconciling with deposits
Reassociating ERAs with bank deposits confirms that reported payments were actually received. Gaps reveal missing ERAs or deposits. Automated reconciliation saves finance teams significant time and improves confidence in reported revenue figures. Reconciliation becomes much easier when this data is accurate.
Implementing 837 and 835 Reliably
Building EDI capabilities requires careful parsing, validation, partner testing and monitoring. The steps below reflect how we deliver claims and remittance integrations for billing platforms, health systems and digital health companies.
Step 1: Gather guides and requirements
Collect implementation guides, payer companion guides and clearinghouse specifications. Identify required variants, payers and edge cases. A clear requirements set prevents rework when partners reject files for rules that were documented but overlooked. Dashboards make these issues visible to billing leaders quickly.
Step 2: Build parsing and generation
Use proven EDI libraries or clearinghouse APIs where possible, rather than writing parsers from scratch. Handle delimiters, loops and situational segments correctly. Clearinghouses offering JSON interfaces can simplify development significantly for many teams. Strong validation reduces rework for billing staff significantly.
Step 3: Validate before sending
Implement validation for structure, required fields, code sets and payer rules before submission. Early validation reduces rejections and accelerates payment. Track validation failures to identify recurring data quality problems upstream in clinical or registration workflows. Plan for edge cases early.
Step 4: Test with partners
Test with clearinghouses and payers using realistic claims, including edge cases such as secondary claims and corrections. Review acknowledgments carefully. Partner testing reveals companion guide requirements and formatting expectations that general testing cannot uncover. Each payer may interpret rules slightly differently, so confirm expectations during testing.
Step 5: Monitor and reconcile
Monitor acknowledgments, rejections, payment timing and unmatched remittances continuously. Reconcile ERAs with deposits. Dashboards help billing teams prioritize work and help leaders understand cash flow and payer performance trends over time. Engagements scale with your roadmap, from a single payer connection to enterprise-wide revenue cycle automation across many entities.
How Taction Helps With Healthcare EDI
Taction has delivered 200+ healthcare projects, including billing platforms, clearinghouse integrations and revenue cycle analytics. We help organizations build reliable 837 and 835 workflows that reduce rejections, speed payments and turn remittance data into insight.
Free EDI architecture review
Share your claims volumes, payers and current systems. We review your EDI approach, clearinghouse options and validation strategy, then recommend improvements. You get a clear, actionable plan. Request your free review. Every integration includes monitoring and clear documentation for billing and IT teams.
Claims and remittance integration
We build 837 generation, acknowledgment handling, 835 posting and reconciliation workflows through clearinghouses or direct connections. Our claims processing automation solutions streamline the full lifecycle. Assign clear ownership for follow-up. We also flag quick wins that can reduce rejections immediately.
Revenue cycle analytics
We turn claims and remittance data into dashboards covering denial trends, payer performance and cash flow. Analytics help leaders target improvements that recover revenue and reduce administrative effort across billing teams. Track trends over time. Log every failure for review.
Billing developers on demand
Need extra expertise? Hire claims processing developers experienced with X12, clearinghouses and payer requirements. They join your team quickly and document integrations thoroughly for long-term support. Engagements scale with your roadmap, from a single payer connection to enterprise revenue cycle automation, with documentation included.
Frequently Asked Questions
These answers address common questions about X12 837 and 835 transactions. Because payer companion guides and requirements vary, confirm details with each payer and clearinghouse when building integrations.
What is an 837 transaction?
The 837 is the X12 transaction used to submit healthcare claims electronically. Variants include 837P for professional claims, 837I for institutional claims and 837D for dental claims. HIPAA requires these standard formats for electronic claims. Revenue depends on getting this right.
What is an 835 transaction?
The 835, or Electronic Remittance Advice, reports payments, adjustments and denials for submitted claims. It includes payment information, claim-level details and adjustment reason codes that explain differences between billed charges and paid amounts. Root causes matter more than individual fixes.
What is the difference between a 999 and a 277CA?
A 999 confirms whether an X12 file was syntactically valid. A 277CA reports whether individual claims were accepted or rejected at the front end. Both are needed to understand whether claims entered adjudication successfully. We document everything for long-term support.
What are CARC and RARC codes?
Claim Adjustment Reason Codes explain why payments differ from charges, while Remittance Advice Remark Codes provide additional detail. Both appear in 835 files and are essential for denial management and payment posting. Errors here delay payment. Faster payments follow cleaner claims.
Should we build EDI parsing ourselves?
Usually not. Proven EDI libraries and clearinghouse APIs reduce effort and risk. Some clearinghouses offer JSON interfaces that hide X12 complexity. Build in-house only when you have strong reasons and deep EDI expertise. Payers publish companion guides for this. Our team handles these details daily.