How Eligibility Verification Improves Billing

Short answer

Insurance eligibility verification should do more than confirm a patient has coverage. A complete 271 response from the payer carries copay amounts by service type, the deductible and how much of it remains for the current benefit period, the coinsurance percentage, the out-of-pocket maximum, the plan name, and coverage effective dates. Many basic eligibility checks return only active or inactive status and stop there. That gap costs money: a biller who does not know a patient has $1,400 of deductible remaining cannot collect correctly at check-in, and finds out only when the remittance lands with a patient-responsibility balance no one quoted.

Real benefit data drives every downstream decision in the revenue cycle: which payer is billed, what the patient owes, whether the claim clears the payer's financial eligibility rules at adjudication, and how much the team can collect before the visit. Eligibility denials like CO-22, CO-31, and CO-32 are among the most preventable in medical billing, and structured benefit data is what prevents them. A status flag does not.

Medi surfaces the full 271 in claim setup and denial follow-up, so billing companies work from the financial picture the payer actually returned.

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

---

What 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 real question is not "does this patient have insurance?" but "what does this patient owe for this service, and does the plan cover what the provider intends to bill?"

The answer lives in the 271 response. A fully populated 271 returns:

• **Copay amounts by service type.** Primary care, specialist, urgent care, and mental health each carry their own copay, and they often differ.
• **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; plan 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 and termination dates**, which catch plans that lapsed since the last visit.
• **Benefit limitations by service type**: visit caps, authorization requirements, and exclusions for categories like physical therapy or behavioral health.

Not every payer returns all of this, even when the data exists in their system. A payer satisfies the 271 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 decline to return patient-responsibility figures. That variability is why eligibility quality differs so much across platforms and payer-clearinghouse connections.

---

Active/inactive is not enough

A platform that reports "Active, Aetna" has done almost nothing useful. The biller at check-in needs the specific copay to collect. The biller building the claim needs the remaining deductible to know what portion lands as patient responsibility. The operations leader reviewing collection performance needs the patient-obligation data staff had when they asked for payment. A bare status flag answers none of those.

Many basic checks return only that flag and bury the rest of the 271 in a raw data view, or drop it entirely. The cost shows up three ways.

**Wrong amount collected at check-in.** Without the remaining deductible, the front desk collects nothing or guesses a fixed estimate. Collect too little and it becomes an A/R problem; collect too much and it becomes a refund and a patient complaint.

**Denials for financial eligibility reasons.** Payers adjudicate against the same benefit data the 271 returned. If a biller assumes full coverage off an "Active" result and the plan actually requires prior authorization for that service type, the claim comes back CO-197 (authorization missing). A complete 271 would have flagged the requirement first.

**Wrong payer billed.** A patient may carry more than one policy. Read together, the 271 from each payer tells the biller which plan is primary and which is secondary. A single active/inactive check with no COB context leaves payer order to guesswork and exposes claims to CO-22 when the secondary rejects a claim the primary should have paid first.

Copay, remaining deductible, coinsurance, and coverage dates are the working inputs for claim accuracy, patient communication, and denial prevention. A check that does not surface them is not doing the job.

---

How benefit data improves billing

Claim accuracy

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

Benefit detail also catches stale coverage. A patient whose employer plan terminated two months ago shows inactive on a real-time 271. Caught at claim build instead of on the remittance, that redirects the claim to the right payer, often Medicaid, COBRA, or a marketplace plan the patient switched to without telling the practice.

Fewer eligibility-driven denials

CO-31 (patient cannot be identified as insured) is one of the most avoidable codes in a practice's A/R. A real-time 271 that returns subscriber-not-found is the earliest possible signal the claim will fail on the same ground at the payer. It 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 rework.

CO-22 (this care may be covered by another payer) is the direct result of incorrect COB. Surfacing benefit data from multiple policies, showing coverage dates for each, and flagging the COB sequence at claim setup cuts CO-22 volume at the source instead of working it as a denial after the fact.

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

Patient expectations and front-end collection

The financial conversation at check-in depends entirely on what the system knows about the plan. Staff who can see a $35 specialist copay, $800 remaining deductible, and 20 percent coinsurance after the deductible can quote a realistic estimate and collect against it. Staff who see only "Active, UnitedHealthcare" have nothing to quote.

