An 837 claim file is the electronic version of a healthcare claim, built to the ANSI ASC X12N standard HIPAA requires for electronic claim submission. It carries exactly what a CMS-1500 or UB-04 paper form carries, just formatted as structured data rather than a printed form. Practice management software generates it automatically as part of claims submission and processing, so almost no one types one by hand.
What Is an 837 Claim File?
An 837 file is the standard electronic transaction providers use to submit healthcare claims to payers, built to the ANSI ASC X12N EDI format that HIPAA mandates for electronic claims.
What Are the Different Types of 837 Files?
Three variants exist: 837P for professional claims, the electronic equivalent of the CMS-1500, 837I for institutional claims, the electronic equivalent of the UB-04, and 837D for dental claims.
Who Generates an 837 File?
Practice management or billing software generates the 837 automatically from the claim data entered into the system; it is not something billing staff typically create or edit by hand.
What Files Come Back After Submitting an 837?
Three response files typically follow in order: a 999 confirming the file parsed correctly, a 277CA acknowledging each individual claim, and eventually an 835 reporting payment or denial.
Key Takeaways
- The 837 is the HIPAA-mandated electronic claim transaction, with 837P, 837I, and 837D variants for professional, institutional, and dental claims respectively.
- An 837 file carries the same core data as a paper CMS-1500 or UB-04, just in structured EDI format.
- Billing software generates 837 files automatically; they are not manually typed.
- A 999 acknowledgment confirms the file parsed, a 277CA confirms each claim was accepted for adjudication, and an 835 reports the actual payment decision.
- A rejected 837 never reached payer adjudication, so there is nothing to appeal; the data must be corrected and resubmitted.
- Clearinghouse front-end edits catch many 837 errors, missing payer IDs or POS mismatches, before the file ever reaches the payer.
Why Does the 837 File Matter to a Billing Team?
Most billing staff never need to read raw 837 data until a claim fails at the clearinghouse and the rejection message names a segment they don’t recognize. Understanding the file’s structure at a basic level helps translate a cryptic rejection into an actionable fix, especially useful in multi-specialty group practice settings submitting a high volume of claims daily.
How Is the 837 Different From the CMS-1500?
The CMS-1500 is the paper form; the 837P is its electronic correspondent, carrying the same required data fields in a structured, machine-readable format instead of a printed grid.
What Are the Key Things to Know About the 837 Claim File?
The ten points below cover the file’s structure, variants, and the response cycle that follows submission.
837P: Professional Claims
837P is used by physicians, nurse practitioners, physician assistants, physical and occupational therapists, and other non-institutional providers and suppliers. It is the electronic correspondent to the CMS-1500.
837I: Institutional Claims
837I is used by hospitals and other facilities, the electronic correspondent to the paper UB-04 form. It carries additional facility-specific data, such as revenue codes and admission and discharge dates.
837D: Dental Claims
837D is used for dental claims, carrying CDT procedure codes rather than CPT or HCPCS codes, reflecting dental billing’s distinct code set separate from medical billing.
The EDI Structure Itself
An 837 file is plain text built to the X12 EDI standard: rows of capital letters, asterisks, and tildes with no visible labels or line breaks in the places a reader might expect. It systematically carries the same information a paper claim form does, organized into standardized segments.
Implementation Guides and Companion Guides
The ASC X12N implementation guide defines the technical content and format requirements for the 837 transaction, and each Medicare Administrative Contractor publishes its own CMS-approved companion guide clarifying Medicare-specific data requirements. See CMS’s MLN guide on CMS-1500 and 837P billing for the federal-level overview.
The 999 Functional Acknowledgment
The first response file, a 999, confirms whether the submitted batch parsed correctly according to the X12 syntax rules, essentially a structural check before any actual claims data is evaluated.
The 277CA Claim Acknowledgment
Following a successful 999, a 277CA reports acceptance or rejection at the individual claim level, confirming each claim passed the payer’s front-end validation and entered adjudication.
The 835 Remittance Advice
Once a claim is adjudicated, the payer returns an 835, the electronic remittance advice reporting payment, adjustment, and denial information, the same file that automated payment posting systems read to apply payments.
What a Rejected 837 Means
A rejected 837, or a claim rejected within it at the 277CA stage, never reached actual payer adjudication. There is no appeal process for a rejection; the underlying data error must be corrected and the claim resubmitted.
Clearinghouse Front-End Edits
Most practices route 837 files through a clearinghouse before they reach the payer. The clearinghouse applies front-end edits, checking for missing payer IDs, invalid modifiers, or place-of-service mismatches, catching many errors before the payer ever sees the file.
When Does a Claim Need to Be Resubmitted as a New 837?
Resubmit as a new 837 whenever the original was rejected at the 999 or 277CA stage, meaning it never reached adjudication; the corrected data needs to go out as a fresh submission, not as an appeal.
When Is a Corrected Claim Different From a New 837 Submission?
A corrected claim applies when the original 837 was accepted and adjudicated, but the payer’s decision needs to be revised based on new or corrected information, typically using a specific claim frequency code rather than a plain resubmission. Getting this distinction right avoids confusing denial management staff working the wrong resolution path.
Best Practices for Managing 837 Claim Files
- Rely on clearinghouse front-end edits to catch common errors before the payer ever sees the file.
- Review 999 and 277CA responses promptly rather than assuming submission equals acceptance.
- Distinguish a true rejection, never reached adjudication, from a denial, adjudicated and refused, before deciding how to fix it.
- Keep companion guide requirements current for each major payer or Medicare Administrative Contractor.
- Train staff to recognize which 837 variant, P, I, or D, applies to each type of claim being submitted.
Mistakes to Avoid With 837 Claim Files
- Treating a 999 or 277CA rejection as a denial requiring an appeal instead of a correction and resubmission.
- Submitting institutional charges through an 837P instead of the correct 837I format.
- Ignoring 999/277CA response files entirely and only discovering a submission problem once payment posting reveals a claim was never actually paid.
- Assuming a clearinghouse’s front-end edits catch every possible payer-specific requirement.
- Losing track of which claims were accepted at 277CA but are still pending final 835 adjudication.
Illustrative Documentation Example
The scenario below is a hypothetical example for teaching purposes, not an actual patient billing case.
A practice submits a batch of claims as an 837P file. The 999 confirms the file parsed correctly, and the 277CA shows all but two claims accepted into adjudication; those two are flagged for an invalid provider taxonomy code. Billing staff correct the taxonomy code and resubmit just those two claims as a new 837P batch, rather than waiting to see if they appear on the eventual 835.
Conclusion
The 837 file is the invisible infrastructure behind nearly every electronic claim a practice submits, and understanding its basic structure, the P/I/D variants and the 999/277CA/835 response cycle, turns a cryptic clearinghouse rejection into an actionable fix rather than a mystery. A practice with recurring 837 rejections often benefits from a closer look at its medical coding services and clearinghouse configuration.
FAQs
Do I need special software to read an 837 file?
Most practice management systems display the underlying claim data in a readable format without requiring staff to read raw EDI; direct file inspection is mainly useful for troubleshooting an unusual clearinghouse rejection.
What is the difference between an 837 rejection and a claim denial?
A rejection means the file or claim never reached payer adjudication due to a data or format error; a denial means the claim was adjudicated and the payer formally refused payment for a substantive reason.
Can a single 837 file contain claims for multiple patients?
Yes. An 837 file is typically submitted in batches containing many claims for many patients, not one file per individual claim.
Is the 837 format the same across all payers?
The core X12 standard is uniform, but individual payers and Medicare Administrative Contractors publish companion guides with payer-specific requirements layered on top of the base standard.
What happens to an 837 claim after the 277CA acceptance?
It moves into the payer’s adjudication process, the results of which are eventually reported back in an 835 electronic remittance advice, the file automated payment posting systems read to apply payments and adjustments.
