Guide

The 271 response: reading benefits like a biller

Summary

A 270 is the eligibility inquiry your practice management system sends; the 271 is the payer's structured response. It returns active-or-inactive coverage status, the plan and product name, coverage effective dates, and a series of benefit segments — one per service type — each carrying its own remaining deductible, copay, and coinsurance figures. It does not guarantee payment; it reports what the payer's eligibility system shows at the moment you asked.

By Gale Editorial · Updated 2026-07-26. Every figure cited to a dated source. How we write.

What a 270/271 check actually returns

The 270 is your outbound request — patient, subscriber ID, date of service, and the service type you're asking about — and the 271 is the payer's answer to exactly that request, structured as a series of segments rather than a single yes-or-no. CAQH CORE operating rules require payers to support this as a standardized, real-time transaction, which is why a modern clearinghouse or practice management system can return a 271 in seconds 1.

That standardization is what makes a 271 checkable in the first place — without it, each payer could return eligibility data in its own format, and a solo practice would have no reliable way to parse a response it had never seen before. The 271 leads with coverage status — active, inactive, or terminated as of a specific date — then the plan name and product type, then coverage effective and (if applicable) termination dates. Everything after that lives in benefit segments, and that's where the detail a biller actually needs sits.

The benefit segments: where the real numbers are

Each benefit segment in a 271 corresponds to a specific service category — medical care, mental health, chemical dependency, pharmacy, durable medical equipment, and others — and carries its own remaining deductible, copay, coinsurance, and sometimes a visit or dollar limit for that category alone. A patient can show a satisfied medical deductible and an untouched mental health deductible in the same response, because the categories are tracked separately.

Reading the wrong segment — pulling the general medical figures instead of the behavioral health segment, for instance — is the single most common way a 271 gets misread, and it's worth confirming which segment actually maps to the service you're about to render before you quote a patient a number.

Why the 271 sometimes looks incomplete or stale

A 271 reflects the payer's eligibility system at the moment of the query, not a live guarantee — deductible and out-of-pocket figures can lag actual claims processing by days, a patient's coverage can change between the check and the visit, and some plans simply don't populate every segment a request asks for. A gap in the response is common enough that it shouldn't be read as "no coverage for that category" without a second check.

This is a practice norm worth building into your workflow rather than a system failure to troubleshoot each time: re-verify close to the date of service for anything time-sensitive, and treat an unusually clean or unusually empty response with the same mild skepticism you'd give a suspiciously simple answer to a complicated question.

When the 271 flags other coverage

A 271 can surface that a patient has other active coverage beyond the payer you queried, which is your signal to work out coordination of benefits before you bill either payer — CMS runs the coordination-of-benefits process that determines primary-versus-secondary order for Medicare, and the same sequencing logic extends to any two-payer situation 2. Billing the wrong payer first when a 271 already flagged a second policy is one of the more avoidable rejection patterns in solo billing.

If the 271 doesn't clearly resolve which policy is primary, that's worth confirming directly with the patient or the payer before the claim goes out, rather than guessing and correcting after a denial comes back.

Where each payer's own portal fills in the gaps

CAQH CORE standardizes the transaction itself, but what a given payer actually populates in each segment, and how its own provider portal displays that same data, varies by payer — Aetna and UnitedHealthcare, for instance, each publish their own provider-facing policy documentation describing what their eligibility tools show, and neither generalizes to how another payer's system behaves 34. Treat a payer's own portal as the tie-breaker when the 271 itself is ambiguous, not a generic rule of thumb.

This is also where checking a specific payer's own published policy pays off before a visit that's expensive to get wrong — a high-cost procedure, a new patient, or a service you don't render often enough to have institutional memory of that payer's quirks.

From a 271 to an 835: what carries forward

A clean 271 lowers the odds of a downstream denial, but it doesn't prevent one — the claim still has to match on code, units, place of service, and every other adjudication field the 271 never touched. When a denial does come back, the CARC on your 835 remittance explains why the claim was paid differently than billed, and the RARC supplies whatever supplemental detail the CARC alone doesn't cover, both maintained as public code lists 56.

