# EDI 271 Eligibility Response: HIPAA 5010 Guide
> EDI 271 eligibility response explained: EB benefit lines for deductibles, copays and coinsurance, AAA reject codes, and live examples of a 271.
The EDI 271 is the X12 Eligibility, Coverage or Benefit Information transaction a health plan sends in reply to a 270 inquiry. It reports whether the patient has active coverage, the plan dates, and benefit details such as deductibles, copays, coinsurance and out-of-pocket amounts, or it rejects the inquiry with an AAA segment and a reason code.
**The EDI 271 is where a front desk learns what the patient owes and whether the visit is covered.** It answers a [270 eligibility inquiry](/guides/edi/270-eligibility-benefit-inquiry), usually within seconds over a real-time clearinghouse connection. Reading it well means understanding one segment above all others: `EB`, the eligibility or benefit line, which repeats as many times as the plan has something to say.
This guide covers how a 271 is organized, how to read `EB` segments without misquoting a patient's cost share, the `AAA` reject codes, two live examples from fictional data, and the errors teams make when they turn a 271 into a copay estimate. It describes the X12 structure only. It is not legal, billing or medical advice, and the health plan's own documents govern what a member's coverage is.
## What Is an EDI 271?
**An EDI 271 is the Eligibility, Coverage or Benefit Information transaction set defined by [ASC X12](https://x12.org/examples/005010x279), used by a health plan to answer a provider's 270 with coverage status and benefit details.** It shares its implementation guide with the 270: the X12 Technical Report Type 3 `005010X279`, adopted for the HIPAA eligibility transaction in [45 CFR 162.1202](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-L/section-162.1202). [CMS's 5010 errata schedule](https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Versions5010andD0/Downloads/Errata_Req_and_Testing.pdf) lists `005010X279A1` as the errata version required for compliance, and that is the value you will see in `GS08` and `ST03`. The functional group code in `GS01` is `HB`.
Authoritative references for 271 work:
- The [X12 005010X279 examples](https://x12.org/examples/005010x279) include a full 271 with active coverage, copays and a primary care provider, and a 271 rejected with an `AAA` segment
- [CMS's operating rules page](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/operating-rules) explains that HHS adopted CAQH CORE operating rules for the eligibility transaction, effective January 1, 2013. They are incorporated in [45 CFR 162.920](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-I/section-162.920) and add requirements such as connectivity on top of the TR3
- Each health plan's companion guide says which benefits it returns, at what level of detail, and for which service type codes
**Who sends it?** The health plan or its eligibility vendor (the information source).
**Who receives it?** The provider that asked, usually through the clearinghouse that routed the 270.
**When is it sent?** In reply to each 270: within the same session for real-time inquiries, or as a returned batch file.
**Why does it matter?** The 271 drives what the front desk collects and whether a visit goes ahead. Misread a remaining deductible or apply an out-of-network copay to an in-network visit, and the patient statement after the [835 remittance](/guides/edi/835-health-care-claim-payment-advice) will not match what you told them.
## Interactive Example: 271 With Active Coverage
The fictional health plan answers the fictional practice's 270 for JOHN SAMPLE. The response echoes the trace number in `TRN*2`, confirms the plan begin date in `DTP*346`, and lists seven `EB` lines: active coverage, an in-network calendar-year deductible and the amount remaining, the out-of-pocket maximum, an office visit copay, coinsurance, and an out-of-network deductible. All names, IDs and amounts are fictional, and `ISA15` is `T` (test).
Use the **Plain English** tab for a readable summary, or click any segment to break it down element by element.
## Interactive Example: 271 Rejected With AAA
Here the member ID on the inquiry did not pass the payer's validation. Instead of benefits, the subscriber loop carries `AAA*Y**72*C`: the request was valid as a transaction (`Y`), the reject reason is `72` (invalid or missing subscriber/insured ID), and the follow-up action is `C` (please correct and resubmit).
## 271 Structure at a Glance
The 271 mirrors the 270's hierarchy (`BHT01` = `0022`). Where the 270 has `EQ` inquiry segments, the 271 has `EB` benefit segments.
| Loop | Segment | Name | Notes |
|---|---|---|---|
| Header | **ST** | Transaction Set Header | `ST01` = `271`, `ST03` = `005010X279A1` |
| Header | **BHT** | Beginning of Hierarchical Transaction | Purpose `11` (response); `BHT03` echoes the 270's reference |
| 2000A / 2100A | **HL / NM1 / AAA** | Information source (payer) | An `AAA` here means the payer could not answer at all |
| 2000B / 2100B | **HL / NM1 / AAA** | Information receiver (provider) | An `AAA` here usually means a provider identification or enrollment problem |
| 2000C | **HL / TRN** | Subscriber level and trace | `TRN01` = `2`, echoing your trace number |
| 2100C | **NM1** | Subscriber Name | Name and member ID as the payer has them |
| 2100C | **N3 / N4** | Subscriber Address | Address on file |
| 2100C | **AAA** | Subscriber Request Validation | Present when the subscriber could not be found or validated |
| 2100C | **DMG / INS / DTP** | Demographics, relationship, dates | `DTP` carries plan and eligibility dates |
| 2110C | **EB** | Eligibility or Benefit Information | Repeats, one per benefit statement |
| 2110C | **HSD / REF / DTP / AAA / MSG** | Benefit details | Quantities, references, dates and free-text messages tied to the `EB` |
| 2115C / 2120C | **III / LS / NM1 / LE** | Additional information and related entities | For example a primary care provider or another payer |
| 2000D-2120D | | Dependent levels | Same layout for a dependent patient |
| Trailer | **SE** | Transaction Set Trailer | Segment count and control number |
## Key Segments Explained
### TRN: Trace Number Echo
```
TRN*2*TRC-000001*9123456789~
```
`TRN01` = `2` means referenced transaction trace number: this is your trace from the 270 coming back. Match on it, not on name, when you process batch responses. A payer can also add its own `TRN*1` trace.
### DTP: Plan and Eligibility Dates
```
DTP*346*D8*20260101~
```
| Qualifier | Meaning |
|---|---|
| `346` | Plan begin |
| `347` | Plan end |
| `291` | Plan (a date or range the response applies to) |
| `307` | Eligibility |
A plan end date in the past, or an `EB01` of `6` (inactive), is the clearest sign the patient's coverage has ended. Check the dates before you look at benefit amounts.
### EB: Eligibility or Benefit Information
```
EB*C*IND*30***23*1500*****Y~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **EB01** | Eligibility or Benefit Information Code | `C` | Deductible (see table below) |
| **EB02** | Coverage Level Code | `IND` | `IND` individual, `FAM` family, `EMP` employee only and others |
| **EB03** | Service Type Code | `30` | Health benefit plan coverage; can repeat with the repetition separator |
| **EB04** | Insurance Type Code | | For example `HM` (HMO), as in the X12 example |
| **EB05** | Plan Coverage Description | | Plan name, such as `SAMPLE PPO PLAN` |
| **EB06** | Time Period Qualifier | `23` | `23` calendar year, `29` remaining, `27` visit, `32` lifetime |
| **EB07** | Monetary Amount | `1500` | The dollar amount |
| **EB08** | Percentage as Decimal | | `.2` means 20 percent |
| **EB09 / EB10** | Quantity Qualifier / Quantity | | Visit counts, days and similar limits |
| **EB11** | Authorization or Certification Indicator | | `Y` when the payer says the benefit needs authorization |
| **EB12** | In Plan Network Indicator | `Y` | `Y` in network, `N` out of network; the TR3 defines the other values |
| **EB13** | Composite Medical Procedure Identifier | | A procedure code, when the benefit is procedure specific |
Common `EB01` codes:
| Code | Meaning | How to read it |
|---|---|---|
| `1` | Active coverage | Coverage exists for the service types listed |
| `6` | Inactive | Coverage is not active for the service types or dates listed |
| `A` | Co-insurance | A percentage in `EB08` |
| `B` | Co-payment | A dollar amount in `EB07`, often per visit (`EB06` = `27`) |
| `C` | Deductible | A dollar amount; `EB06` tells you whether it is the full amount (`23`) or what is left (`29`) |
| `F` | Limitations | Visit or dollar limits, often with `EB09`/`EB10` |
| `G` | Out of pocket (stop loss) | The out-of-pocket maximum, or what remains of it |
| `I` | Non-covered | The service types listed are not covered |
| `L` | Primary care provider | Followed by an `LS`/`NM1`/`LE` loop naming the PCP |
| `R` | Other or additional payer | Another payer may be primary or secondary |
Read each `EB` as one sentence built from all its elements. `EB*C*IND*30***29*900*****Y` in the sample says: deductible, individual, health benefit plan coverage, remaining, $900, in network. Take any one element out of that sentence (the `29`, the `IND` or the `Y`) and the dollar amount means something different.
### AAA: Request Validation
```
AAA*Y**72*C~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **AAA01** | Valid Request Indicator | `Y` | `Y` the request was valid, `N` it was not |
| **AAA03** | Reject Reason Code | `72` | Why the payer could not answer |
| **AAA04** | Follow-up Action Code | `C` | What to do next |
Reject reason codes you will see most:
| Code | Meaning |
|---|---|
| `42` | Unable to respond at current time |
| `43` | Invalid/missing provider identification |
| `50` | Provider ineligible for inquiries |
| `51` | Provider not on file |
| `58` | Invalid/missing date of birth |
| `71` | Patient birth date does not match that for the patient on the database |
| `72` | Invalid/missing subscriber/insured ID |
| `73` | Invalid/missing subscriber/insured name |
| `75` | Subscriber/insured not found |
| `76` | Duplicate subscriber/insured ID number |
Follow-up action codes include `C` (please correct and resubmit), `N` (resubmission not allowed), `R` (resubmission allowed), `P` (please resubmit original transaction), `W` (please wait 30 days and resubmit), `X` (please wait 10 days and resubmit) and `Y` (do not resubmit; the payer will respond again shortly). The level of the `AAA` matters: in loop 2000A it is the payer, in 2000B or 2100B it is the provider, and in 2100C or 2100D it is the patient.
### MSG, LS and LE: Messages and Related Entities
`MSG` carries free text tied to a benefit, such as a note on how a benefit applies. Read it, but do not try to parse amounts out of it. `LS*2120` and `LE*2120` wrap a loop that names an entity related to a benefit, such as the primary care provider (`NM101` = `P3`) in the X12 example, or another payer to bill.
## 270 vs 271 vs 999
| Document | Sent by | What it tells you |
|---|---|---|
| **[270 Eligibility Inquiry](/guides/edi/270-eligibility-benefit-inquiry)** | Provider | The question: who, which payer, which service types |
| **271 Eligibility Response** | Health plan | The answer: coverage, dates and benefits, or an `AAA` rejection |
| **[999 Implementation Acknowledgment](/guides/edi/999-implementation-acknowledgment)** | Clearinghouse or payer | Whether the 270 file passed syntax and TR3 validation |
A 999 rejection means the 270 never reached the payer's eligibility logic. A 271 with an `AAA` means it did, and the payer could not match or answer it.
## Where the 271 Sits in the Revenue Cycle
1. Registration captures the patient's coverage from the card.
2. The 270 asks the payer; the **271** answers.
3. If the 271 shows a service needs authorization, the provider sends a [278 services review](/guides/edi/278-health-care-services-review).
4. After the visit, the provider bills with an [837 claim](/guides/edi/837-health-care-claim).
5. The [276 and 277](/guides/edi/277-claim-status-response) track the claim; the 835 explains payment.
## Common 271 Errors and How to Prevent Them
| Error | What happens | Prevention |
|---|---|---|
| **Out-of-network amount applied to an in-network visit** | Wrong copay or deductible quoted to the patient | Always filter `EB` lines on `EB12` |
| **Full deductible read as remaining** | Patient told they owe more or less than they do | Check `EB06`: `23` is the annual amount, `29` is what is left |
| **Individual and family amounts mixed** | Wrong cost share | Filter on `EB02` coverage level |
| **Only the first `EB` read** | Missed limitations, non-covered services or authorization flags | Parse every `EB` in the 2110 loop, including `EB11` |
| **`AAA` ignored** | Staff assume "no benefits" means "not covered" | Route `AAA` responses to a work queue with the reason code |
| **Response matched to the wrong patient in a batch** | Wrong benefits on an account | Match on the `TRN` trace number |
| **Free text in `MSG` treated as data** | Misquoted amounts | Show `MSG` to staff; take amounts only from `EB` elements |
| **Coinsurance read as a whole number** | 20 percent shown as 0.2 percent or 2,000 percent | `EB08` is a decimal: `.2` is 20 percent |
## 271 Implementation Checklist
- Confirm `GS01` = `HB` and `005010X279A1` handling in your translator
- Parse every `EB` element, not only `EB01` and `EB07`
- Build display logic around `EB02`, `EB03`, `EB06` and `EB12` together
- Route `AAA` rejections by level (payer, provider, subscriber, dependent) and follow-up action code
- Match responses to requests on `TRN02`, and store `BHT03`
- Surface `EB11` authorization flags to the team that sends 278s
- Keep the raw 271 with the appointment for audit and patient questions
- Test active, inactive, not-found, dependent and multi-service-type responses with each major payer
For a general primer on X12 envelopes and segments, see our [essential guide to EDI](/blog/essential-guide-to-edi). The [EDI document types reference](/edi-document-types) lists other X12 transaction sets.
## Where OrderSync Fits
OrderSync's product is built for supplier order flows: it reads inbound purchase orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches customers, items and units, and outputs ERP data or valid X12.
For healthcare EDI teams, the useful piece is the [free EDI inspector](/edi-inspector), which parses any X12 file, 271s included. Paste a test 271 to see each `EB` line and `AAA` rejection labeled, with a plain-English summary. Follow your organization's policies on protected health information before pasting a production file; test files with fictional data work just as well for checking structure.
## Frequently Asked Questions
### What is an EDI 271?
The EDI 271 is the X12 Eligibility, Coverage or Benefit Information transaction a health plan sends in response to a 270. It reports coverage status, plan dates and benefit details, or rejects the inquiry with an AAA segment.
### What is the EB segment in a 271?
EB is the Eligibility or Benefit Information segment. Each EB states one fact about coverage: active coverage, a deductible, a copay, coinsurance, an out-of-pocket maximum, a limitation or a non-covered service, qualified by coverage level, service type, time period and network.
### How do I find the remaining deductible in a 271?
Look for an EB segment with EB01 = C (deductible) and EB06 = 29 (remaining). EB07 holds the amount. Check EB02 for individual or family and EB12 for in or out of network before quoting it.
### What does AAA mean in a 271?
AAA is the Request Validation segment. It means the payer could not answer part or all of the inquiry. AAA03 gives the reason, such as 72 invalid or missing subscriber ID or 75 subscriber not found, and AAA04 says whether to correct and resubmit.
### What does EB01 = 1 mean?
It means active coverage for the service types listed in EB03. EB01 = 6 means inactive. Active coverage alone does not tell you the patient's cost share; that comes from the A, B, C and G lines.
### Why do different payers return different 271s for the same question?
The TR3 sets the structure, but each payer decides how many service types it answers and how much detail it returns, within the TR3 and the adopted CAQH CORE operating rules. Its companion guide documents those choices.
### Is the 271 the same version as the 270?
Yes. Both use the 005010X279A1 implementation guide. The 270 travels in a functional group with GS01 = HS and the 271 with GS01 = HB.