Medi vs Availity

Availity and Medi occupy different layers of the billing-company technology stack. Availity is a payer-provider network and clearinghouse — the infrastructure that carries transactions between providers and health plans. Medi is the billing-company operating layer that sits on top of that infrastructure, where staff run daily work across client practices. For many billing companies, the question is not Availity or Medi but rather how the two fit together, because they solve different problems.

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

Short answer

Availity describes itself as "the nation's largest health information network," processing over 13 billion administrative and clinical transactions annually across 3.4 million connected providers and 95 direct payer connections, per Availity's clearinghouse page. Its core role is transaction routing — eligibility checks, claim submission, claim status, remittance processing, and prior authorization — moving data between providers and payers through a single credentialed connection instead of dozens of payer-specific portals. Several major payers, including the entire Anthem/Elevance family, have named Availity their exclusive EDI gateway, meaning any trading partner submitting claims to Anthem must route through Availity regardless of which billing platform they use.

Medi is the billing-company operating layer that runs on top of clearinghouse infrastructure. It handles multi-practice workspace management, claim building and scrubbing, ERA review and exception handling, denial and appeal workflows, payment posting, underpayment detection, reporting across the full book of business, 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 need a separate clearinghouse contract.

The short answer: a billing company may use Availity and Medi simultaneously, with Availity handling payer-network connectivity for specific payer transactions and Medi handling every workflow that surrounds those transactions.

When you need Availity

Availity fills three distinct roles, and understanding which one applies to your situation matters before any evaluation conversation.

The first is the free payer portal. Availity Essentials is payer-sponsored — health plans subsidize access so their provider networks can reach them without subscription fees. BCBS plans across most states, Anthem, Aetna, Cigna, UnitedHealthcare, and dozens of regional plans treat Availity as a primary portal for eligibility lookups, prior authorization submissions, claim status checks, and digital correspondence. A billing company that needs to check eligibility for a single visit or submit a one-off appeal for a payer that requires Availity access will use Essentials regardless of what other software is in the stack. The portal is free at the baseline; no billing-company subscription decision is needed.

The second role is EDI gateway for specific payers. Anthem (Elevance Health) has designated Availity as its exclusive EDI gateway, per Anthem provider announcements. All new submitters routing claims to any Anthem affiliate must send them through Availity's clearinghouse layer, not directly to Anthem's systems. This is a connectivity requirement, not an optional feature. Any clearinghouse or billing platform submitting to Anthem is routing through Availity at some point in the chain.

The third role is the paid RCM product. Availity Essentials Pro and Availity Essentials Plus add capabilities beyond the free portal: AI-powered predictive claim editing that checks claims against recent payer history before submission, batch eligibility, denial management queues, advanced analytics, and integrated remittance tools. These are sold to provider organizations and hospital systems that want to consolidate payer interaction inside one platform without buying a separate billing system. Availity Essentials Pro targets this segment explicitly, 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 claim status checks across multiple payers and wants one login instead of separate payer portals
• The organization is a provider group (not a third-party billing company) that wants clearinghouse and RCM workflow on one Availity platform

When you need Medi

Medi is built for billing companies that manage revenue cycle work across multiple client practices as their core business. The platform fee is $300 per month, flat, for the billing company. Client practices, providers, and users are unlimited under that fee, so the cost structure does not change when the book grows from twenty to fifty providers next quarter.

The practical 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. What it does not provide is a place to organize that work across a multi-practice 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 the full book of clients. 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 report — found that 70 percent of denials are eventually overturned and paid, representing billions of dollars in avoidable administrative churn, per HIT Consultant's coverage of the report. That churn does not fix itself through better payer connectivity. It requires a systematic denial workflow: a queue where the right staff member picks up each denial at the right time, with the right context, and can document the appeal and track the resolution. That layer sits in the billing-company operating platform, not in the clearinghouse or payer portal.

You need Medi when:

• You run a billing company with multiple client practices and need to manage work across all of them from a single 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 use an EHR and want a billing-only operating relationship, not a bundled EHR-plus-billing vendor

How they fit together in a real billing-company stack

Most billing companies with serious claim volume end up with both Availity and a billing-company operating platform in the stack, because the two tools do not overlap — they layer.

The architecture looks like this. At the bottom sits clearinghouse infrastructure: transaction routing, X12 EDI translation, payer connectivity. Medi uses Stedi for this layer. For payers that require Availity's EDI gateway (Anthem, and any plan that has named Availity as its exclusive gateway), Stedi routes through Availity automatically; the billing-company staff does not need to manage that routing separately. At the middle layer sit payer portals — Availity Essentials is the most common, but Cigna, Aetna, UnitedHealthcare, and Medicare's PECOS each have their own. Billing-company staff open those portals to check eligibility details that did not come back cleanly on a 271, submit an authorization that a payer only accepts through its portal, or file a formal appeal that requires payer-specific forms. At the top sits the billing-company operating layer: Medi. Claims enter Medi, get scrubbed, route to submission via Stedi, come back as ERAs and claim status responses, move into denial queues, get worked by the right staff, and get reported to practice owners and billing-company managers.

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