Surface the benefit data up front and more patient responsibility gets collected at the point of service, so less of it has to be chased afterward. Collecting by statement costs more and recovers less than collecting at the time of service against a known obligation.

Billing companies that run multiple practices gain this at scale. A workflow that puts copay, remaining deductible, and coinsurance in front of every collection conversation, at every practice, shrinks the patient-balance A/R that piles up when the front desk 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 (name, date of birth, member ID or SSN), the payer ID, the provider's NPI, the date of service or range, and optionally a service type code that scopes the inquiry to one benefit category. With no service type code, the payer should return all available benefit information.

The 271 is a hierarchy: payer information at the top, then subscriber (the primary insured), then dependent information when the patient is covered as a dependent. Within each level, EB segments carry the benefit detail. Each EB segment carries a code for what it contains: active coverage, inactive coverage, copayment, coinsurance, deductible, and so on. Supporting segments carry the dollar amounts for deductibles and out-of-pocket maximums (AMT), coverage effective and termination dates (DTP), and free-text payer notes (NTE).

Real-time 271 checks return in roughly one to three seconds. Batch checks process a patient list overnight, which suits appointments booked in advance. The working 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 verification by phone costs about $6.78; an electronic one costs about $0.34. The cost case is decisive, and the accuracy case is stronger still, since a payer IVR call usually returns less structured detail than a full 271.

One pattern worth knowing: conflicting EB segments. A payer's system sometimes returns active coverage for a service type in one segment and inactive for the same service type in another, when its coverage data comes from sources that have not been reconciled. Software that hides the conflict hands the biller 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, and surfaces the full 271, not just active/inactive, in the claim context where billers need it. Copay, remaining deductible, coinsurance, plan type, and coverage dates show in the claim setup screen, so the benefit detail is in view while the claim is built rather than parked in a separate eligibility module.

Eligibility exceptions surface as actionable signals. A subscriber-not-found result from a real-time 271 flags the claim before submission, so a biller can fix demographics or switch payers instead of learning it from a CO-31 denial three weeks later.

Eligibility checks are priced per transaction at $0.25 each, with no monthly seat fee for eligibility access. Billing companies running eligibility across practices see the cost per verification on their invoice next to claim and ERA volume. Full pricing is at /pricing.

What Medi does not do here:

• Guarantee a 271 captured every applicable benefit limit or exclusion. Payer 271 completeness varies, and Medi cannot control what a payer returns.
• Replace payer-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 the plan's medical necessity criteria.

The honest framing: structured benefit data at claim setup prevents the most preventable eligibility-driven denials. It does not erase adjudication uncertainty. Billers who need that data in the workflow, not in a separate module and not as a raw API response, are who 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 it 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 means the patient has coverage with that payer as of the date of service. Payment still depends on whether the service is covered, whether the deductible has been met, whether medical necessity is satisfied, whether required authorization was obtained, whether the claim was filed within the timely filing window, and whether it routes to the correct primary payer under COB. Active status prevents the CO-177 eligibility denial. It does not prevent CO-22, CO-4, CO-50, or CO-197.

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

Because the codes that cost billing teams the most time (CO-22, CO-31, CO-32) come from information problems a status flag does not touch. CO-31 (patient cannot be identified as insured) is caught by a 271 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 check that returns only "Active" gives no signal on either. 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 and gets a 271 back in roughly one to three seconds, which suits walk-ins, same-day appointments, or any case that needs an answer now. A batch check submits a patient list overnight and returns results before the practice opens, which suits a full day of scheduled appointments. Use both: batch the prior day for 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 check before submitting a claim?

At minimum: remaining deductible (what portion routes to patient responsibility), the copay for the specific service type, the coinsurance percentage (to size responsibility after the deductible), coverage effective and termination dates (to confirm the visit date is in the active period), and plan type (HMO, PPO), which affects network rules. For patients with more than one policy, COB detail decides which plan is primary. Any authorization requirement flagged in the 271 should be verified before submission.

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

Coverage changes 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 with no notice to the practice. Verify at scheduling, batch the day before the visit, and run real-time 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, an electronic re-verification costs about $0.34, which makes pre-visit re-runs straightforward at any 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