Medical Billing Clearinghouses Explained

Medical Billing Clearinghouses: How They Work and How to Choose

Short answer

A medical billing clearinghouse is a health information network that sits between your billing software and the payers. It receives claims in whatever format your system produces, translates them into HIPAA-compliant X12 EDI, runs front-end edits, and routes them to each payer. On the way back, it accepts 835 electronic remittance advice (ERA) files from payers and delivers them to your system. Stedi's documentation describes the full transaction lifecycle for 837 claims, 277CA acknowledgments, and 835 ERAs. The core transaction types a clearinghouse brokers are the 837 (claim submission), 835 (ERA), 270/271 (eligibility), 276/277 (claim status), and 277CA (claim acknowledgment). Billing companies deal with clearinghouses daily whether they realize it or not — every payer connection runs through one. Choosing the right one comes down to payer coverage depth, ERA enrollment friction, pricing model, and how well it integrates with your RCM platform.

What a clearinghouse does and why it exists

Payers do not accept claims in arbitrary formats. The HIPAA Administrative Simplification rules mandate standardized X12 5010 EDI transactions, but each payer also layers on proprietary companion guides, 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 solves this by acting as a translation hub. 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 fires 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 routes it back to your billing system.

Front-end edits are the clearinghouse's claim scrubbing layer. These checks run before the claim reaches the payer: 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 front-end edits never reaches the payer. This is a clearinghouse rejection, not a payer denial — and the distinction matters a great deal for your workflow.

The EDI transaction flow from submission to payment

The lifecycle of a single claim touches several distinct X12 transaction sets:

• 837P / 837I / 837D — professional, institutional, and dental claim submission
• 277CA — claim acknowledgment returned by 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 for real-time status between submission and ERA receipt
• 270 / 271 — eligibility inquiry and response, typically run before a claim is filed to confirm coverage and obtain benefit detail
• 835 — the electronic remittance advice that carries line-level payment, adjustment, and denial detail after adjudication concludes

The X12 standards body publishes the base specifications for each transaction set. Clearinghouses then publish their own companion guides documenting payer-specific deviations.

The sequence for a clean claim looks 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 anywhere from 7 to 30 days later. ERA delivery requires a separate enrollment step (see below) — you do not receive 835s automatically just because you submitted a claim.

Clearinghouse rejection vs. payer denial

This distinction trips up new billers consistently. A clearinghouse rejection means the claim failed validation before it was ever transmitted to the payer. 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.

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

Clearinghouse rejections are fixable in minutes if you have a good workflow. Payer denials can take weeks to resolve. Confusing the two leads to delayed action on claims that could have been corrected quickly.

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 distinct enrollment processes matter for billing companies.

Payer enrollment (also called trading partner setup) is the process of registering your organization as an authorized submitter with each payer through the clearinghouse. Most clearinghouses handle this on your behalf when you onboard — you provide your NPI, Tax ID, and billing contact information, and the clearinghouse coordinates 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 enrolled to submit claims to a payer, you must explicitly enroll to receive 835 ERA files back. Each commercial payer has its own enrollment form or portal. Some accept clearinghouse batch enrollments; others require a direct request. Enrollment timelines range from a few days to several weeks depending on the payer. Stedi's ERA documentation notes that transaction enrollment is always required before a provider can receive 835s — there is no automatic delivery.

For billing companies managing many client practices, ERA enrollment at scale is one of the most time-consuming operational tasks. The clearinghouses that offer managed enrollment services — where their team handles payer-by-payer paperwork on your behalf — save meaningful staff time.

Major clearinghouses billing companies encounter

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

No pricing comparison is possible for the quote-based vendors without a signed contract. The per-claim figures that appear in third-party guides are frequently outdated. Contact each vendor directly for current rates.

How to choose a clearinghouse for your billing company

Payer coverage and your payer mix are the starting point. If your client base is heavy with Anthem, Availity is likely unavoidable — Anthem routes new submitters through it. If you bill a lot of Medicare and regional Medicaid programs, verify each clearinghouse has direct enrollment with those specific payers, not just generic "Medicare coverage."

ERA enrollment effort matters more than most billing companies expect at the start. Every new payer you add for a new client requires ERA enrollment. A clearinghouse with a managed enrollment team cuts this from a weeks-long staff task to a ticket you open and follow up on. Calculate the enrollment burden across your entire client roster before choosing on price alone.

