Healthcare EDI 837: Claims Submission Guide

The EDI 837 is the standard electronic format for submitting healthcare claims from providers to payers. Every time a physician’s office bills an insurance company for a patient visit, a hospital submits a facility claim for an inpatient stay, or a dentist files for a procedure — an 837 transaction carries that claim data. It is the starting point of the healthcare revenue cycle’s electronic backbone, and getting it right determines how quickly and accurately providers get paid.

The 837 is formally known as the Health Care Claim transaction, defined by the ASC X12 standard and mandated by HIPAA for electronic claims submission. There are three variants — 837P (Professional), 837I (Institutional), and 837D (Dental) — each designed for a different provider type and claim format. This guide covers the 837’s structure, submission workflow, common rejection codes, and how the 837 connects to the 835 remittance response.

What Is EDI 837?

EDI 837 (Electronic Data Interchange 837) is an X12 transaction set that providers use to submit claims to health insurance payers. It contains all the information a payer needs to adjudicate the claim:

Patient demographics and insurance information
Provider identification (NPI, Tax ID)
Diagnosis codes (ICD-10-CM/PCS)
Procedure codes (CPT, HCPCS, CDT)
Dates of service
Charges and units
Place of service
Referring and rendering provider information
Prior authorization numbers (when applicable)

The 837 replaces the paper CMS-1500 form (for professional claims) and UB-04 form (for institutional claims). Every data element on those paper forms has a corresponding location in the 837 transaction.

HIPAA Mandate

HIPAA requires all covered entities that submit claims electronically to use the X12 837 format. The current mandated version is 005010, with specific implementation guides:

837P: 005010X222A1 (Professional)
837I: 005010X223A2 (Institutional)
837D: 005010X224A2 (Dental)

Providers cannot use proprietary claim formats for electronic submission. Payers must accept and process compliant 837 transactions.

837P vs 837I vs 837D

The three 837 variants serve different segments of the healthcare industry. Understanding which to use is the first step in claims submission.

Each 837 variant maps to a paper claim form and a specific HIPAA-mandated implementation guide.

837P (Professional)

The 837P is used by physicians, outpatient facilities, ambulatory surgery centers, and other professional providers. It maps to the paper CMS-1500 claim form and covers:

Office visits
Outpatient procedures
Laboratory services (when billed by the ordering provider)
Durable medical equipment
Home health services
Ambulance services

The 837P is the most commonly used variant. Most provider billing systems generate 837P transactions by default.

837I (Institutional)

The 837I is used by hospitals, skilled nursing facilities, home health agencies, and other institutional providers. It maps to the paper UB-04 (CMS-1450) claim form and covers:

Inpatient stays
Outpatient hospital services
Emergency department visits
Rehabilitation facilities
Psychiatric facilities
Hospice services

The 837I includes elements specific to institutional billing that do not exist in the 837P: revenue codes, occurrence codes, condition codes, value codes, and the Diagnosis Related Group (DRG) for inpatient claims.

837D (Dental)

The 837D is used by dental providers. It maps to the ADA Dental Claim Form and includes dental-specific elements like tooth numbers, tooth surfaces, oral cavity areas, and CDT (Current Dental Terminology) procedure codes.

Key Differences

Aspect	837P (Professional)	837I (Institutional)	837D (Dental)
Paper form	CMS-1500	UB-04 (CMS-1450)	ADA Dental Form
Provider types	Physicians, outpatient	Hospitals, SNF, HHA	Dentists
Procedure codes	CPT, HCPCS	CPT, HCPCS + Revenue Codes	CDT
Diagnosis codes	ICD-10-CM	ICD-10-CM, ICD-10-PCS	ICD-10-CM
Place of service	POS codes (2-digit)	Type of bill (4-digit)	POS codes
Revenue codes	Not used	Required per line	Not used
DRG	Not used	Required for inpatient	Not used
Implementation guide	005010X222A1	005010X223A2	005010X224A2

837 File Structure

Like all X12 transactions, the 837 uses a hierarchical segment-based structure with envelopes, loops, and segments.

The 837 nests outward-in: the ISA interchange wraps the GS group, the ST transaction set, the 1000/2000 entity loops, and finally the 2300 claim and 2400 service lines. Each layer opens and closes with a matched segment pair.

