Medical Billing Clearinghouses: How They Work and How to Choose

Short answer

A medical billing clearinghouse is a network that sits between your billing software and the payers. It takes the claims your system produces, translates them into HIPAA-compliant X12 EDI, runs front-end edits, and routes each one to the right payer. It also receives the 835 electronic remittance advice (ERA) files payers send back and delivers them to your system.

A clearinghouse brokers five core transaction types: the 837 (claim submission), 835 (ERA), 270/271 (eligibility), 276/277 (claim status), and 277CA (claim acknowledgment). Stedi's documentation covers the full lifecycle for 837 claims, 277CA acknowledgments, and 835 ERAs.

Every payer connection a billing company has runs through a clearinghouse. Choosing one comes down to four things: payer coverage for your mix, ERA enrollment effort, pricing model, and how cleanly it integrates with your RCM platform.

What a clearinghouse does and why it exists

HIPAA Administrative Simplification mandates standardized X12 5010 EDI transactions, but each payer layers its own companion guide, field requirements, and filing deadlines on top of the base standard. A billing company submitting to 40 payers would otherwise need 40 separate technical connections.

A clearinghouse is the translation hub that removes that. Your system sends a batch file or an API call. The clearinghouse maps it to the correct X12 format for each payer, applies front-end edits, and routes it to the right payer endpoint. When the payer responds with a 277CA acknowledgment, a claim status update, or an 835 ERA, the clearinghouse receives that file and hands it back to your billing system.

Front-end edits are the clearinghouse's scrubbing layer. They run before the claim reaches the payer and catch missing required fields, invalid NPI or taxonomy codes, date logic errors, and payer-specific rules the clearinghouse has encoded for that carrier. A claim that fails these edits never reaches the payer. That is a clearinghouse rejection, not a payer denial, and the difference drives different work.

Sources: CMS Administrative Simplification — Transactions · X12.org Transaction Set Directory

The EDI transaction flow from submission to payment

A single claim touches several X12 transaction sets:

• 837P / 837I / 837D — professional, institutional, and dental claim submission
• 277CA — claim acknowledgment from the clearinghouse and then the payer, confirming whether each claim was accepted into adjudication
• 276 / 277 — claim status inquiry and response, used to poll payer systems between submission and ERA receipt
• 270 / 271 — eligibility inquiry and response, run before a claim is filed to confirm coverage and pull benefit detail
• 835 — the electronic remittance advice that carries line-level payment, adjustment, and denial detail after adjudication

The X12 standards body publishes the base specification for each transaction set; clearinghouses publish companion guides documenting payer-specific deviations.

A clean claim runs like this: your system generates an 837, the clearinghouse validates and routes it, the payer returns a 277CA within hours confirming receipt, the payer adjudicates, and the 835 ERA arrives 7 to 30 days later. ERA delivery requires a separate enrollment step (covered below). You do not receive 835s automatically just because you submitted a claim.

Sources: X12.org Transaction Set Directory · Stedi Healthcare Documentation

Clearinghouse rejection vs. payer denial

This distinction trips up new billers. A clearinghouse rejection means the claim failed validation before it was transmitted. The payer never saw it. The error appears in the 277CA with a reason code, and the fix is to correct the claim and resubmit, often the same day.

A payer denial is a different event. The claim cleared the clearinghouse, passed the 277CA acceptance check, entered the payer's adjudication engine, and the payer decided not to pay it over a coverage issue, an authorization requirement, a bundling rule, or a coordination of benefits conflict. Denials arrive in the 835 ERA, not the 277CA. They require denial work: reading the CARC and RARC codes, then deciding whether to correct, appeal, or write off the line.

Rejections are fixable in minutes with a good workflow; denials can take weeks. Treating a rejection like a denial delays action on a claim you could have corrected immediately.

A 277CA acceptance confirms the claim entered the payer's adjudication queue. It does not mean the claim will be paid.

Payer enrollment and ERA enrollment

Two enrollment processes matter for billing companies, and billers routinely conflate them.

