837 Claim Transaction

What an 837 Claim Transaction is

An 837 Claim Transaction is the ASC X12 standard file format for sending healthcare claims electronically. HIPAA requires covered entities to use the 837 standard instead of proprietary claim formats when submitting claims to health plans.

There are three primary versions: 837P for professional claims, 837I for institutional claims, and 837D for dental claims. Behavioral health programs most often use 837P for outpatient services and 837I for facility-based services like PHP, IOP, and residential.

An 837 file is a batch. One file can contain many claims and many service lines. Each segment and loop in the 837 carries a specific piece of data, for example subscriber info, diagnosis codes, service dates, modifiers, or authorization numbers.

Why the 837 matters operationally

Every electronic claim your billing system sends becomes an 837 under the hood. Clearinghouses and payers validate the structure and the content of that 837 before a claim ever reaches adjudication. Structural errors cause rejections, which never show up as denials on an 835 and never start the timely filing clock.

Small mapping mistakes inside the 837 can quietly cost real money. A wrong payer ID in the ISA or NM1 segment sends claims to the wrong plan and wastes days. Missing or misfiled authorization numbers in the 2300 REF segment can lead to CO-197 denials for behavioral health services that actually had auth. Incorrect place-of-service or revenue code mapping in an 837I for PHP or IOP can shift a claim from covered to non-covered and lose entire per-diem days.

For leaders, 837 quality is an upstream control point. Clean-claim rate, denial rate, days in AR, and cost to collect all depend on how accurate and complete the 837 data is before the claim hits the payer front door.

How the 837 is used and read day to day

Most billers never hand-build an 837. The practice management system generates the 837 file, then sends it to the clearinghouse, which forwards accepted claims to payers. Workflows focus on the clearinghouse rejections and payer rejections that point back to problems in the 837.

When something breaks at scale, operators often must open the raw 837 to see what the system actually sent. Examples:

• Checking the billing provider and rendering provider loops when claims deny for NPI or taxonomy mistakes.
• Confirming that the authorization or referral number populated in the correct REF segment for a residential stay.
• Reviewing how modifiers and units were sent for group therapy or IOP to explain a CO-96 or CO-97 denial.

Most clearinghouses and some billing systems provide an 837 viewer that translates raw segments into readable screens. RCM leads and analysts use those tools when CO-16 or CO-4 denials spike in a short window, or when a new payer implementation causes a wave of rejections tied to a specific 837 segment or loop.

• Assuming the EHR's 'claim preview' matches the 837 that actually went out, so the team chases diagnosis or modifier issues in the UI but never checks the 2400 service-line segments where the wrong modifiers were mapped and sent.
• Sending residential or PHP days on an 837P when the payer expects 837I with specific revenue codes, which produces a pattern of CO-96 non-covered service denials that look like clinical issues but are really file-format problems.
• Failing to populate the authorization number in the correct 2300 REF segment for concurrent-auth cases, which causes CO-197 denials for days past the initial auth even though the UR team obtained extensions.
• Recycling failed claims by correcting them in the UI but not regenerating a new 837 batch for that payer, which leaves old, bad 837 files sitting uncorrected and leads to timely filing risk and CO-29 denials.
• Ignoring clearinghouse-level 837 rejections for secondary claims with coordination-of-benefits data missing or mis-mapped, then trying to bill secondary payers on paper and creating months of PR-96 and CO-18 confusion.

Behavioral health programs often deal with carve-out behavioral health plans. Those plans can have unique 837 requirements, like specific payer IDs, member ID formats, or custom expectations for diagnosis pointer usage. If the 837 mapping is set up only for the medical carrier and not the carve-out BH plan, claims can reject at the front door and burn 10 to 20 days before anyone notices.

Facility-based behavioral health, such as residential, PHP, and IOP, commonly uses 837I with per-diem billing. Multi-week episodes require accurate span dates, revenue codes, occurrence codes, and units for each covered day. A small mapping mistake in the 837, such as pushing all days to one revenue code or omitting condition codes required by a state Medicaid MCO, can result in an entire 30-day stay denying as non-covered.