Envelope Structure

The 837 uses the same three-layer envelope as other X12 transactions:

ISA*00*          *00*          *ZZ*PROVIDER_ID    *ZZ*PAYER_ID       *260327*1200*^*00501*000000001*0*P*:~
GS*HC*PROVIDER_ID*PAYER_ID*20260327*1200*1*X*005010X222A1~
ST*837*0001*005010X222A1~

  [Transaction content — claims, subscribers, service lines]

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

ISA/IEA: Interchange envelope with sender/receiver identification and delimiters.
GS/GE: Functional group. GS*HC identifies this as a Health Care Claim functional group. The version identifier (005010X222A1) specifies which 837 variant.
ST/SE: Transaction set containing one batch of claims.

Hierarchical Levels (HL Loops)

The 837 uses Hierarchical Level (HL) segments to establish parent-child relationships between billing providers, subscribers (insurance holders), and patients.

The HL chain descends information-source → subscriber → patient. The patient level is conditional — it only appears when the patient is a dependent who differs from the subscriber.

HL*1**20*1~        [Billing Provider]
HL*2*1*22*1~       [Subscriber (patient = subscriber)]
HL*3*2*23*0~       [Patient (dependent, if different from subscriber)]

HL*1 (Level 20 — Information Source): The billing provider or billing service.
HL*2 (Level 22 — Subscriber): The insurance subscriber. If the patient is the subscriber, the claim data is attached here.
HL*3 (Level 23 — Patient): Used only when the patient is a dependent (child, spouse) and different from the subscriber.

CLM Loop (Claim Information)

The CLM segment is the heart of the 837. It identifies a single claim:

Reading the CLM segment left to right: asterisks delimit elements, empty positions (CLM03/04) collapse to consecutive asterisks, and CLM05 packs place of service, facility code qualifier, and claim frequency type into one colon-separated composite.

CLM*CLAIM001*350.00***11:B:1*Y*A*Y*Y~

Key fields:

CLM01: Patient account/claim number (CLAIM001). This is your internal reference and will be returned in the 835’s CLP01.
CLM02: Total claim charge amount (350.00)
CLM05: Place of service, facility code qualifier, and claim frequency. 11:B:1 means place of service 11 (office), facility code qualifier B, and claim frequency 1 (original claim).

DTP Segments (Date/Time)

DTP segments carry dates throughout the 837:

DTP*472*D8*20260315~            [Service date - single (837P service line)]
DTP*434*RD8*20260310-20260315~  [Statement date range (837I claim-level)]
DTP*454*D8*20260301~            [Initial treatment date]
DTP*431*D8*20260301~            [Onset of current illness/symptom]

DTP01: Date/time qualifier. Key values: 472 = Service Date (837P service-line), 434 = Statement Date range (837I claim-level), 454 = Initial Treatment Date, 431 = Onset of Current Illness or Symptom.
DTP02: Format (D8 = single date CCYYMMDD, RD8 = date range)
DTP03: Date value

SBR Loop (Subscriber Information)

The SBR segment identifies the patient’s insurance coverage:

SBR*P*18*GROUP123******CI~

SBR01: Payer responsibility (P = primary, S = secondary, T = tertiary)
SBR02: Individual relationship code (18 = self, 01 = spouse, 19 = child)
SBR03: Group or policy number
SBR09: Claim filing indicator code (CI = commercial insurance, MA = Medicare Part A, MB = Medicare Part B, MC = Medicaid)

NM1 Segments (Name/Identification)

NM1 segments identify the various entities involved in the claim:

NM1*85*1*SMITH*JAMES*A***XX*1234567890~    [Billing Provider]
NM1*87*2*WEST PALM MEDICAL GROUP*****XX*9876543210~  [Pay-To Provider]
NM1*IL*1*DOE*JOHN****MI*MEMBER001~         [Subscriber]
NM1*82*1*JONES*SARAH*B***XX*5678901234~    [Rendering Provider]
NM1*DN*1*WILLIAMS*ROBERT*C***XX*4567890123~  [Referring Provider]

