How Eligibility Verification Improves Billing

Short answer

Insurance eligibility verification does more than confirm that a patient has coverage. A complete 271 response from the payer carries copay amounts by service type, the base deductible and how much of it remains for the current benefit period, coinsurance percentage, out-of-pocket maximum, plan name, and coverage effective dates. Many basic eligibility checks surface only an active or inactive status and stop there. That gap matters because a biller who does not know the patient's $1,400 remaining deductible before submitting a claim has no chance to collect correctly at the point of service — and will find out only when the remittance arrives with a patient-responsibility balance the patient did not expect.

Benefits visibility shapes every downstream decision in the revenue cycle: which payer is billed, what the patient owes, whether the claim passes the payer's financial eligibility rules at adjudication, and how much the billing team can realistically collect before the visit. Eligibility-related denials — CO-22, CO-31, CO-32 — are among the most preventable denial types in medical billing. Real benefits data, not just a status flag, is what prevents them.

Medi connects real 271 benefit data to claim setup and denial follow-up so billing companies are working from the actual financial picture the payer returned, not a binary coverage signal.

Sources: CMS Health Plan Eligibility Benefit Inquiry and Response · CAQH 2024 Index Report · Experian Health 2025 State of Claims

---

What insurance eligibility verification actually checks

Eligibility verification is a real-time or batch electronic inquiry sent to a payer before or at the point of service. The practical question it answers is not just "does this patient have insurance?" but "what are this patient's financial obligations for this type of service, and does the plan cover what the provider intends to bill?"

The answer lives in the 271 response transaction. When a payer populates a 271 fully, it returns:

• **Copay amounts by service type** — primary care, specialist, urgent care, mental health, and other service categories each carry their own copay, which may differ substantially
• **Base deductible and remaining deductible** for the current benefit year
• **Coinsurance percentage** — the patient's share of covered charges after the deductible is met (80/20 is common, but plan-specific ratios vary)
• **Out-of-pocket maximum** and the amount already applied toward it
• **Plan name, group number, and member ID** — which matter when a patient card is outdated or the name on file does not match the payer's records
• **Coverage effective dates and termination dates** — which catch plans that have lapsed since the last visit
• **Benefit limitations by service type** — visit caps, authorization requirements, and plan-specific exclusions for categories like physical therapy or behavioral health

The challenge is that not every payer returns all of this, even when it exists in their system. A payer can satisfy the 271 transaction standard by confirming active status and returning very little financial detail. CAQH CORE's Eligibility and Benefits Data Content Rule (version EB.2.1) sets a floor for what CORE-certified payers must return for copay, deductible, and coinsurance — but certification is not universal, and even certified payers have discretionary service type categories where they may decline to return patient-responsibility figures.

That variability is one reason why the quality of eligibility verification differs so much across platforms and payer-clearinghouse connections.

---

Active/Inactive is not enough: the benefits that matter

A billing platform that reports "Active — Aetna" has done almost nothing useful. A biller standing at a check-in desk needs to know the specific copay to collect, not just that coverage exists. A billing company building claims needs to know how much of the deductible remains to understand what portion of the claim will land as patient responsibility. An operations leader reviewing front-end collection performance needs accurate patient-obligation data at the point of service to evaluate whether collections staff had the right information when they asked for payment.

Many basic eligibility checks return only that status flag and bury the rest of the 271 response in a raw data view — or discard it entirely. The financial implications show up three ways:

**Incorrect patient collections at check-in.** If the platform does not surface the deductible remaining, the front desk either collects nothing or collects a fixed estimate that may be significantly higher or lower than the actual patient responsibility. Collecting too little creates a downstream A/R problem. Collecting too much creates a refund liability and a patient complaint.

**Claim denials for financial eligibility reasons.** Payers adjudicate claims against the same benefit data the 271 returned. If a biller assumed full coverage because the eligibility check returned "Active" and the plan actually requires a prior authorization for that service type — something a complete 271 would have flagged — the claim returns a CO-197 (authorization missing). That is a preventable denial.

**Wrong payer billed.** The patient may carry more than one policy. The 271 response from each payer, when read together, tells the biller which plan is primary and which is secondary. A basic active/inactive check against one payer with no COB context leaves the billing team guessing at payer order and exposes claims to CO-22 denials when the paid-secondary payer rejects the claim because the primary should have gone first.

The benefit data the payer actually returns — copay, deductible remaining, coinsurance, coverage dates — is the working input for claim accuracy, patient communication, and denial prevention. An eligibility check that does not surface it is not doing the job.