Payer enrollment (trading partner setup) registers your organization as an authorized submitter with each payer through the clearinghouse. Most clearinghouses handle it when you onboard: you provide your NPI, Tax ID, and billing contact, and they coordinate registration. Some payers require a formal agreement or credentialing-adjacent paperwork before they accept electronic submissions.

ERA enrollment is a separate, per-payer process. Even after you are cleared to submit claims to a payer, you must explicitly enroll to receive 835 ERA files back. Each commercial payer has its own form or portal; some accept clearinghouse batch enrollments, others require a direct request. Timelines run from a few days to several weeks. Stedi's ERA documentation confirms transaction enrollment is always required before a provider can receive 835s. There is no automatic delivery.

For a billing company running many client practices, ERA enrollment at scale is one of the heaviest operational tasks. A clearinghouse with managed enrollment, where its team works the payer-by-payer paperwork for you, turns a weeks-long staff job into a ticket you open and track.

Sources: Stedi — Electronic Remittance Advice Enrollment · CMS Administrative Simplification — Transactions

Major clearinghouses billing companies encounter

The table covers the clearinghouses your team is most likely to deal with. "Quote-based" means the vendor does not publish rates; you contact sales for a contract.

You cannot compare the quote-based vendors on price without a signed contract, and the per-claim figures in third-party guides are often stale. Get current rates from each vendor directly.

Sources: Availity · Optum / Change Healthcare · Change Healthcare breach impact (Nixon Peabody) · Waystar · Office Ally · Claim.MD · TriZetto / Cognizant · Stedi

How to choose a clearinghouse for your billing company

**Payer coverage against your mix** is the starting point. If your book is heavy with Anthem, Availity is effectively unavoidable, since Anthem routes new submitters through it. If you bill Medicare and regional Medicaid, confirm each clearinghouse has direct enrollment with those specific payers, not generic "Medicare coverage."

**ERA enrollment effort** is the line item most billing companies underweight. Every new payer for a new client requires ERA enrollment. A managed enrollment team turns that weeks-long task into a ticket. Add up the enrollment burden across your whole roster before you decide on price alone.

**Pricing model fit** depends on volume and growth stage. Per-claim pricing is predictable at low volume; flat or volume-tiered plans get cheaper as you scale. Get quotes at your current volume and at twice it, and watch for line-item fees on eligibility checks, attachments, and secondary claims.

**API and automation** set the ceiling on what your RCM software can do. A modern REST API lets your platform run real-time eligibility, automated status polling, and programmatic ERA retrieval; SFTP-only connections force batch processes and slow the feedback loop. If your platform already has a built-in clearinghouse connection, check whether it carries the full transaction set or only claim submission.

**Support quality** is hard to judge before signing, so research it through billing-company forums and peer communities. Support issues surface as enrollment delays, companion-guide questions, and 277CA error codes that need expert reading. A named support team beats a ticket queue the day you hit a rejection from a payer you have never billed.

How Medi handles clearinghouse connectivity

Medi connects to payers through Stedi, a programmable clearinghouse with 3,400+ payer connections and a REST API for every major HIPAA transaction set. The connectivity is built in, so you do not manage a separate clearinghouse contract to run Medi.

Submit a claim and Medi generates the 837P, routes it through Stedi, and surfaces the 277CA acknowledgment in the claim detail. Per-payer ERA enrollment is still required, because that is a payer requirement and not a software one, and Medi's ERA workflow walks you through it. Once you are enrolled, 835 files come back through Stedi and post into Medi's payment ledger.

Related workflow guides:

• 277CA claim acknowledgment guide
• Posting ERAs in Medi
• Book a demo

When Medi is not the right fit

Medi is built for billing companies that run revenue cycle workflows across multiple client practices after clinical coding is done. It is the wrong fit if you need:

• A clearinghouse to plug into an EHR or practice management system you already own and operate
• Prior authorization submission or clinical documentation workflows
• A standalone clearinghouse portal for a single small practice with no billing-company relationship
• Multi-specialty coding or clinical documentation review tools

If you want a clearinghouse portal without a full RCM platform behind it, Office Ally and Claim.MD are worth a look for their low-friction onboarding.

Frequently asked questions