NM1*85: Billing provider (who is billing)
NM1*87: Pay-to provider (who receives payment, if different)
NM1*IL: Insured/subscriber
NM1*82: Rendering provider (who performed the service)
NM1*DN: Referring provider

SV1/SV2 Loops (Service Line)

Service lines detail individual procedures within a claim. The 837P uses SV1 segments; the 837I uses SV2 segments.

837P Service Line (SV1):

SV1*HC:99214*150.00*UN*1*11**1:2~
SV1*HC:85025*75.00*UN*1*11**3~

SV101: Procedure code (HC:99214 = CPT 99214, office visit level 4)
SV102: Line item charge amount
SV103: Unit of measurement (UN = unit)
SV104: Quantity/units of service
SV105: Place of service code
SV107: Diagnosis code pointer (references the DX codes in the HI segment)

837I Service Line (SV2):

SV2*0250*HC:85025*75.00*UN*1~

SV201: Revenue code (0250 = pharmacy)
SV202: Procedure code
SV203: Line item charge amount

HI Segment (Diagnosis Codes)

The HI segment carries diagnosis codes for the claim:

HI*ABK:J06.9*ABF:R50.9~

ABK: ICD-10-CM principal diagnosis (J06.9 = acute upper respiratory infection)
ABF: ICD-10-CM additional diagnosis (R50.9 = fever, unspecified)

Complete 837P Example

Here is a simplified but complete 837P for a single professional claim:

ISA*00*          *00*          *ZZ*PROVIDER_ID    *ZZ*CLEARINGHOUSE  *260327*1200*^*00501*000000001*0*P*:~
GS*HC*PROVIDER_ID*CLEARINGHOUSE*20260327*1200*1*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*BATCH001*20260327*1200*CH~
NM1*41*2*WEST PALM MEDICAL GROUP*****46*123456789~
PER*IC*BILLING DEPT*TE*5615551234~
NM1*40*2*ACME CLEARINGHOUSE*****46*987654321~
HL*1**20*1~
NM1*85*2*WEST PALM MEDICAL GROUP*****XX*1234567890~
N3*100 MEDICAL DR~
N4*WEST PALM BEACH*FL*334010000~
REF*EI*123456789~
HL*2*1*22*0~
SBR*P*18*GROUP123******CI~
NM1*IL*1*DOE*JOHN*A***MI*MEMBER001~
N3*123 MAIN ST~
N4*WEST PALM BEACH*FL*334010000~
DMG*D8*19800115*M~
NM1*PR*2*ACME HEALTH PLAN*****PI*PAYER001~
CLM*CLM001*225.00***11:B:1*Y*A*Y*Y~
HI*ABK:J06.9~
NM1*82*1*SMITH*JAMES*A***XX*1234567890~
SV1*HC:99214*150.00*UN*1*11**1~
DTP*472*D8*20260315~
SV1*HC:85025*75.00*UN*1*11**1~
DTP*472*D8*20260315~
SE*30*0001~
GE*1*1~
IEA*1*000000001~

This 837P submits a single claim (CLM001) for patient John Doe with two service lines: an office visit (99214, $150) and a CBC lab test (85025, $75), both performed on March 15, 2026, at an office setting (POS 11), with a diagnosis of acute upper respiratory infection (J06.9).

837 Submission Workflow

Claims do not go directly from the provider to the payer. The typical workflow involves several intermediaries and checkpoints.

Provider to Clearinghouse to Payer

The 837 travels provider → clearinghouse → payer; the 835 remittance comes back through the same path, typically 7–21 days later.

Claim generation. The provider’s practice management system (PMS) or EHR generates an 837 transaction from the encounter data. Most PMS systems batch claims — accumulating charges throughout the day and generating a single 837 file containing multiple claims at end-of-day.
Clearinghouse submission. The 837 is transmitted to a clearinghouse via SFTP, AS2, or a web portal. Major clearinghouses include Availity, Change Healthcare (now Optum), Trizetto, and Office Ally.
Clearinghouse scrubbing. The clearinghouse validates the 837 against X12 syntax rules, payer-specific requirements, and common billing errors. Claims that fail scrubbing are rejected back to the provider with error codes. Claims that pass are forwarded to the appropriate payer.
Payer receipt. The payer receives the 837 from the clearinghouse and generates a 999 (Implementation Acknowledgment) confirming receipt.
Adjudication. The payer processes the claim against the patient’s benefit plan, verifying eligibility, applying allowed amounts, and determining payment.
Remittance. The payer generates an 835 remittance advice containing the payment decision and sends it back through the clearinghouse to the provider.