---

How benefits visibility improves billing

Claim accuracy

The single most direct impact is routing the claim correctly. Knowing which payer is primary, whether the plan requires authorization for the service type being billed, and what the patient's plan type is (HMO, PPO, indemnity) directly affects how the claim is built. HMO claims that route to an out-of-network payer, or claims missing authorization that the 271 flagged as required, fail at adjudication for reasons that were visible before submission.

Benefits detail also catches stale coverage. A patient whose employer plan terminated two months ago will show as inactive on a real-time 271 check. That signal, surfaced at claim build rather than on the remittance, redirects the claim to the correct payer — often Medicaid, COBRA, or a marketplace plan the patient switched to without notifying the practice.

Fewer eligibility-driven denials

CO-31 (patient cannot be identified as insured) is one of the most avoidable denial codes in a practice's A/R. A real-time 271 inquiry before claim submission that returns a subscriber-not-found error is the earliest possible signal that the claim will fail on that same ground at the payer. That signal should stop the claim at build, trigger a demographics correction or payer change, and prevent a denial that otherwise takes three to four weeks to surface, research, and correct.

CO-22 (this care may be covered by another payer) is the direct consequence of incorrect COB. A platform that surfaces benefit data from multiple policies, shows coverage dates for each, and flags a COB sequence at claim setup reduces CO-22 volume at the source rather than treating it as a denial type to work reactively.

Per the Experian Health 2025 State of Claims survey, 68 percent of surveyed providers identify inaccurate or incomplete patient data at intake as a primary driver of claim denials. Eligibility verification that surfaces structured benefit detail rather than a status flag addresses a meaningful share of that problem before the claim leaves the practice.

Patient expectations and front-end collection

The financial conversation at check-in depends entirely on what the billing system knows about the patient's plan. A front desk staff member who can see "$35 copay, $800 remaining deductible, 20% coinsurance after deductible meets the deductible" can quote the patient a realistic estimate and collect against it. A staff member who sees only "Active — UnitedHealthcare" has nothing to quote.

The operational consequence of surfacing actual benefit data up front is that patient-responsibility balances collected at the point of service go up, and post-service patient billing for balances that could have been collected earlier goes down. Chasing patient balances by statement is significantly more expensive and has lower collection rates than collecting at the time of service against a known obligation.

Billing companies that manage multiple practices benefit from this at scale. A billing workflow that consistently puts copay, deductible remaining, and coinsurance in front of the collection conversation — at every practice, for every patient — reduces the patient-balance A/R that accumulates when front-end collection is guessing.

---

How the 270/271 works

The 270 is the eligibility and benefit inquiry. The 271 is the response. Both are X12 EDI transactions governed by HIPAA administrative simplification rules and maintained by X12. The transaction set reference for the 271 is 005010X279A1.

The 270 inquiry sends patient demographics (first name, last name, date of birth, member ID or Social Security Number), the payer's identification, the provider's NPI, the date of service or range being queried, and optionally a service type code that specifies which benefit category the inquiry covers. When no service type code is provided, the payer should return all available benefit information.

The 271 response is organized as a hierarchy: payer information at the top level, then subscriber information (the primary insured), then dependent information when the patient is covered as a dependent rather than the subscriber. Within each level, EB segments carry the actual benefit detail.

Each EB segment carries a code for the type of information it contains: active coverage, inactive coverage, copayment, coinsurance, deductible, and so on. Supporting segments carry dollar amounts for deductibles and out-of-pocket maximums (AMT segments), coverage effective and termination dates (DTP segments), and optional free-text payer notes (NTE segments).

Real-time 271 checks return a response in roughly one to three seconds. Batch checks process a list of patients overnight, which works well for appointments scheduled in advance. The practical standard is to batch the prior day for all scheduled visits, then run real-time at check-in for walk-ins, late additions, or any patient whose batch result flagged a question.

Per the CAQH 2024 Index Report, 96 percent of medical eligibility transactions are now electronic. A manual eligibility verification by phone costs about $6.78 per transaction; an electronic one costs about $0.34. The financial case for electronic verification is not close, and the benefit accuracy case is even stronger — a phone call to a payer IVR system often returns less structured detail than a full 271 inquiry.

One 271 pattern worth knowing: conflicting EB segments. A payer's eligibility system sometimes returns one segment showing active coverage for a service type and another showing inactive for the same service type. This happens when the payer's system draws coverage data from multiple sources that have not been reconciled. Billing software that does not surface this conflict leaves the biller with a false confidence in coverage that may not survive adjudication.

