270/271 Eligibility Transaction
A 270/271 eligibility transaction is the standard HIPAA electronic inquiry and response that checks a patient's coverage, benefits, and patient responsibility with a health plan. The 270 request is sent by the provider or clearinghouse and the 271 response is returned by the payer or benefit administrator.
What it means
What a 270/271 eligibility transaction is
A 270/271 eligibility transaction is a HIPAA standard EDI pair used to ask a health plan about a patient's coverage and benefits, and to receive a structured response.
- 270: Eligibility, Coverage or Benefit Inquiry
- 271: Eligibility, Coverage or Benefit Information response
The 270 is typically generated by your practice management or RCM system, often through a clearinghouse, using the X12N 270 format defined by ASC X12. The payer or benefit administrator responds with a 271 that confirms active coverage, plan details, benefit limits, copays, coinsurance, and sometimes notes about prior authorization requirements.
In most behavioral health settings the 270/271 replaces phone calls or portal lookups for routine eligibility checks, especially before intake or at each new episode of care.
Why 270/271 matters operationally
Eligibility gaps are one of the fastest ways to lose money. If you start a residential or IOP episode with incorrect coverage information, you can easily deliver weeks of care with no payable benefits.
Using 270/271 transactions consistently:
- Reduces hard denials tied to no coverage, wrong plan, or terminated eligibility
- Surfaces high deductibles, copays, and coinsurance so you can set financial expectations early
- Flags benefit caps and visit limits before you build long treatment plans
- Anchors audit risk, since you can prove you verified eligibility and saw specific benefit language
For behavioral health providers on per diem or program-based billing, a single missed eligibility check can mean tens of thousands of dollars in charges that hit CO-16 or CO-29. Clean 270/271 use is an upstream control that reduces preventable write-offs.
How 270/271 is used and read in practice
A typical workflow:
- Your system sends a 270 with patient demographics, subscriber details, and the provider's NPI and tax ID.
- The payer or carve-out vendor returns a 271, usually within seconds, with segments that describe:
- Active or inactive coverage status
- Plan type and payer identifiers
- Service-level benefits (for example, mental health outpatient, substance use, partial hospitalization)
- Copay, coinsurance, and deductible details
- Limits, such as visit caps or day limits
- Notes indicating prior authorization or referral requirements
RCM or front-desk staff typically read the 271 through a user interface that has already translated the EDI into plain language. Key fields to review on every response:
- Is coverage active on the planned date of service
- Who is the correct payer for mental health or substance use (carve-out versus medical plan)
- Is the rendering provider in-network or out-of-network
- Are there specific limits or prior authorization requirements for the level of care
Saving the 271 or a human-readable snapshot in the patient record is important. When payers deny later with CO-16, CO-22, or N130, your archived 271 can support appeals and show what information the payer provided at the time of scheduling or admission.
Common mistakes
- Relying only on 'active coverage' on the 271 and not checking service-level benefit segments, so a patient looks covered but has no behavioral health benefit with that payer and the claim later denies with N130 or MA130.
- Missing carve-out language on the 271 that lists a separate behavioral health payer ID or phone number, so your team bills the medical plan first and accumulates CO-16 or CO-109 denials before re-routing claims.
- Ignoring benefit limits and visit caps in the 271 for outpatient therapy or IOP, then billing past the covered visit count and getting CO-97 or PR-96 adjustments that could have been avoided or planned for.
- Assuming that a 271 note about 'authorization may be required' means an auth already exists, so staff skip prior authorization and run into CO-197 denials for an entire residential or PHP episode.
- Not re-running a 270 when a treatment episode spans a new plan year or enrollment period, so eligibility changes mid-stay and later dates of service deny with CO-4 or CO-18 because the payer or plan has changed.
Why it matters in behavioral health
Behavioral health benefits are often carved out to separate vendors, especially for EAP, outpatient therapy, and substance use treatment. The 271 response may show an active medical plan, then list different contact information, payer IDs, or group numbers for mental health and SUD benefits. If staff only look at the top-line coverage status, they can easily bill the wrong payer for the entire episode.
Many payers return service-specific segments on the 271 that break out mental health outpatient, substance use, PHP, IOP, and residential. Those segments often carry visit or day limits and language like 'authorization required after X visits.' For long per-diem stays, those details are critical. You can map the 271 information into your authorization tracking and utilization review workflows so you do not deliver days beyond the covered limit without concurrent auth.
State Medicaid and Medicaid MCOs often use 270/271 heavily, but behavioral health services may sit with different plans than medical. A 271 can reveal that SUD residential or withdrawal management benefits live under a separate behavioral health MCO contract while outpatient therapy runs through the main MCO. Reading those distinctions carefully up front keeps you from sending claims into the wrong Medicaid plan and waiting months to discover CO-22 or N130 denials.
For programs that bill weekly or monthly per diem for IOP, PHP, or residential, it can be worth sending a new 270 before each billing period, especially around redetermination dates. That cadence catches mid-episode eligibility loss early so your clinical and UR teams can discuss options with the patient rather than learning about lost coverage when the 835 hits.
How AI can help with 270/271 Eligibility Transaction
AI agents can handle the mechanics and volume of 270/271 traffic. An eligibility agent can send 270 transactions through your clearinghouse, parse the raw 271, and surface what actually matters to staff: Is coverage active, who is the correct behavioral health payer, is the provider in-network, what are the limits, and is prior authorization indicated. It can also compare new 271 responses against prior ones and flag changes in payer, plan, or benefit limits.
Supabill uses an eligibility and benefits-verification agent to read every 271 and normalize payer-specific language into structured fields for behavioral health: carve-out payer identifiers, level-of-care flags (like IOP or residential), visit caps, and cost-share by service type. The agent can also tie each 271 response back to later denials in the 835, so when a CO-197 or N130 denial arrives, you can quickly see what the payer previously told you. AI will not replace judgment when the 271 is vague or contradictory. Humans still need to call payers for edge cases, clarify confusing authorization notes, and decide when to accept benefit risk for clinically necessary care.
FAQ
What is the difference between a 270/271 eligibility transaction and checking eligibility on a payer portal?
A 270/271 transaction is a standard electronic message pair defined by ASC X12 that your system or clearinghouse sends and receives. A payer portal is a proprietary web interface that you log into directly. Portals often show richer narratives or documents, but they require manual work and are not standardized. 270/271 traffic can be automated from your practice management system, can run in batches, and can be logged consistently. Many organizations use 270/271 as the default and fall back to portals or phone calls when the 271 is incomplete or contradicts clinical or prior history.
Does a 271 eligibility response guarantee that a behavioral health claim will be paid?
No. A 271 confirms coverage and benefits at a point in time but does not guarantee payment. Claims can still deny for lack of prior authorization, medical necessity issues, incorrect coding, coordination of benefits, or reaching benefit limits after the eligibility check. CMS and large payers describe eligibility responses as informational rather than a payment guarantee, so your workflows must still include authorization, accurate coding, and utilization management controls.
What information is required to send a 270 eligibility inquiry?
A 270 generally needs the subscriber or patient name, date of birth, and member ID (if available), plus your billing and rendering provider identifiers such as NPI and tax ID. Some payers will respond with partial data if the member ID is missing, but for reliable behavioral health results you should match what is on the insurance card as closely as possible and send the correct service type or level of care so the payer returns the right benefit segments.
How should behavioral health providers handle carve-outs that appear on a 271 response?
If the 271 indicates that mental health or substance use services are administered by a different payer or vendor, treat that carve-out as the primary payer for those services. Capture the carve-out payer ID, plan name, and any contact numbers from the 271, attach them to the patient record, and update your billing system so claims for those CPT or HCPCS codes route to the correct payer. For complex episodes such as residential or PHP, it is often worth confirming carve-out details by phone before admission, especially with Medicaid MCOs and employer self-funded plans. Source
How often should I re-run 270 eligibility checks for long behavioral health episodes like residential or IOP?
At minimum you should re-run a 270 before each new authorization period, at the start of each plan year, and when you know there has been an enrollment change. Many programs also check eligibility monthly on long stays. That cadence helps you catch mid-episode eligibility loss, plan changes, or exhausted benefits before you continue delivering care that will deny later. Your policy here should balance patient volume, payer mix, and the financial risk of your typical episodes. Source
Related terms
Benefits verification is the process of confirming a patient’s active coverage, financial responsibility, and authorization requirements with the payer before services are rendered. VOB can be manual (phone, fax, portal) or electronic (eVOB using 270/271 transactions or integrated portals).
A clearinghouse is a third-party EDI intermediary that receives electronic claims, checks and reformats them, then forwards them to payers and returns electronic responses. A clearinghouse often also handles eligibility checks, electronic remittances, and claim status transactions between providers and payers.
Prior authorization is a payer requirement to obtain approval before delivering specific services, confirming that planned care is medically necessary and covered under the member's benefit. Prior authorization is typically required for higher-cost, high-utilization, or ongoing treatment and is a common denial trigger when missing or expired.
A Medicaid Managed Care Organization (MCO) is a private or nonprofit health plan that contracts with a state Medicaid agency to deliver Medicaid-covered services to enrolled members, usually for a fixed per-member-per-month payment. In behavioral health revenue cycle, a Medicaid MCO is the billed payer and follows plan-specific coverage, authorization, and billing rules that differ from fee-for-service Medicaid.
Related denial codes
Procedure code inconsistent with modifier / missing modifier
Claim lacks information or has a submission error
Exact duplicate claim or service
May be covered by another payer per coordination of benefits
Time limit for filing has expired
Benefit included in another service already adjudicated
Precertification, authorization, or notification absent
Refer to plan benefit documents for coverage details
Claim contains incomplete or invalid information
