Eligibility, COB, and Insurance Discovery Guide

Short answer

A useful eligibility check returns far more than whether a patient is active or inactive. A complete 271 response carries copay amounts, base and remaining deductible, coinsurance percentage, plan name, group number, effective dates, and service-type limitations. Coverage of benefits (COB) determines which payer is primary when the patient carries more than one policy, and getting that order wrong is the single fastest path to a CO-22 denial. Insurance discovery is the fallback when the patient has no card or when a prior self-pay account might have had coverage all along. Medi connects all three signals to claim setup, payer routing, and denial follow-up. None of them guarantee payment — adjudication still depends on coding, medical necessity, authorization, and timely filing — but working eligibility correctly prevents the most preventable denials in the practice's revenue cycle.

CMS publishes the administrative simplification framework for Health Plan Eligibility Benefit Inquiry and Response and Coordination of Benefits. CAQH CORE publishes operating rules that set the floor for what CORE-certified payers must return. The CAQH 2024 Index Report found that a manual eligibility transaction costs about $6.78, an electronic one about $0.34 — the case for real-time electronic verification is not close.

What a good eligibility response actually contains

This is the most important section for billing companies evaluating software. Knowing a patient is "active" is almost useless at the point of claim build. The question a biller actually needs answered is: what is this patient's financial responsibility for this service type, and does anything about the plan limit or exclude this specific procedure?

The 271 transaction, when a payer populates it correctly, answers that. It carries copay amounts by service type (primary care, specialist, urgent care), the base deductible and how much of it remains for the current benefit period, the coinsurance percentage (for example, 80/20 after the deductible), out-of-pocket maximum and how much remains, plan name and group number, coverage effective and termination dates, and benefit limitations or exclusions that apply to specific service type codes.

The problem is that payers vary enormously on how much of this they actually return. A payer can technically satisfy the 271 transaction standard by confirming active status and returning almost no financial detail. CAQH CORE's Eligibility and Benefits Data Content Rule (version EB.2.1) establishes that CORE-certified payers must return base and remaining deductible, copay, and coinsurance for each required service type code — but not every payer is CORE-certified, and even certified payers have discretionary STCs (service type codes) where they may elect not to return patient responsibility figures.

This is the gap that experienced billers recognize and new software buyers miss. A platform that displays "Active — United Healthcare" has done almost nothing. A platform that surfaces "$35 copay, $1,200 deductible remaining, 20% coinsurance after deductible, benefit period through December 31" has done the work that prevents a surprise denial, a patient dispute, and a collections problem three months later.

Billers who have worked on Availity's portal understand this concretely. Availity's eligibility and coverage tool returns structured benefit detail — fixed copay by service category, deductible remaining, coinsurance — not just a status flag. That is why experienced billers prefer it to platforms that tunnel the 271 response through a basic active/inactive display. The underlying data exists in the 271 transaction set; the question is whether the software surfaces it or buries it.

Per the 2025 Experian Health State of Claims survey, 68 percent of surveyed providers identify inaccurate or incomplete patient data at intake as a primary driver of claim denials. A meaningful share of that problem is not bad front-desk work — it is software that does not surface the benefit detail that the 271 already returned.

The 270/271 transaction in plain English

The 270 is the eligibility and benefit inquiry. The 271 is the response. Both are X12 EDI transactions governed by the 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 service date range being queried, and optionally a service type code specifying which benefit category the inquiry covers. If no service type code is provided, the payer should return all available benefit information.

The 271 response is organized as a hierarchy: payer information, then subscriber (the primary insured) information, then dependent information if the patient is a dependent rather than the subscriber. Within the subscriber or dependent loop, the EB segments carry the actual benefit detail.

Each EB segment in the 271 carries:

• EB01: a code for the type of information (1 = active coverage, 6 = inactive, I = copayment, A = coinsurance, C = deductible, and so on)
• EB02 and EB03: codes for the coverage level and service type
• EB04: the insurance type code (HMO, PPO, indemnity, etc.)
• EB06, EB07: the monetary amount or percentage associated with the benefit
• EB08: the coinsurance percentage

Supporting segments carry additional detail: AMT segments hold dollar amounts for deductibles and out-of-pocket maximums, DTP segments carry effective dates and termination dates, and NTE segments carry free-text notes the payer optionally includes.

