AAA eligibility errors in plain English

Payers reject eligibility checks for all kinds of reasons. For failed requests, X12 271 eligibility responses typically include a segment called AAA.

AAA errors tell you what went wrong. Payers return them for things like bad member IDs, missing info, and system outages. They also include tips for what to do next.

Stedi’s Eligibility Check APIs let you get 271 responses as JSON or raw X12 EDI. This guide explains how to find AAA errors in 271 responses, what the most common ones mean, and how to fix them.

How to find and read AAA errors

Every AAA error includes three pieces of information:

• Code – What went wrong, such as a bad member ID or invalid name.

• Followup Action – What the payer recommends you do next.

• Location – The location of the error within the original X12 EDI response.

If you’re reading raw X12, the following table outlines possible loop locations:

If you’re using JSON responses, you don’t need to decode loops. Instead, AAA errors are nested under the related section of the response:

• subscriber.aaaErrors[] – The most common spot for AAA errors.

• dependents[].aaaErrors[] – If checking eligibility for a dependent.

• provider.aaaErrors[] – Typically indicates an NPI or transaction enrollment issue.

• payer.aaaErrors[] – Usually indicates a connectivity or access issue with the payer.

All errors at these levels are also returned in the top-level errors array. Example:

{
 "errors": [
    {
      "code": "43",
      "followupAction": "Please Correct and Resubmit",
      "location": "Loop 2100B",
      ...
    }
  ],
  ...
}

Common AAA errors

This section covers the most common AAA errors. Errors are listed in numerical order – not by frequency – for easier lookup.

For complete details, see Payer AAA errors in the Stedi docs.

15 – Required Application Data Missing

The request didn’t include enough info to identify the patient. Or the request is missing a required provider field, like Tax ID.

How to fix it:

• Double-check the patient’s name, date of birth (DOB), and member ID.

• Include the provider’s Federal Taxpayer Identification Number (EIN) in the request’s provider.federalTaxpayersIdNumber field.

33 – Input Errors

The request is missing payer-required fields or includes invalid data.

Some payers issue each dependent their own member ID and don’t support eligibility requests that include a dependents array. These payers may return this error if the request includes the patient in that array.

How to fix it:

• Double-check that you’re sending all required fields:

  • Patient first name

  • Patient last name

  • Patient date of birth (DOB)

  • Patient member ID

  • Provider NPI

  • Service Type Code (STC) or procedure codes

• Make sure all values are in the correct format, especially the patient’s DOB and member ID.

• If the request includes a dependent patient in the dependents array, try sending their info in the subscriber object instead.

41 – Authorization/Access Restrictions

The provider isn’t authorized to submit eligibility checks to the payer.

How to fix it:

• Some payers require transaction enrollment for eligibility requests. Ensure the provider is enrolled with the payer.

42 – Unable to Respond at Current Time

The payer is temporarily unavailable.

How to fix it:

• Automatically retry using the retry strategy outlined in our docs.

• If retries fail, retry with a different patient and NPI to rule out request-level issues.

• If all requests are failing, contact Stedi support.

43 – Invalid/Missing Provider Identification

The NPI you sent isn’t valid for the payer, or the provider isn’t enrolled with the payer for eligibility requests.

How to fix it:

• Make sure the NPI is correct.

• Confirm the payer supports 270/271 eligibility checks in the Stedi Payer Network.

• Some payers require transaction enrollment for eligibility requests. If so, ensure the provider is enrolled with the payer.

• If supported, retry with a different patient and NPI to rule out request-level issues.

• If all requests are failing, contact Stedi support.

50 – Provider Ineligible for Inquiries

The payer doesn’t allow the provider to submit eligibility checks for the Service Type Code (STC).

How to fix it:

• Some payers require transaction enrollment for eligibility requests. Ensure the provider is enrolled with the payer.

• Confirm that the provider is enrolled with the payer for the Service Type Code (STC) you're using. Some payers only allow certain specialties to check eligibility for specific benefits.

51 – Provider Not on File

The payer doesn’t recognize the provider’s NPI. This usually means the provider isn’t registered with the payer.

How to fix it:

• Make sure the NPI is correct.

• Confirm the payer supports 270/271 eligibility checks in the Stedi Payer Network.

• Some payers require transaction enrollment for eligibility requests. Ensure the provider is enrolled with the payer.

• Some payers require credentialing before accepting eligibility checks from a provider. The provider must contact the payer to register.