Real-Time vs Batch Submission

Batch submission is the traditional model. Claims accumulate and are submitted in batches — typically daily. The 835 response arrives 7-21 days later after the payer completes adjudication. Most claims are still processed in batch mode.

Real-time submission (also called real-time adjudication) is available from some payers for certain claim types. The provider submits a single claim, and the payer returns an adjudication response within seconds. This is most common for:

Eligibility verification (270/271 transactions, often preceding the 837)
Simple professional claims with no medical review required
Dental claims

Real-time adjudication reduces the payment cycle from weeks to seconds but requires direct payer connectivity and is not universally available.

Acknowledgments and Responses

Several response transactions follow an 837 submission. Each lands at a different point in the lifecycle and answers a different question.

Time spacing is logarithmic. Receipt acks (TA1, 999) arrive within hours; payment decisions (277CA, 835) take days to weeks. Only the 835 confirms payment.

Transaction	Purpose	Timing
TA1	Interchange acknowledgment (ISA envelope accepted/rejected)	Immediate
999	Implementation acknowledgment (X12 syntax validation)	Minutes to hours
277CA	Claim acknowledgment (claim accepted for adjudication or rejected)	Hours to days
835	Remittance advice (payment/denial decision)	7-21 days

The 999 confirms that the file was syntactically valid X12. The 277CA confirms that individual claims were accepted for processing. Neither guarantees payment — they only confirm receipt and initial validation.

Common 837 Rejection Codes and Fixes

Claims are rejected at two stages: the clearinghouse (pre-adjudication) and the payer (post-adjudication). Each has different error patterns.

A claim runs two rejection gates: the clearinghouse stops X12 syntax and data-quality errors before adjudication, while the payer returns coverage and policy denials in the 277CA or 835 afterward. Different error classes, different fixes.

Clearinghouse Rejections

These are X12 syntax and data quality errors caught before the claim reaches the payer.

Error	Description	Fix
Invalid NPI	Billing or rendering NPI is not valid	Verify NPI on NPPES registry
Missing subscriber ID	Member ID is blank or invalid	Confirm patient insurance information
Invalid procedure code	CPT/HCPCS code is not valid for date of service	Check code set for current year
Invalid diagnosis code	ICD-10 code is not valid or not specific enough	Use most specific diagnosis code available
Missing place of service	POS code is required but blank	Add appropriate POS code
Invalid date format	Date not in CCYYMMDD format or is out of range	Correct date format and values
Duplicate claim	Same CLM01 submitted previously	Verify if original was processed; use corrected claim if needed

Payer Rejections and Denials

These are adjudication-level rejections returned in the 277CA or 835.

Code	Description	Fix
Patient not found	Member ID does not match payer records	Verify insurance card, check 270/271 eligibility
Authorization required	Service requires prior auth that is missing	Obtain authorization before resubmitting
Timely filing	Claim submitted after payer’s filing deadline	File within deadline (typically 90-365 days depending on payer)
Coordination of benefits	Payer believes another insurer is primary	Verify primary/secondary order, submit to correct payer first
Non-covered service	Service not covered under patient’s benefit plan	Appeal with documentation or bill patient
Bundling	Service is included in another service’s payment	Review NCCI edits, unbundle if appropriate
Invalid modifier	Modifier is missing, incorrect, or inconsistent	Review modifier guidelines for the procedure

Reducing Rejection Rates

The most effective strategies for reducing 837 rejections:

Verify eligibility before submission. Use a 270/271 transaction to confirm the patient’s coverage, effective dates, and member ID before generating the 837.
Scrub claims internally. Run claims through an internal rules engine that checks for common errors before sending to the clearinghouse.
Keep code sets current. ICD-10, CPT, and HCPCS codes change annually. Use current code sets and update them on October 1 (ICD-10) and January 1 (CPT/HCPCS).
Monitor rejection patterns. Track rejections by code and payer. If a specific payer consistently rejects for the same reason, there may be an enrollment or configuration issue to resolve.
Automate authorization tracking. Denials for missing authorization (CARC 197 — “Precertification/authorization/notification/pre-treatment absent”) are among the most common and most preventable. Automate authorization checks during scheduling and prior to claim submission.

The 837 to 835 Round-Trip

The 837 and 835 form a matched pair. The claim number you assign in the 837’s CLM01 field is returned in the 835’s CLP01 field, creating a traceable link between submission and payment.

Matching Claims to Payments

CLM01 ↔ CLP01 is the primary matching key — design your claim numbers to uniquely reference billing-system records. Other fields verify the match; the round-trip itself spans 7–21 days.

837 Field	835 Field	Purpose
`CLM01` (Claim Number)	`CLP01` (Claim Number)	Primary matching key
`SV1/SV2` (Service Lines)	`SVC` (Service Lines)	Line-level matching
`CLM02` (Total Charge)	`CLP03` (Total Charge)	Verification
`HI` (Diagnosis Codes)	—	Not returned in 835
`REF*D9` (Claim Identifier)	`CLP07` (Payer Claim Number)	Secondary matching key

Designing your claim numbering scheme thoughtfully makes 835 processing significantly easier. Use unique, sequential claim numbers in CLM01 that directly reference records in your billing system.

Tracking the Full Lifecycle

For complete revenue cycle visibility, track each claim through every stage:

837 generated — Claim created with unique claim number
837 submitted — File sent to clearinghouse (log date, batch number)
999 received — Syntax acceptance confirmed
277CA received — Claim accepted for adjudication (or rejected)
835 received — Payment decision received
Payment posted — Amounts applied to patient account
Balance resolved — Patient billed, payment collected, or balance written off

Gaps in this lifecycle (a claim with no 999, a 999 with no 277CA, a 277CA with no 835) indicate processing issues that need investigation.

Clearinghouse Connectivity

The clearinghouse is the intermediary between providers and payers. Choosing and integrating with a clearinghouse is a critical technical and business decision.

What Clearinghouses Do

Format validation: Verify X12 syntax compliance before forwarding to payers.
Payer routing: Route claims to the correct payer based on payer ID.
Scrubbing: Check claims against payer-specific rules and NCCI edits.
Translation: Handle format differences between the provider’s system and individual payer requirements.
Aggregation: Consolidate 835 remittances from multiple payers into a single delivery.
Reporting: Provide claim status dashboards and rejection analytics.

Connectivity Options

Method	Description	Best For
Web portal	Manual upload/download via browser	Low-volume practices
SFTP	Automated file exchange via secure FTP	Medium-volume providers
AS2	Automated, encrypted B2B messaging	High-volume providers and payers
API	REST or SOAP web service	Real-time submission, modern integrations
Direct connect	Dedicated connection to a specific payer	Highest-volume payer relationships

Most practice management systems include built-in clearinghouse integrations. For custom integrations or high-volume scenarios, SFTP and AS2 are the standard protocols.

Major Clearinghouses

The healthcare clearinghouse market is dominated by a few major players: Availity (largest by transaction volume), Change Healthcare/Optum, Trizetto (Cognizant), Waystar, and Office Ally. Each has different strengths in payer coverage, claim scrubbing capabilities, and reporting features. Selection typically depends on which payers the provider bills most frequently and what integrations the provider’s PMS supports.

Next Steps

The EDI 837 is the foundation of electronic claims processing in healthcare. Whether you are implementing a new billing system, integrating with a clearinghouse, or optimizing your claims submission workflow, understanding the X12 structure and submission pipeline is essential for clean claims and fast payment.

CMS Interoperability Services — We build claims processing pipelines, clearinghouse integrations, and payer connectivity solutions.
Healthcare EDI 835: Remittance Advice Guide — Understand the 835 remittance response that follows your 837 claim submission.
Healthcare Interoperability Consulting — Comprehensive integration strategy spanning EDI, HL7, and FHIR.

Healthcare EDI 837: Claims Submission Guide for Providers