Pricing model fit depends on your volume and growth stage. Per-claim pricing is predictable at low volume; flat or volume-tiered plans become cheaper as you scale. Get quotes at your current volume and at 2x current volume. Watch for line-item fees on eligibility checks, attachments, and secondary claims — these add up.

API and automation access determines what your RCM software can do. A clearinghouse with a modern REST API lets your platform do real-time eligibility, automated claim status polling, and programmatic ERA retrieval. SFTP-only clearinghouses require batch processes and delay feedback loops. If your platform already has a built-in clearinghouse connection, check whether that connection supports the full transaction set or only claim submission.

Support quality is harder to evaluate before signing, but worth researching through billing company forums and peer communities. Clearinghouse support issues tend to surface as payer enrollment delays, EDI companion guide questions, and 277CA error codes that need expert interpretation. A clearinghouse with a named support team beats one with a ticket queue when you have a rejected claim from a payer you've never billed before.

How Medi handles clearinghouse connectivity

Medi connects to payers through Stedi, a programmable clearinghouse with 3,400+ payer connections and a REST API for all major HIPAA transaction sets. You do not need to manage a separate clearinghouse contract to use Medi — the connectivity is built in.

When you submit a claim through Medi, it generates the 837P, routes it through Stedi, and surfaces the resulting 277CA acknowledgment in the claim detail. ERA enrollment per payer is still required (that is a payer requirement, not a software one), and Medi's ERA workflow guides you through it. Once enrolled, 835 files come back through Stedi and post directly into Medi's payment ledger.

The relevant workflow documentation:

• 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 manage revenue cycle workflows across multiple client practices after clinical coding is complete. It is not a good fit if you need:

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

If you need a clearinghouse portal without a full RCM platform attached, Office Ally and Claim.MD are worth evaluating 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 — checking required fields, NPI validity, date logic, payer-specific rules — and kicks back any claim that fails. You get a 277CA with error codes. The payer never sees the claim. You correct the error and resubmit, often on the same day.

A payer denial happens after the claim enters adjudication. The claim made it through the clearinghouse, the payer received a 277CA-accepted claim, the payer reviewed it, and the payer decided not to pay. Denials arrive in the 835 ERA with CARC and RARC reason codes. Resolving them takes longer: reviewing the denial reason, deciding whether to appeal, correcting and resubmitting with additional documentation, or writing off the balance.

Both reduce your collected revenue, but they require different responses and different workflow tools. A good RCM platform surfaces rejections separately from denials so your team works each queue with the right action set.

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 clearinghouse contract or portal. In that case, the platform handles the 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, for example), if your platform's built-in clearinghouse does not have enrollment with a specific payer you need, or if you need to submit transactions — like certain attachments or coordination of benefits claims — that your platform does not yet route.

Before signing a standalone clearinghouse contract, confirm whether your RCM platform already covers the payers you bill most. Duplicate clearinghouse relationships add cost and create two sets of enrollment records to maintain.

What are the major medical billing clearinghouses?

The clearinghouses billing companies encounter most often are Availity, Optum/Change Healthcare, Waystar, TriZetto (Cognizant), Office Ally, Claim.MD, and Stedi. Each occupies 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 accelerated adoption of 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 — free for claim submission. Claim.MD publishes per-transaction pricing openly, which is unusual, and has a clean API. Stedi is the developer-first option with a modern REST API and JSON/EDI support for all core HIPAA transaction types.

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 that includes your NPI, Tax ID, and clearinghouse routing information. Each payer has its own process: some accept a clearinghouse batch enrollment request, others require a form submitted directly through their provider portal, and a few require a call. Timeline varies from a few days for Medicare to several weeks for some commercial payers.

Billing companies with many client practices face this enrollment burden at scale. A clearinghouse that offers managed enrollment services — where their team handles payer-by-payer paperwork — is worth a price premium if you are onboarding five or more practices per month. The alternative is building an internal enrollment tracking workflow and accepting the timeline as a cost of doing business.

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 submitted batch was accepted or rejected. There are two stages: the clearinghouse sends a 277CA first (within about 30 minutes for Stedi) confirming whether the claim passed front-end edits, and then the payer sends a 277CA confirming whether it accepted the claim for adjudication.

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

Monitoring 277CAs is the first line of defense for a clean A/R. Claims that never generated a 277CA acceptance need immediate attention; they have not entered the payer's system at all. Stedi's claim acknowledgment documentation covers the full response lifecycle including error code interpretation.