---

How Medi handles eligibility

Medi routes 270 inquiries through Stedi, the clearinghouse Medi uses for all EDI transactions, and surfaces the full 271 response — not just the active/inactive status — in the claim context where billers actually need it. Copay, remaining deductible, coinsurance, plan type, and coverage dates are displayed in the claim setup screen so that the benefit detail is visible when the claim is being built, not buried in a separate eligibility module.

Eligibility exceptions surface as actionable signals. A subscriber-not-found result from a real-time 271 check flags the claim before submission so a biller can correct demographics or switch payers rather than finding out via a CO-31 denial three weeks later.

Eligibility checks in Medi are priced per transaction at $0.20 each, with no monthly seat fee attached to eligibility access. Billing companies that run eligibility for multiple practices can see the cost per verification on their invoice alongside claim and ERA transaction volume. Full pricing is at /pricing.

What Medi does not do in this area:

• Guarantee that a 271 response captured all applicable benefit limits or exclusions — payer 271 completeness varies and Medi cannot control what a payer returns
• Replace payer-specific portal verification for Medicare Advantage plans or other plans with coverage conditions the 271 does not fully document
• Replace clinical judgment on whether a service meets plan medical necessity criteria

The honest framing is that structured benefit data at claim setup prevents the most preventable eligibility-driven denials. It does not eliminate adjudication uncertainty. Billers who need to see that data in the workflow — not in a separate module, not as a raw API response — are the audience Medi is built for.

See the Eligibility, COB, and Insurance Discovery Guide for the full workflow including coordination of benefits, denial codes, and insurance discovery. To see how this works in practice, request a demo.

---

Frequently asked questions

Does an active eligibility response guarantee the claim will be paid?

No. Active coverage on a 271 response means the patient has coverage with that payer as of the date of service. Payment still depends on whether the specific service is covered under the plan, whether the deductible has been met, whether medical necessity is satisfied, whether authorization was obtained when required, whether the claim was filed within the payer's timely filing window, and whether the claim routes to the correct primary payer under COB rules. An active status prevents the CO-177 eligibility denial. It does not prevent CO-22, CO-4, CO-50, or CO-197.

Why does benefits detail matter more than active/inactive status for preventing denials?

Because the denial codes that cost billing teams the most time — CO-22, CO-31, CO-32 — are driven by information problems that a status flag does not address. CO-31 (patient cannot be identified as insured) is caught by a 271 check that returns subscriber-not-found before the claim goes out. CO-22 (another payer should have paid first) is prevented when benefit data from both policies is visible at claim setup and payer order is set correctly. A basic check that returns only "Active" provides no signal on either of those. The benefit data is what makes the check actionable.

What is the difference between a real-time and a batch eligibility check?

A real-time check sends a 270 inquiry and gets a 271 response back in roughly one to three seconds. It is appropriate for walk-in patients, same-day appointments, or any situation where you need an answer immediately. A batch check submits a list of patients overnight and returns results before the practice opens, which works for a full day's scheduled appointments. Best practice is to use both: batch the prior day for all scheduled visits, then run real-time at check-in for late additions or any patient whose batch result returned an exception.

Which benefit details should a biller look at before submitting a claim?

At minimum: the remaining deductible (to understand what portion of the claim will route to patient responsibility), the copay for the specific service type being billed, the coinsurance percentage (to size patient responsibility after the deductible), coverage effective and termination dates (to confirm the visit date falls within the active coverage period), and the plan type (HMO, PPO) which affects network rules. For patients with more than one policy, COB detail — which plan is primary, which is secondary — determines how the claim routes. Authorization requirements flagged in the 271 response should also be verified before submission.

How often should eligibility be re-verified for established patients?

Coverage can change between a patient's last visit and the current appointment. Employer plan terminations, Medicaid eligibility shifts, and Medicare Advantage plan changes all happen mid-year without any notification to the practice. The practical standard is to verify at scheduling, run a batch check the day before the visit, and run a real-time check at check-in for any patient whose batch result returned an exception or whose last visit was more than 30 days prior. Per CAQH 2024 Index data, the cost of an electronic re-verification is about $0.34, which makes pre-visit re-runs economically straightforward at any practice volume.

---

Sources: CMS Health Plan Eligibility Benefit Inquiry and Response · X12 271 Transaction Set Reference (005010X279A1) · CAQH 2024 Index Report · Experian Health 2025 State of Claims · Stedi 270/271 EDI Reference