Updated November 5, 2026, based on CAQH CORE, X12 and CMS as of that date.
A payer can require at most four things to find a member on a 270 eligibility inquiry: member ID, first name, last name and date of birth. Payers must support a primary search option and several alternates, but each plan chooses its own matching logic. When a search fails, the 271 comes back with an AAA reject code that tells you which field to fix.
A common name without a member ID, or a date of birth copied wrong from a referral, can cause "not found" and "multiple records" results. Reading the AAA code and retrying with the right combination may resolve the match without a call to the payer.
The four fields a payer can require
The HIPAA-adopted X12 270/271 sets a maximum data set for finding a patient. The CAQH CORE eligibility data content rule quotes that standard: when the patient is the subscriber, the most a payer can require is "Patient's Member ID, Patient's First Name, Patient's Last Name, Patient's Date of Birth." For a dependent, the payer can require the subscriber's member ID plus the patient's first name, last name and date of birth.
The same standard requires payers to support more than one way in. It "defines four alternate search options that an Information Source is required to support in addition to the Primary Search Option." If an alternate search matches more than one person, the payer "is required to reject the transaction" and name the extra information it needs from the primary search option.
Every payer matches differently
CORE leaves the matching logic to the payer. Its AAA rule "does not require a health plan … to use any specific search and match criteria or logic." Payers may not even use every field you send. An X12 interpretation on search guidance warns that "Information Receivers should be aware that the Information Source might not have used all four of these elements."
X12 puts the member ID first. In an X12 interpretation on identity theft, X12 recommends that the payer "use the member ID on the 270 inquiry as one of the primary components of a search and not use only the name and date of birth."
What the AAA codes tell you
When a payer can't return eligibility, the 271 includes an AAA segment with a reject reason in AAA03. CORE's error table assigns these codes to identification problems:
- 72: invalid or missing subscriber ID.
- 73: invalid or missing subscriber name. CORE also uses 73 when a name-only search returns multiple records.
- 71: the date of birth doesn't match the one on file.
- 58: invalid or missing date of birth.
- 76: duplicate subscriber ID, used when a member ID search returns multiple records.
- 65: invalid or missing patient name, in the dependent loop.
A payer may return more than one AAA segment. An X12 interpretation on AAA codes describes a search that tries the ID, then the name, then the birth date, and says "you may return AAA03 = 71 (Patient Birth Date Does Not Match That for the Patient on the Database)" when the name matches and the birth date doesn't. So a 71 suggests the payer found the person and the birth date is the problem.
Suffixes and punctuation in last names are handled for you
Payers following CORE normalize last names before comparing them when the inquiry includes a member ID. The rule removes "JR, SR, I, II, III, IV, V, RN, MD, MR, MS, DR, MRS, PHD, REV, ESQ" when they follow a space, comma or slash, and strips special characters. A "Smith Jr." on the referral and a "SMITH" on file should still match.
When the stored name differs from what you sent but still validates, the 271 returns the last name as the payer stores it in NM103, with INS03 = 001 and INS04 = 25. Update your record to that spelling so the claim matches too.
Medicare's three search options
The CMS HETS 270/271 companion guide shows how one payer publishes its rules. Medicare's eligibility system accepts three combinations:
- Primary: Medicare Beneficiary Identifier (MBI), last name, first name and date of birth.
- Alternate 1: MBI, last name and date of birth.
- Alternate 2: MBI, last name and first name.
Every option needs the MBI. CMS says "Trading Partners should not submit any additional Beneficiary data elements to generate a match," and a middle name or initial in the middle name field (NM105) returns a 999 response. Other payers publish their own search rules, usually in their 270/271 companion guides.
What to do when referral data is wrong
When a referral has a misspelled name or the wrong date of birth, work through it in this order:
- Get the member ID from the insurance card or the referral source. It turns a name search into an ID search.
- Read the AAA code. A 71 points at the DOB. A 73 points at the name, or at too many matches on a name search.
- Retry with an alternate search option that leaves out the field you doubt, using the options the payer lists in its companion guide.
- If the 271 returns a different stored last name, update your record to match it.
- If nothing matches, check the payer portal or call provider services, and ask the referral source to confirm the patient's details.
Whether a payer accepts a search without a member ID varies by payer. Check its 270/271 companion guide. Getting demographics right at intake prevents some of these retries. Our guide to referral intake automation covers that step.
Frequently asked questions
Why do I get "multiple records found" even with a date of birth?
The payer may not use every field you send, and some search on name or ID first. Without a member ID, a common name can match several members. Send the member ID whenever you have it.
Can I search without a member ID?
Some payers accept a name and date of birth search, and some don't. Medicare requires the MBI on every search. Check the payer's companion guide.
What does AAA 71 mean?
The date of birth you sent doesn't match the one the payer has for that person. The name or ID likely matched, so recheck the DOB with the patient or the referral source.
Should I send a middle initial?
Check the payer's companion guide. Medicare returns a 999 response if a middle name or initial is sent in NM105, so leave it out for Medicare.
The 271 returned a different last name. Which do I use?
Use the name the payer returned in NM103. CORE requires the payer to send the last name as stored when it differs from what you submitted, so claims match the payer's record.
Running member searches across payer portals?
Champ automates portal work like eligibility checks. We set it up and run it, so your staff sees only the finished results. If referral data keeps sending your team back to the portal, learn more here.
This post is general information, not legal, compliance or billing advice. Rules vary by payer and change often, so confirm search rules in the payer's companion guide or with provider services before acting. Champ is not affiliated with or endorsed by CAQH, X12 or CMS.
Continue reading
See all
Prior Authorization Turnaround Times: What CMS Requires Payers to Meet
Under CMS-0057-F, most Medicare Advantage and Medicaid plans must decide prior authorizations within 7 days, or 72 hours when urgent. This guide covers who the rule applies to, when payers can extend, and how to keep requests moving.

Can You Share a Payer Portal Login? MFA, User Accounts and Credential Rotation
Payer portals like Availity and UnitedHealthcare require a separate login for every user. Here's how to handle administrators, billing vendors, MFA and password changes.

Payers Without an API: How RCM Software Gets Eligibility, Claim Status, and Prior Auth Answers
HIPAA standardizes the format of eligibility, claim status and prior auth transactions, not how much detail comes back. Here is what X12, CMS-0057-F APIs, portals and phone each return, and how to set a fallback order per payer.