52 – Service Dates Not Within Provider Plan Enrollment

The provider wasn’t enrolled in the patient’s plan with the payer on the date of service.

How to fix it:

• Confirm the patient was actively enrolled on the specific date of service.

• Double-check the date of service in the request. Ensure the date(s) are properly formatted as YYYYMMDD.

• Check that the date of service isn’t far in the future. Most payers support future dates through the end of the current calendar month. Only a few, such as CMS, support dates further into the future.

57 – Invalid/Missing Date(s) of Service

The date of service (DOS) is missing, incorrectly formatted, far in the future, or outside the payer’s allowed range.

How to fix it:

• Double-check the date of service in the request. Ensure the date(s) are properly formatted as YYYYMMDD.

• Check that the date of service isn’t far in the future. Most payers support future dates through the end of the current calendar month. Only a few, such as CMS, support dates further into the future.

• If requests still fail, try omitting encounter.dateOfService from the request.

58 – Invalid/Missing Date-of-Birth

The subscriber or dependent’s date of birth is missing or incorrectly formatted. Some payers require it to locate the member.

How to fix it:

• Include dateOfBirth in the request, formatted as YYYYMMDD.

• Double-check that the date is accurate and is not a future date or invalid day/month.

• Some payers require a date of birth (DOB) even when a member ID is present.

62 – Date of Service Not Within Allowable Inquiry Period

The date of service you submitted is outside the payer’s allowed range.

How to fix it:

• Don’t send dates more than two years in the past. Some payers only support eligibility checks for dates within the last 12 or 24 months.

• Check that the date of service isn’t far in the future. Most payers support future dates through the end of the current calendar month. Only a few, such as CMS, support dates further into the future.

63 – Date of Service in Future

The date of service is in the future. The payer doesn’t allow eligibility checks for future dates.

How to fix it:

• Check that the date of service isn’t far in the future. Most payers support future dates through the end of the current calendar month. Only a few, such as CMS, support dates further into the future.

• Try omitting the date of service from the request.

64 – Invalid/Missing Patient ID

The patient’s ID is missing or doesn’t match what the payer has on file. This usually happens when the payer needs the dependent’s member ID, but the request only includes the subscriber’s.

How to fix it:

• Check the insurance card. Some plans list separate IDs for dependents. If the patient is a dependent and has their own member ID, treat them as the subscriber and leave out the dependents array.

65 – Invalid/Missing Patient Name

The name of the patient is missing or doesn’t match the payer’s records.

How to fix it:

• Check the insurance card. Some plans list separate IDs for dependents. If the patient is a dependent and has their own member ID, treat them as the subscriber and leave out the dependents array.

• Use the full legal name. For example, “Robert” not “Bob.”

• Avoid nicknames, abbreviations, or special characters.

• Try different name orderings for compound or hyphenated names. Check if the patient has recently changed names.

67 – Patient Not Found

The payer couldn’t find the patient in their system based on the information you submitted.

How to fix it:

• Double-check the patient’s name, date of birth (DOB), and member ID.

• Try sending different combinations of those fields to account for data mismatches – especially if you're missing the member ID.

68 – Duplicate Patient ID Number

The payer found more than one patient record with the ID you submitted. They can’t tell which one you meant.

How to fix it:

• Include the patient’s name, date of birth (DOB), and member ID to help the payer narrow down the match.

• In rare cases, this error can occur due to a data issue on the payer side. For example, duplicate records for the same person with the same member ID. If you suspect this, contact Stedi support.

71 – Patient DOB Does Not Match That for the Patient on the Database

The date of birth (DOB) in your request doesn’t match what the payer has on file for the patient.

How to fix it:

• Double-check the patient’s dateOfBirth. Use the YYYYMMDD format.

• Confirm the patient’s DOB from a reliable source, like the insurance card or other identification.

72 – Invalid/Missing Subscriber/Insured ID

The member ID doesn’t match the payer’s requirements.

How to fix it:

• Use the exact ID on the subscriber’s insurance card.

• If no card is available, run an insurance discovery check using demographic data, like name and date of birth (DOB).

73 – Invalid/Missing Subscriber/Insured Name

The subscriber’s name doesn’t match the payer’s records.

How to fix it:

• Use the full legal name. For example, “Robert” not “Bob.”

• Avoid nicknames, abbreviations, or special characters.

• Try different name orderings for compound or hyphenated names. Check if the patient has recently changed names.

74 – Invalid/Missing Subscriber/Insured Gender Code