What payers frequently omit or return inconsistently: out-of-network benefit detail (many payers return only in-network figures), benefit limitations for mental health or physical therapy visit counts, prior authorization requirements by service type, coordination of benefits information about other coverage the payer has on file for that member, and plan-specific exclusions. A payer companion guide — published by most large payers and available from clearinghouses like Stedi — describes what each payer includes and omits from its 271 responses.

A common 271 error worth flagging is a conflicting EB segment: one segment returns active coverage, another returns inactive for the same service type. This happens when the payer's eligibility system has coverage data from multiple sources that haven't been reconciled. Billing software that does not detect and surface this conflict leaves the biller with a false confidence in coverage that may not survive adjudication.

Real-time 271 checks return a response in roughly one to three seconds. Batch checks process a list of patients overnight and are appropriate for appointments scheduled in advance. The best practice is a hybrid: batch the day prior for all scheduled visits, then run real-time at check-in for walk-ins, late additions, or any patient whose batch result raised a question. Per the 2024 CAQH Index, 96 percent of medical eligibility transactions are now electronic; the savings versus manual phone verification are about $6.44 per transaction.

Coordination of Benefits in practice

COB determines which payer pays first when a patient carries more than one policy. Getting the order right is not optional — it is a claim validity requirement, and most payers will return CO-22 rather than pay a claim where they have reason to believe another payer is primary.

The payer order rules for most commercial plans follow several standard frameworks:

The birthday rule applies when dependent children are covered under both parents' employer plans. The plan of the parent whose birthday falls first in the calendar year (by month and day, not birth year) is primary for the child. If both parents share the same birthday, the plan that has covered the parent for longer is primary. The gender rule — where the father's plan is always primary — has been phased out by most major payers but persists in some older plan documents; when one plan uses the birthday rule and another uses the gender rule, the gender rule controls.

For Medicare, the Medicare Secondary Payer (MSP) framework takes over. MSP is federal law and preempts state law and private contract terms. Per the CMS MSP fact sheet MLN006903, Medicare is secondary in these situations:

• Working aged: the patient is 65 or older, is covered through a current employer's group health plan, and the employer has 20 or more employees
• Disabled: the patient is under 65, disabled, covered through current employment, and the employer has 100 or more employees
• ESRD (end-stage renal disease): the patient is in the first 30 months of Medicare entitlement — employer size does not matter during the 30-month coordination period
• Workers' compensation: the illness or injury is work-related
• Liability and no-fault insurance: a third party is responsible for the incident

Billing Medicare as primary when MSP applies is not just a denial — it is a recoverable overpayment. CMS can demand repayment within 60 days of a settlement or payment, and civil money penalties for MSP reporting failures can reach $1,000 per day per record. As of 2026, CMS is auditing 250 MSP records per quarter, a meaningful enforcement escalation from prior years.

The most common COB failure modes in practice are: the patient has changed employers mid-year and the prior group plan is still on file; both parents' employer plans cover a child but registration captured only one; Medicare is primary on a claim where MSP rules make it secondary because the employer has only 18 employees (under the 20-employee threshold); and secondary claims are submitted without the primary payer's EOB attached, which causes the secondary to deny without even reviewing the claim.

COB workflows that work well maintain a structured COB questionnaire at registration, enforce coverage effective dates so a terminated plan cannot silently remain primary, and create an aging queue for secondary submissions so that COB delays do not quietly push secondary claims past timely filing deadlines.

Common eligibility-related denials and how to prevent them

These four CARC codes account for most of the eligibility and COB denial volume that billing companies manage. Each has a distinct cause and a distinct prevention pathway.

CO-22 deserves particular attention because it is the second-order consequence of every COB mistake made upstream. Per FCSO Medicare CO-22 guidance, the prevention strategy for CO-22 has three anchors: correct payer order established at registration, primary adjudication proof attached when billing secondary, and structured resubmission workflows that handle the cross-claim timing correctly.

CO-31 and CO-32 are overwhelmingly preventable with real-time 271 inquiry before or at the point of service. A subscriber-not-found error from a 271 check is the earliest possible signal that a claim submitted to that payer will return CO-31. That signal should stop the claim at claim build, not after submission.

CO-177 is less predictable because it depends on payer-specific eligibility rules that are not always fully documented in the 271 response. Medicare Advantage plans in particular have plan-specific coverage conditions, benefit periods, and service area restrictions that the 271 may not fully surface. For MA, the practical mitigation is to verify coverage against the specific plan's member eligibility portal or through a payer-specific eligibility check rather than relying on a generic 271 inquiry.