A third configuration exists for billing companies that previously used Availity Essentials Pro or Essentials Plus as their primary billing platform. Those products are designed more for provider-side RCM teams inside hospitals or large practices than for third-party billing companies managing a diverse client book. The billing-company-specific gaps — cross-practice workspace management, practice-scoped permissions for staff, reporting that aggregates across clients, billing-company ownership of payer enrollment records — typically push billing companies toward a purpose-built platform regardless of how capable Availity's RCM tools are within a single practice context.

Where each one shines

What about Stedi vs Availity as the clearinghouse choice?

Billing companies often ask whether choosing Stedi (Medi's clearinghouse) means losing access to payer connections that Availity provides. The practical answer is more nuanced than "one clearinghouse vs another."

Availity and Stedi approach clearinghouse infrastructure differently. Availity grew as a payer-sponsored, portal-first network where providers log in to a web portal and use point-and-click workflows to submit transactions. The portal is the interface. Stedi is API-first — it accepts modern JSON API calls, translates them into HIPAA-compliant X12 EDI, routes to payers, and returns structured responses that software can act on directly. Billing software built on Stedi sends an eligibility request via API and gets a benefit result back in the same call, without a human manually clicking through a portal. That architecture is what enables Medi to surface eligibility results, claim status updates, and ERA line items directly inside workflows rather than requiring staff to log into a separate portal to retrieve them.

For payer reach, Stedi connects to over 3,400 payers. Where a payer has named Availity as its exclusive EDI gateway — Anthem being the clearest example — Stedi routes to that payer through Availity's gateway. A billing company using Medi does not lose Anthem connectivity; it just does not see the Availity gateway layer because Stedi handles it.

The cases where direct Availity portal access still matters, even with Stedi and Medi in the stack:

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

For those workflows, staff open Availity Essentials alongside Medi — using Availity as the payer-facing portal and Medi as the work surface where context, notes, and follow-up live.

Choosing Stedi as the clearinghouse backbone is a decision about transaction architecture, not payer access. Choosing Availity as a portal is a decision about which payers require it. Neither choice eliminates the other.

What should a billing company verify before choosing?

Before deciding how Availity fits into the stack — and whether Medi is the right operating layer on top of it — work through these questions with your team.

Which payers in your book require Availity for specific workflows? For authorization submission, certain appeals, and payer-specific correspondence, Availity Essentials may be mandatory for those payers regardless of what billing platform is in use. Verify this payer by payer before planning to remove portal access entirely.

Is Availity currently serving as a clearinghouse, a portal, or both? Some billing companies route claims through Availity's clearinghouse while also using its portal for status and auth. Others use Availity only as a portal while routing EDI through a different clearinghouse. Knowing which role it plays — and at what volume — clarifies what changes when switching to a platform like Medi.

Where does the denial follow-up work actually live today? If the team is pulling denial information out of Availity's portal and working it in a spreadsheet or a separate task list, that gap is the reason to evaluate a billing-company operating layer. The question is whether that work belongs in Availity's tools or in a purpose-built denial workflow.

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

What does reporting across the book look like today? Availity's reporting tools surface transaction data within their portal. Billing-company-level reporting — A/R aging by practice, denial rate trends across the book, collection rate by payer, month-over-month payment velocity — typically requires a separate layer that aggregates data across all practices.

Other comparisons billing companies look at

Availity is a clearinghouse and payer-network layer rather than a billing-company operating system. Buyers comparing Availity usually also consider 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.

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. Availity and Medi serve different layers of the billing workflow. Availity is payer-network infrastructure: it moves transactions between providers and health plans, provides a payer portal for status and prior auth, and for some payers functions as a mandatory EDI gateway. Medi is the billing-company operating layer: it handles the claim workflow, denial management, ERA posting, reporting, and multi-practice management that billing-company staff do 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 Availity Essentials access for specific payer workflows — authorization submission, appeals via payer-specific forms, payer correspondence — while running daily billing operations in Medi. The two tools do not conflict.

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

The Anthem requirement is at the EDI gateway level, not the billing-platform level. Billing companies submitting Anthem claims through Stedi still route through Availity's gateway because Stedi and Availity have that connection in place. The billing-company staff do not log into Availity to submit claims — 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. Availity Essentials Pro and Essentials Plus are paid products with pricing available on request from Availity, not published. Medi's pricing is transparent: $300 per month for the billing-company platform, plus EDI usage billed as consumed — $0.25 for the first claim line item, $0.20 for each additional line, $0.20 per paid ERA line, and $0.20 per eligibility or claim status inquiry. EDI usage at a typical 50-provider book runs roughly $1,300 to $1,700 per month, putting all-in platform cost in the range of $1,600 to $2,000 per month.

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

Availity's denial tooling — available in Essentials Pro — focuses on two areas: predictive editing to catch likely denials before submission, and a denial management queue to work claims that have already been denied. Per Availity's denial prevention page, the tools include practice-specific edit rules, state-specific rule sets, and AI-powered claim analysis based on recent payer history. What Availity's denial tools do not address is multi-practice denial orchestration: routing the right denial to the right specialist, tracking appeal deadlines across a book of twenty practices, surfacing underpayment patterns that require contract analysis, or rolling up denial metrics across the full billing-company portfolio. Medi's denial workflow covers that operational layer.

How current is this comparison?

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