What is the difference between a clearinghouse rejection and a payer denial?

A clearinghouse rejection happens before the claim reaches the payer. The clearinghouse runs front-end edits on required fields, NPI validity, date logic, and payer-specific rules, then kicks back any claim that fails. You get a 277CA with error codes, the payer never sees the claim, and you correct and resubmit, often the same day.

A payer denial happens after the claim enters adjudication. It cleared the clearinghouse, the payer received a 277CA-accepted claim, reviewed it, and decided not to pay. Denials arrive in the 835 ERA with CARC and RARC reason codes, and resolving them takes longer: read the denial reason, then appeal, correct and resubmit with documentation, or write off the balance.

Both cut your collected revenue, but they need different responses and different tools. A good RCM platform separates rejections from denials so your team works each queue with the right actions.

Do I need to choose a clearinghouse if my RCM platform already has one built in?

Not necessarily. Many RCM platforms, Medi included, embed clearinghouse connectivity so you submit claims and receive ERAs without a separate contract or portal. The platform handles routing, acknowledgment monitoring, and ERA delivery as part of the core workflow.

You might still need a direct clearinghouse relationship if a payer requires it (Anthem mandates Availity for new submitters), if your platform's built-in clearinghouse lacks enrollment with a specific payer you need, or if you have to submit transactions your platform does not yet route, such as certain attachments or coordination of benefits claims.

Before signing a standalone contract, confirm your RCM platform already covers the payers you bill most. A duplicate clearinghouse relationship adds cost and gives you two sets of enrollment records to maintain.

What are the major medical billing clearinghouses?

The ones billing companies meet most often are Availity, Optum/Change Healthcare, Waystar, TriZetto (Cognizant), Office Ally, Claim.MD, and Stedi. Each sits in a different part of the market.

Availity and Change Healthcare are the two largest by transaction volume and payer reach; Change Healthcare's February 2024 ransomware outage caused weeks of nationwide claims disruption and pushed many billers toward alternatives. Waystar is the largest SaaS-native clearinghouse and strong in mid-market RCM. TriZetto serves large billing companies and enterprise health systems with deep PM/EHR integrations. Office Ally is the entry point for small practices and solo billers; claims to participating payers are free, though a $44.95/month fee applies per Tax ID and NPI for non-participating-payer claims. Claim.MD publishes per-transaction pricing openly, which is rare, and has a clean API. Stedi is the developer-first option, with a modern REST API and JSON/EDI support for every core HIPAA transaction type.

No single clearinghouse fits every billing company. The right one depends on your payer mix, your current RCM platform, and your volume.

How does ERA enrollment work, and how long does it take?

ERA enrollment is a per-payer process that authorizes a clearinghouse to receive your 835 files from that payer and deliver them to your billing system. You cannot skip it. 835s do not flow automatically just because you submit claims through a clearinghouse.

For each payer, you or your clearinghouse submits an enrollment request with your NPI, Tax ID, and clearinghouse routing information. Each payer runs its own process: some accept a clearinghouse batch request, others require a form through their provider portal, and a few require a call. The timeline runs from a few days for Medicare to several weeks for some commercial payers.

Billing companies hit this burden at scale. If you onboard five or more practices a month, a clearinghouse with managed enrollment that works the payer-by-payer paperwork is worth paying more for. The alternative is building an internal enrollment-tracking workflow and absorbing the timeline.

What is the 277CA and why does it matter?

The 277CA is the Health Care Claim Acknowledgment transaction. It tells your billing system whether each claim in a batch was accepted or rejected, in two stages: the clearinghouse sends a 277CA first (within about 30 minutes for Stedi) on whether the claim passed front-end edits, then the payer sends a 277CA on whether it accepted the claim for adjudication.

A 277CA acceptance at the payer level means the claim is in the adjudication queue, not that it will be paid. A 277CA rejection at the clearinghouse level means the claim never reached the payer and needs correction.

Watching 277CAs is the first line of defense for clean A/R. A claim that never produced a 277CA acceptance needs immediate attention, because it has not entered the payer's system at all. Stedi's claim acknowledgment documentation covers the full response lifecycle, including error code interpretation.