Medi vs Availity

Availity and Medi sit at different layers, so for most billing companies this is not an either/or. Availity is a payer-provider network and clearinghouse: the infrastructure that carries transactions between providers and health plans. Medi is the operating layer on top of that infrastructure, where staff run daily work across client practices. They solve different problems, and many billing companies run both.

This page covers what Availity does, where it stops, how a billing-company stack assembles around it, and what Medi adds that Availity alone does not.

Short answer

Availity calls itself "the nation's largest health information network," processing over 13 billion transactions a year across 3.4 million connected providers and 95 direct payer connections, per Availity's clearinghouse page. Its job is transaction routing: eligibility, claim submission, claim status, remittance, and prior authorization, moving data between providers and payers through one credentialed connection instead of dozens of payer portals. Several major payers, including the entire Anthem/Elevance family, have named Availity their exclusive EDI gateway, so any trading partner submitting Anthem claims routes through Availity no matter which billing platform they use.

Medi is the billing-company operating layer that runs on top of that infrastructure. It handles multi-practice workspaces, claim building and scrubbing, ERA review and exception handling, denials and appeals, payment posting, underpayment detection, book-wide reporting, user permissions, and audit trails. Medi uses Stedi as its clearinghouse, an API-first, HIPAA and HITRUST certified programmable clearinghouse that recently closed a $50 million Series C, so billing companies do not carry a separate clearinghouse contract.

A billing company can run both at once: Availity for payer-network connectivity on specific transactions, Medi for every workflow that surrounds them.

Sources: Availity EDI Clearinghouse · Availity Essentials Pro · Anthem EDI Gateway · Stedi

When you need Availity

Availity plays three roles, and which one applies changes the evaluation.

**Free payer portal.** Availity Essentials is payer-sponsored: health plans subsidize access so their networks can reach them without a subscription. BCBS plans in most states, Anthem, Aetna, Cigna, UnitedHealthcare, and dozens of regional plans treat Availity as a primary portal for eligibility, prior auth, claim status, and digital correspondence. A billing company that needs to check eligibility for a visit or file a one-off appeal for a payer that requires Availity will use Essentials no matter what else is in the stack. The baseline portal is free, so there is no subscription decision to make.

**EDI gateway for specific payers.** Anthem (Elevance Health) has designated Availity as its exclusive EDI gateway, per Anthem provider announcements. New submitters routing claims to any Anthem affiliate must send them through Availity's clearinghouse layer rather than directly to Anthem. This is a connectivity requirement, not a feature. Any platform submitting to Anthem routes through Availity somewhere in the chain.

**Paid RCM product.** Availity Essentials Pro and Essentials Plus add capabilities beyond the free portal: predictive claim editing that checks claims against recent payer history before submission, batch eligibility, denial management queues, analytics, and remittance tools. These sell to provider organizations and hospital systems that want to consolidate payer interaction without buying a separate billing system, per Availity's Essentials Pro page.

You need Availity when:

• A payer requires its portal for specific workflows: authorization submission, appeal filing, certain correspondence
• Anthem/Elevance is in your payer mix; the EDI gateway is unavoidable regardless of billing platform
• Your team runs manual eligibility or status checks across many payers and wants one login instead of separate portals
• The organization is a provider group rather than a third-party billing company and wants clearinghouse and RCM workflow on one platform

When you need Medi

Medi is built for billing companies whose core business is running revenue cycle work across multiple client practices. Pricing is $20 per client practice per month, with volume pricing available. Adding providers inside a practice never changes the fee.

The deciding question is where daily billing work actually happens. Availity's Essentials portal gives staff access to payer data: eligibility results, claim status, remittances, authorization decisions. It is not a place to organize that work across a book, route denial follow-up to the right specialist, track appeal deadlines, post ERAs with exception review, flag underpayments, manage patient payment plans, or report A/R aging across every client. Per an independent review of Availity's clearinghouse positioning, Availity "primarily ensures claims get filed and status updated, but does not actively manage downstream denial workflows."

The Availity Abrasion Index 2026, Availity's own research, found that 70 percent of denials are eventually overturned and paid, billions of dollars in avoidable administrative churn, per HIT Consultant's coverage. Better payer connectivity does not fix that churn. It takes a denial workflow where the right staff member picks up each denial at the right time with the right context, documents the appeal, and tracks resolution. That layer lives in the operating platform, not the clearinghouse or portal.

You need Medi when:

• You run a billing company with multiple client practices and manage all of them from one workspace
• Your team is organized by function, posters, denial leads, follow-up specialists, and needs cross-practice work queues
• You want ERA exception review with BPR footer checks, CARC/RARC codes in plain English, and line-level posting decisions on one screen
• You need appeal tracking, recovery items, and underpayment flags visible across the full book
• You want seven-year audit retention aligned with HIPAA Security Rule §164.312(b) and a signed BAA before any PHI workflow goes live
• Your clients already run an EHR and want a billing-only relationship, not a bundled EHR-plus-billing vendor

How they fit together in a real stack

Most billing companies with serious claim volume run both Availity and an operating platform, because the two layer rather than overlap.

The stack has three tiers:

• **Clearinghouse infrastructure** at the bottom: transaction routing, X12 EDI translation, payer connectivity. Medi uses Stedi here. For payers that require Availity's EDI gateway, Stedi routes through it automatically, so staff never manage that routing.
• **Payer portals** in the middle. Availity Essentials is the most common, but Cigna, Aetna, UnitedHealthcare, and Medicare's PECOS each have their own. Staff open these to chase eligibility that did not come back cleanly on a 271, submit an authorization a payer only accepts through its portal, or file an appeal that requires payer-specific forms.
• **The operating layer** on top: Medi. Claims enter Medi, get scrubbed, route to Stedi for submission, return as ERAs and status responses, move into denial queues, get worked by the right staff, and roll up into reporting for practice owners and managers.

Nothing in that stack is redundant. Availity provides payer-specific portal access and, for Anthem, the mandatory gateway. Stedi provides the programmable clearinghouse API. Medi provides the work surface, exception management, and reporting.

A separate case: billing companies that used Availity Essentials Pro or Plus as their primary billing platform. Those products fit provider-side RCM teams inside hospitals or large practices more than third-party billing companies with a diverse client book. The gaps that drive the switch are billing-company-specific: cross-practice workspaces, practice-scoped staff permissions, reporting that aggregates across clients, and billing-company ownership of payer enrollment records. Those gaps push toward a purpose-built platform however capable Availity's RCM tools are inside a single practice.

Where each one shines

Stedi vs Availity as the clearinghouse choice

Billing companies often ask whether choosing Stedi, Medi's clearinghouse, means losing the payer connections Availity provides. It does not, and the reason is architectural.

Availity grew as a payer-sponsored, portal-first network: providers log in and point-and-click their way through transactions, with the portal as the interface. Stedi is API-first. It accepts JSON API calls, translates them into HIPAA-compliant X12 EDI, routes to payers, and returns structured responses software can act on. Billing software on Stedi sends an eligibility request and gets a benefit result back in the same call, with no human clicking through a portal. That is what lets Medi surface eligibility, claim status, and ERA line items inside workflows instead of making staff log into a separate portal to fetch them.

Stedi connects to over 3,400 payers. Where a payer has named Availity its exclusive EDI gateway, Anthem being the clearest example, Stedi routes through that gateway. A billing company on Medi keeps Anthem connectivity; it just never sees the gateway layer, because Stedi handles it.

Direct Availity portal access still matters in a few cases, even with Stedi and Medi in the stack:

• A payer requires its Availity-hosted portal for prior authorization and will not accept electronic auth via EDI
• A denial appeal requires a formal reconsideration filed through the payer's Availity-hosted dispute module
• A payer publishes forms, letters, or digital correspondence only through Availity Essentials
• The team needs member data the payer surfaces only in its portal view, such as coordination-of-benefits history or member ID images

For those, staff open Availity Essentials alongside Medi: Availity as the payer-facing portal, Medi as the work surface where context, notes, and follow-up live. Choosing Stedi is a decision about transaction architecture; choosing Availity is a decision about which payers require its portal. Neither eliminates the other.

What should a billing company verify before choosing?

Work through these questions with your team before deciding how Availity fits and whether Medi is the right operating layer on top of it.

**Which payers in your book require Availity?** For authorization submission, certain appeals, and payer-specific correspondence, Availity Essentials may be mandatory for those payers whatever billing platform you use. Verify payer by payer before planning to drop portal access.

**Is Availity a clearinghouse, a portal, or both today?** Some billing companies route claims through Availity's clearinghouse and use its portal for status and auth. Others use it as a portal only and route EDI elsewhere. Knowing the role and the volume clarifies what changes when you move to a platform like Medi.

**Where does denial follow-up actually live?** If the team pulls denial data out of Availity's portal and works it in a spreadsheet or task list, that gap is the reason to evaluate an operating layer. The question is whether that work belongs in Availity's tools or a purpose-built denial workflow.