State Medicaid and MCO behavioral health plans often embed additional validation rules around diagnosis codes, level-of-care codes, and authorization references. For example, an 837 might need specific value codes or rate codes to match the Medicaid fee schedule or waiver program. If the EHR does not populate those elements correctly in the 837, the plan may systematically reject or deny claims even when clinical documentation and eligibility are both correct.

For outpatient therapy and psychiatry, many BH groups use telehealth heavily. Telehealth modifiers and place-of-service codes must land in the right 837 loops and segments. Misplacing modifier 95 or 93, or sending telehealth encounters with the wrong POS, can turn into CO-50 medical necessity or CO-96 non-covered denials for large blocks of virtual visits.

AI agents can watch 837 traffic at scale. An agent can read raw 837 files, compare them to rejections and 835 remittances, and flag patterns like 'all 837P files to Payer X are missing the authorization REF segment' or 'claims with residential revenue codes are failing a specific Medicaid edit.' That reduces days lost to silent mapping issues and helps operators prioritize fixes that protect large-dollar episodes.

Supabill's claims-scrubbing agent can hold payer-specific 837 rules in memory, inspect each generated 837 before it hits the clearinghouse, and block or flag claims that would likely reject or deny based on past CARC/RARC patterns. A human still needs to own final decisions about payer configuration changes, conversations with EHR and clearinghouse vendors, and clinical or compliance judgments when a payer's 837 rules conflict with documentation or state guidance.

What is the difference between 837P and 837I for behavioral health billing?

The 837P is the professional claim format, typically used for outpatient behavioral health services such as office-based therapy, psychiatry visits, and some telehealth. The 837I is the institutional claim format, used for facility-based services like PHP, IOP, residential, and inpatient psych, especially when you bill per-diem rates with revenue codes and occurrence codes. Using 837P instead of 837I for a residential program can cause systemic non-covered or incorrectly paid claims, even if the clinical documentation is correct.

For the underlying transaction standard, see the ASC X12 837 documentation at X12. Source

How does an 837 Claim Transaction relate to HIPAA requirements?

HIPAA designates the 837 as the standard electronic format for healthcare claims. Covered entities that submit electronic claims to health plans are expected to use the ASC X12 837 format rather than proprietary or non-standard file types. CMS oversees HIPAA Administrative Simplification rules, which include requirements for standard transactions, code sets, and identifiers. Behavioral health providers interacting with Medicaid, Medicare, and commercial plans all sit under the same 837 standard, even though payer-level companion guides add extra rules.

More information on HIPAA transaction standards is available from CMS at cms.gov. Source

Why do some of our 837 files get rejected before a claim number is assigned?

Rejections at the clearinghouse or payer front end usually mean the 837 failed basic structural or content edits. Common causes include missing subscriber IDs, invalid diagnosis codes, mismatched payer IDs, missing billing provider information, or invalid formatting of dates and IDs. In behavioral health, extra risk comes from mis-mapped telehealth modifiers, missing authorization references for levels of care that always require auth, and incorrect use of diagnosis pointers. These rejections are not denials and typically do not appear on 835 remits, so tracking them requires watching clearinghouse reports in addition to denial reports. Source

How can I tell whether a claim problem is in the 837 or in the payer's adjudication logic?

Start by reviewing clearinghouse and payer rejection reports. If a claim never receives a payer claim number and only shows a front-end rejection, the problem is usually in the 837 structure or basic content. If a payer assigns a claim number and later denies with a CARC, the 837 was accepted and the issue is in adjudication logic, benefits, or medical policy. For behavioral health, checking whether the authorization number, level-of-care codes, and telehealth indicators were correctly present in the 837 is key before challenging the payer's adjudication. Source

Do small behavioral health practices need to understand raw 837 files, or is the billing system enough?

Most small practices can rely on their billing system and clearinghouse for day-to-day workflows, but someone on the team should be comfortable inspecting an 837 when patterns of rejections or denials appear. Reading the raw 837, or using an 837 viewer, lets you confirm how NPIs, modifiers, diagnoses, and authorization numbers were actually sent. This is often the fastest way to solve payer carve-out quirks, Medicaid companion guide issues, and telehealth configuration mistakes that affect many claims at once. Source

• X12 - Standards
• CMS - Administrative Simplification