Insurance discovery: when it matters

Insurance discovery is a separate query from a standard 271 eligibility check. Where a 271 inquiry asks a specific payer "is this patient your member?", insurance discovery sends a patient's demographic data across a network of payers and databases to find whether any active coverage exists, without knowing the payer in advance.

The scenarios where insurance discovery adds real value:

A patient presents without an insurance card, or presents as self-pay but seems to have employer coverage based on their demographic profile. A standard 271 inquiry has nowhere to go. Insurance discovery fans the inquiry across probable payers — often 13 to 16 real-time checks against major carriers — and returns any matches with subscriber and benefit details and a confidence level. Per Stedi's insurance discovery documentation, results take up to 120 seconds, much slower than a real-time 271 check, so it is a workflow-specific tool rather than a point-of-service lookup.

A prior self-pay account or bad-debt account might have had Medicaid coverage at the time of service that was never captured. Post-service Medicaid discovery tools — including vendors like Infinx and ZOLL — perform continuous monitoring of patient accounts and flag when retroactive Medicaid approvals are posted. Industry data cited by FinThrive suggests that insurance discovery tools identify active coverage for more than 40 percent of presumed self-pay patients at some facilities, with retroactive Medicaid accounting for around 5 percent of uninsured patients.

A claim returned CO-22 and the billing company suspects a secondary policy exists but the patient has not provided the details. Insurance discovery can find the secondary plan faster than repeated calls to the patient.

Important limits on insurance discovery: it returns active coverage for the date of service range provided; it cannot return retroactive or future coverage through standard checks. It will not reliably find dental-only or vision-only plans. And finding a policy does not determine primacy — a separate COB check is still required to establish payer order.