Reading a 271 well is upstream risk reduction, not a substitute for reading the remittance that eventually comes back — the two documents answer different questions, one before the visit and one after the claim is adjudicated.

What a 271 doesn't tell you

A 271 doesn't cover everything relevant to the visit — whether a service needs prior authorization is a separate check entirely, and a carved-out benefit administered by a different company than the one that answered your 271 won't show up as a problem in the response you got. Treat the 271 as one input among several, not the full eligibility picture.

Prior auth as a solo covers what to check before you assume a 271's active-coverage status is the only gate the service has to clear. Carve-outs covers how to find the actual administrator when the medical payer isn't the one paying the claim. A plan that terminates mid-care won't show up in a 271 checked weeks earlier at intake — mid-care termination has its own timeline worth knowing. And reading a plan's full structure, not just what one transaction returns, is closer to benefit design in one pass; a purpose-built eligibility tool, not just a raw 270/271 call, is what eligibility tooling is built for, and the standing habit worth keeping is trust but verify.

Common questions

The 270 is the eligibility inquiry your system sends out — patient, subscriber ID, date of service, service type. The 271 is the payer's structured response to that specific request. You never see a 270 as a document yourself; it's the outbound half of a transaction where the 271 is the half that reaches your desk.

No. A 271 confirms coverage status and reports benefit figures as of the query, but the claim itself still has to clear every other adjudication check — correct coding, units, place of service, medical necessity — that a 271 never evaluates. Treat it as a strong signal, not a payment guarantee.

Payers track deductibles, copays, and coinsurance separately by service category, so a patient's medical and mental health benefits can sit at genuinely different points in the plan year even under the same policy. Always read the segment that matches the service you're about to render, not the first one on the page.

Treat a missing segment as incomplete data, not as a denial of coverage for that category. Re-query closer to the date of service, and if the gap persists, confirm the specific benefit directly with the payer or through their provider portal before relying on the 271 alone.

Coverage and accumulated deductible figures can change between visits, so re-verifying at or near each date of service is the safer habit for anything with real dollars attached, rather than relying on a check run weeks earlier at intake — especially close to a plan-year renewal or a deductible reset, when a stale check is most likely to be wrong.

Run your practice on Gale

The software is free. Gale earns one flat 3.5% all-in per paid transaction — only on transactions that actually pay. No subscription, no setup fee, no network cut.

Start or manage a practice →

References

  1. 1.CAQH (2026). CAQH CORE Operating Rules. CAQH CORE. linkThat CAQH CORE operating rules standardize the 270/271 eligibility transaction as a required, real-time payer capability
  2. 2.Centers for Medicare & Medicaid Services (2026). Coordination of Benefits and Recovery Overview. Centers for Medicare & Medicaid Services (CMS). linkThat coordination of benefits determines primary vs secondary payer order when a 271 surfaces other active coverage
  3. 3.Aetna (2026). Aetna Clinical Policy Bulletins. Aetna provider portal. linkAetna's own published provider policy as a named example of payer-specific eligibility-tool documentation
  4. 4.UnitedHealthcare (2026). UnitedHealthcare Policies and Protocols. UnitedHealthcare provider portal. linkUnitedHealthcare's own published provider policy as a named example of payer-specific eligibility-tool documentation
  5. 5.X12 (2026). Claim Adjustment Reason Codes. X12. linkThat CARCs explain why a claim was paid differently than billed on the 835 that follows a 271 check
  6. 6.X12 (2026). Remittance Advice Remark Codes. X12. linkThat RARCs supply supplemental remittance detail beyond the CARC

https://www.gale.care/for-providers/va-270-271-basics · 6 sources. Competitor details are cited to dated public sources and maintained as they change; figures are estimates, not commitments. Synthetic demonstration.

Findability, by specialty

How practices like yours get found in local search and AI answers — the honest playbook, per specialty.

SEO for private practices · SEO for AI search / answer engines (all verticals)