**How are multi-practice permissions managed?** Availity's portal grants access to payer transactions for the NPI/TIN combinations a user is credentialed under. It does not manage billing-company staff access across a client portfolio. If a poster needs four practices but not eight, that permission has to live somewhere.

**What does book-wide reporting look like?** Availity's reporting surfaces transaction data inside its portal. Billing-company reporting, A/R aging by practice, denial-rate trends across the book, collection rate by payer, month-over-month payment velocity, takes a layer that aggregates across every practice.

Other comparisons billing companies look at

Availity is a clearinghouse and payer-network layer, not a billing-company operating system. Buyers comparing it usually also weigh other clearinghouses (Claim.MD, Office Ally) for connectivity and separate billing platforms (Tebra, AdvancedMD, Medi) for the operating layer on top.

• Medi vs Claim.MD — direct clearinghouse alternative to Availity; more billing-focused workflow tooling.
• Medi vs Office Ally — free-for-Medicare clearinghouse with Practice Mate PM bundled.
• Medi vs Tebra — full PM platform; often paired with Availity for Anthem connectivity.
• Medi vs AdvancedMD — per-provider PM; transitioned to Waystar clearinghouse in 2025.
• Medi vs CollaborateMD — billing-company-focused PM with its own clearinghouse dependency.
• Medi vs PracticeSuite — multi-tenant billing-service PM.
• Medi vs Waystar — enterprise RCM and clearinghouse; competes with Availity at the enterprise tier.
• Best Availity alternatives for billing companies — the full field of options beyond the head-to-head pages.

The billing-company software evaluation guide explains how to evaluate clearinghouse versus operating-layer products in a billing-company stack.

Frequently asked questions

Is Availity a competitor to Medi?

Not directly. They serve different layers. Availity is payer-network infrastructure: it moves transactions between providers and health plans, offers a payer portal for status and prior auth, and for some payers functions as a mandatory EDI gateway. Medi is the operating layer: the claim workflow, denial management, ERA posting, reporting, and multi-practice management that billing-company staff handle every day. Many billing companies use both.

Does using Medi mean losing access to Availity's payer portal?

No. Availity Essentials is free and credential-based. A billing company can register staff for Essentials access for specific payer workflows, authorization submission, appeals on payer-specific forms, correspondence, while running daily operations in Medi. The two do not conflict.

If Anthem requires Availity as its EDI gateway, must billing companies use Availity as their clearinghouse?

No. The Anthem requirement is at the gateway level, not the billing-platform level. Anthem claims submitted through Stedi still route through Availity's gateway, because Stedi and Availity have that connection in place. Staff do not log into Availity to submit; they work in Medi, and the gateway routing happens automatically at the clearinghouse layer.

What does Availity Essentials cost, and how does that compare to Medi?

Availity Essentials (the base portal) is free because payers sponsor it. Essentials Plus is $25 per month, per Availity's published pricing. The EDI clearinghouse add-on has been cited at roughly $35 per month historically; confirm the current rate with Availity. Essentials Pro (paid RCM) is quote-based and not published.

Medi publishes its full schedule: $20 per client practice per month, with volume pricing available. Adding providers inside a practice never changes the fee. EDI is billed as consumed: $0.70 per claim with ERA included (line-blind; steps to $0.65 from 501-5,000 claims/month and $0.55 beyond 5,000), $0.25 per eligibility inquiry, $0.20 per claim status inquiry, and $1.50 per COB, discovery, or attachment transaction. Migration is free with a 12-month commitment, or $100 per practice (one-time, capped at $3,000) month-to-month; data export is always free with no termination fee.

What denial workflows does Availity offer, and where does Medi go further?

Availity's denial tooling, in Essentials Pro, covers two areas: predictive editing to catch likely denials before submission, and a queue to work claims already denied. Per Availity's denial prevention page, it includes practice-specific edit rules, state-specific rule sets, and claim analysis based on recent payer history. What it does not address is multi-practice orchestration: routing the right denial to the right specialist, tracking appeal deadlines across twenty practices, surfacing underpayment patterns that need contract analysis, or rolling up denial metrics across the whole portfolio. Medi's denial workflow covers that operational layer.

How current is this comparison?

Last reviewed 2026-06-07. Availity's packaging, gateway requirements, and feature scope change. The authoritative sources are availity.com/providers, availity.com/essentials, availity.com/essentials-pro, and availity.com/edi-clearinghouse. For Anthem's gateway requirement, see Anthem provider news. For Stedi, see stedi.com and stedi.com/pricing. Verify current arrangements directly before any migration or enrollment decision.