The patient’s gender code is missing, incorrect, or not formatted the way the payer expects.

How to fix it:

• Double-check that the gender matches what’s on file with the payer.

• Try omitting gender to see if the payer defaults correctly.

75 – Subscriber/Insured Not Found

The payer couldn’t match the subscriber’s details to anyone in their system. This is the most common error.

How to fix it:

• Verify the member ID matches the patient’s insurance card. Include any prefix or suffix on the patient’s ID.

• Double-check the patient’s name and date of birth (DOB).

• Use the full legal name. For example, “Robert” not “Bob.” Avoid nicknames, abbreviations, or special characters. Try different name orderings. Check if the patient has recently changed names.

• If the info is correct, confirm the request is going to the right payer.

76 – Duplicate Subscriber/Insured ID Number

The payer found more than one member with the subscriber ID you sent. They can’t determine which one to return.

How to fix it:

• Include the patient’s name, date of birth (DOB), and member ID in the request.

78 – Subscriber/Insured Not in Group/Plan identified

The payer found the member, but they aren’t enrolled in the group or plan you specified.

How to fix it:

• If possible, include the groupNumber or planNumber in the request. Make sure it matches what’s on the member’s insurance card.

• Try omitting the groupNumber. Many payers can still return eligibility without it.

79 – Invalid Participant Identification

If the response has a 200 HTTP status, this usually means there’s a connectivity issue with the payer. If the response has a 400 HTTP status, it means the payer ID is invalid or the payer doesn’t support eligibility checks.

How to fix it:

• If the error comes back with a 200 HTTP status, automatically retry using the retry strategy outlined in our docs.

• If you get a 400 status, don’t retry. Confirm the payer ID and that the payer supports 270/271 eligibility checks in the Stedi Payer Network.

• If all requests continue failing, contact Stedi support.

80 – No Response Received - Transaction Terminated

The payer didn’t return any eligibility data. The transaction timed out or failed midstream.

How to fix it:

• Automatically retry using the retry strategy outlined in our docs.

• If retries fail, retry with a different patient and NPI to rule out request-level issues.

• If all requests are failing, contact Stedi support.

97 – Invalid or Missing Provider Address

The address submitted for the provider is missing or doesn’t match what the payer has on file.

How to fix it:

• Double-check the provider’s address in informationReceiverName.address. Check for formatting issues, like missing ZIP or street line, or common mismatches (e.g. “St.” vs. “Street”).

Retryable AAA errors

Only AAA errors 42, 79, and 80 are retryable. These indicate temporary payer issues like downtime or throttling. All other AAA errors require fixing before retrying.

AAA 79 errors are only retryable if it comes back with a 200 HTTP status. If you get a 400 status, it usually means the payer ID is invalid or not configured. Don’t retry in these cases.

The right retry strategy depends on your use case:

Retry strategy for real-time eligibility checks
If you’re using the real-time endpoint and need a fast response – like checking in a patient – we recommend:

• Wait 15 seconds before the first retry.

• Retry every 15 seconds for up to 2 minutes.

• Don’t send the same NPI to the payer more than once every 15 seconds.

• If requests still fail, stop retrying and contact Stedi support.

If requests still fail, stop retrying and contact Stedi support.

Retry strategy for batch refreshes
If you’re running eligibility refreshes between appointments, use the batch endpoint. For this endpoint, Stedi automatically retries AAA 42, eligible 79, and 80 errors in the background for up to 8 hours.

If you’re using the real-time endpoint and can tolerate longer delays:

• Wait 1 minute before the first retry.

• Then exponentially back off – up to 30 minutes between retries

• Continue retrying for up to 8 hours.

For full guidance, see our retry strategy docs.

How to handle non-retryable AAA errors

If a 271 response includes any AAA errors, treat it as a failure – even if it includes benefits data. Payers sometimes return benefits alongside AAA errors. In JSON responses, you can check the top-level errors array to quickly detect AAA errors.

If the error isn’t retryable, use Stedi’s Eligibility Manager to debug and try the request again.

How to mock AAA errors

In Stedi’s test mode, you can use mock eligibility checks to simulate common AAA errors and test your application’s error-handling logic. See Eligibility mock requests for more details.

Fast, expert eligibility help

Stedi gives you modern APIs and tools to build accurate, reliable eligibility workflows. When errors do happen, you get help fast. Our average support response time is under 8 minutes.

Want to see how good support can be? Get in touch.