Vendors like Waystar (which acquired Recondo Technology's eligibility and patient-access capabilities), Infinx, and Inovalon operate insurance discovery networks. What distinguishes them is the breadth of the payer network they query, their match rates for patients with incomplete demographic data, and whether their discovery results flow directly into the billing workflow or require manual reentry.

Where does Medi fit?

Medi connects eligibility signals, COB context, and insurance discovery leads to the revenue-cycle work that depends on them: claim setup, payer routing, and denial follow-up. The Stedi clearinghouse handles the 270/271 EDI transactions; Medi stores the response, surfaces the benefit detail in the claim context, and ties eligibility exceptions to the denial queue when a CO-22, CO-31, CO-32, or CO-177 comes back.

For billing companies, the value of this connection is operational. An eligibility check that returns as a raw API response and disappears into a log is not useful. An eligibility check that surfaces a $1,500 remaining deductible in the claim setup screen, flags a COB mismatch before submission, and ties a CO-31 denial back to the member ID verified at service — that is useful.

Medi does not:

• Guarantee payment based on an active eligibility response
• Guarantee that a 271 response captured all applicable benefit limits or exclusions
• Guarantee that MSP or COB order is always determinable from available plan data
• Replace clinical judgment on whether a service meets plan medical necessity criteria

The honest framing for billing-company buyers is that eligibility, COB, and insurance discovery work reduces the uncertainty that causes preventable denials. What a biller actually needs is the benefit detail (not just active/inactive), the COB structure visible in claim setup, and eligibility exceptions routed to a denial queue when they produce a denial — not a standalone eligibility module that lives outside the revenue cycle workflow.

See billing-company operations for the broader operational context and request a demo to see how eligibility data connects to claim setup and denial follow-up in practice.

What should buyers verify in an eligibility workflow demo?

A demo that only shows the eligibility check returning "Active" has not shown you anything worth evaluating. These are the specific things to verify:

• Does the 271 response display structured benefit detail — copay by service type, base deductible, remaining deductible, coinsurance percentage — or only active/inactive status?
• Can the biller see benefit detail in the context of claim setup, or is eligibility a separate module with no connection to the claim?
• How does the system handle a conflicting 271 response, where one EB segment returns active and another returns inactive for the same service type?
• Can the system run batch eligibility the day prior for all scheduled patients, and flag exceptions for review before those patients arrive?
• When a 271 returns a subscriber-not-found error, does the system surface it as an actionable task before claim submission?
• Does the COB workflow distinguish payer order, capture the primary EOB, and tie secondary submission to the primary's remittance?
• When a CO-22 or CO-31 denial arrives, does the denial queue link back to the eligibility check that ran before or at service?
• Is insurance discovery available for patients who present without insurance information, and do discovery results flow into the claim setup workflow or require manual entry?
• Which payers are supported for real-time 271 checks, and how current is the payer network?
• How are eligibility responses stored for audit — can a biller retrieve exactly what was returned on the date of service?

See the denial management workflow guide for how eligibility-related denials fit into the broader denial triage and follow-up workflow.

Frequently asked questions

Does an active eligibility response mean 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 patient has met the deductible, whether medical necessity is satisfied, whether authorization is required, whether the claim is billed to the correct payer in the correct order (COB), whether the claim is filed within the payer's timely filing window, and whether the claim passes adjudication. An active status prevents the CO-177 denial; it does not prevent CO-22, CO-4, CO-50, or CO-197.

What is the difference between a 270/271 transaction and an insurance discovery check?

A 270/271 asks a specific payer whether the patient is a member. You have to know the payer to run it. An insurance discovery check sends demographics across a network of payers to find whether any active coverage exists when you do not know the payer. Discovery checks are slower (up to 120 seconds) and less reliable for incomplete demographics, but they fill the gap when a patient presents without insurance information. Both are distinct from COB, which determines payer order among known plans.

What is the birthday rule and when does it apply?

The birthday rule determines primary coverage for dependent children covered by both parents' employer plans. The plan of the parent whose birthday (month and day, not birth year) falls first in the calendar year is primary. It applies only to situations where the child is a dependent on two different employer-sponsored group plans. It does not apply to Medicare, Medicaid, workers' compensation, or liability situations. Some older plan documents still use the gender rule (father's plan is always primary); when plans conflict between birthday and gender rules, the gender rule typically controls for that plan pairing.

When is Medicare secondary under MSP rules?

Medicare is secondary in five main situations: working aged (patient is 65 or older, covered by an employer plan, employer has 20 or more employees); disabled (patient is under 65, covered by an employer plan, employer has 100 or more employees); ESRD (during the first 30 months of Medicare eligibility regardless of employer size); workers' compensation (for the work-related condition); and liability or no-fault (for the accident-related condition). Federal law governs MSP; a private plan cannot contract its way out of primary responsibility when MSP rules apply. Per CMS, billing Medicare as primary when it is secondary creates a conditional payment obligation that CMS will recover.

What does CO-22 actually require to fix?

CO-22 means the payer believes another plan should have paid first. The resolution path depends on the actual situation: if the claim was submitted to the wrong primary payer, correct and resubmit to the correct primary payer, then submit the secondary claim with the primary EOB attached; if the payer's COB data is outdated (they have a prior employer plan on file that has terminated), contact the payer's COB department to update their records and resubmit; if Medicare MSP rules apply and Medicare was billed as primary, submit to the employer plan first, then submit to Medicare as secondary with the employer plan's EOB. FCSO Medicare CO-22 guidance describes the specific documentation required for Medicare secondary submissions.

How often should eligibility be re-verified?

Best practice is to verify at scheduling, again the day before the visit via batch, and again at check-in for any patient whose batch result returned an exception or whose last visit was more than 30 days prior. Coverage can change between scheduling and the date of service — employer plan terminations, Medicaid eligibility shifts, and Medicare Advantage plan changes all happen mid-year. Per CAQH 2024 Index data, the marginal cost of an electronic re-verification is about $0.34, making pre-visit re-runs economically straightforward.

What should be stored from an eligibility check for audit purposes?

Store the full 271 response, not just the displayed result. The raw transaction preserves the exact benefit data returned on the date of service, which becomes important when a payer denies a claim based on benefits that the 271 showed as covered, or when a patient disputes their responsibility against what the eligibility check showed at service. The date and time of the inquiry, the date of service the inquiry covered, and the payer identifier should all be part of the stored record. Regulators and payers in dispute resolution routinely ask for evidence of the eligibility check that was run before service.

How current is this guide?

Last reviewed 2026-05-17. X12 transaction set references are at x12.org. CMS MSP guidance is at cms.gov Medicare Secondary Payer. CAQH CORE eligibility operating rules are at caqh.org/core. Cost-per-transaction figures are from the CAQH 2024 Index Report. Denial statistics are from the Experian Health 2025 State of Claims survey.