Eligibility troubleshooting

A list of potential errors and possible resolutions when submitting 270/271 eligibility checks.

Payer unable to find patient

Sometimes, a payer can't return benefits information for a patient even when the patient exists in their system. This problem can occur for a couple reasons.

Multiple matching records

Payers can have multiple records of patients with the same name and date of birth. The payer cannot return benefits information unless they are able to identify a unique match within their system.

To avoid this issue, we recommend:

Include all of the demographic information available for a patient.
Include the patient's member ID, if available.

There can be discrepancies between the information the provider has collected from the patient and the record the payer has in their system. These discrepancies can lead to issues returning a patient, even though a match exists. Some examples include differences in spelling the patient's name, using a nickname instead of the full name ("Nick" vs. "Nicolas"), and accidentally transposing numbers in the date of birth.

If a request fails to return the expected member in the response, we recommend progressively sending additional eligibility check requests with fewer patient identity and demographic data elements, or different combinations of those. This allows you to identify and handle cases where there are data errors or discrepancies between payer and provider data.

Name mismatches

If the payer fails to find a matching plan member due to a name mismatch, the errors array in the response typically has the code set to one of the following values:

65: Invalid/Missing Patient Name
67: Patient Not Found
73: Invalid/Missing Subscriber/Insured Name
75: Subscriber/Insured Not Found

These error codes are set by the payer, not by Stedi, so it's possible that other error codes could be returned.

Resolving the error may require trying different name variations until the check is successful.

Replace any nickname or shortened name with the full legal name, for example "Robert" instead of "Bob".
Replace any non-English or accented characters (letters with diacritical marks) such as "Ñ" or "é" with the closest equivalent within the character restrictions. Stedi automatically replaces most such characters with the usual closest equivalent but this might not match the payer's record. For example, the character "Đ" could be transliterated to "D" or "J" depending on the romanization system used.
For compound names try using only one or the other part. You can also try try removing the separator, or changing the separator from hyphen to space, or vice versa. Some payers may ignore special or separator characters when performing name searches.
If the patient has recently changed their name, for example due to marriage, then the name stated by the patient or printed on their ID card might not match the payer's record. Try both the current and previous name.

Retry strategy

Implementing the right retry strategy for eligibility check failures saves a lot of time and money.

At a minimum, we strongly recommend automatically retrying every request that fails due to payer connectivity issues. Automatic retries resolve a significant portion of these types of failures without manual intervention.

Payer connectivity issues

We recommend implementing automatic retries for all of the following AAA error cases. These scenarios indicate temporary payer downtime, throttling, or intermittent connectivity issues:

42 (Unable to Respond at Current Time)
42 (Unable to Respond at Current Time) and 79 (Invalid Participant Identification)
80 (No Response received - Transaction Terminated)

Our recommended retry strategy depends on your eligibility check workflow.

Real-time eligibility checks

For real-time eligibility checks that require a response within a few minutes, we recommend:

Retry immediately and continue retrying for up to 2 minutes.
The recommended retry window is based on what's acceptable in real-time human workflows. For example, a patient checking in for an appointment at their doctor's office.
If the request is still unsuccessful, fail gracefully and escalate as needed.

Scheduled eligibility checks

You may want to run scheduled or background eligibility checks to perform periodic refreshes for a patient population or when checking eligibility for upcoming appointments.

If you're using the Batch Eligibility Check endpoint (recommended), Stedi automatically retries checks that fail due to payer connectivity issues for up to 8 hours.

If you're submitting real-time checks that can tolerate longer wait times, we recommend:

Wait 1 minute to perform the first retry.
Then, exponentially increase the wait between subsequent retries to up to 30 minutes between attempts.
We recommend retrying for at least 8 hours, but the retry window should be based on your business workflows.

Other common error cases

You should also consider the following common error cases when implementing retries:

AAA error	HTTP status	Reason	Retry Strategy
-	`429`	You exceeded your Stedi concurrency limit.	Retry immediately. Monitor your open concurrent requests and immediately replace any finished requests under your Stedi account limit.
`79`	`200`	Stedi successfully sent your request to the payer, but the payer rejected it.	First, retry as soon as possible with a different member and a different NPI. This helps determine whether the issue is with the original request or there is a broader issue with the payer. If you determine the issue is with the payer, follow our guidance for payer connectivity issues.
`79`	`400`	Either Stedi doesn't recognize the payer ID you provided, or the payer is not configured for eligibility checks.	Don't automatically retry. Fix the payer ID or contact Stedi support to resolve.

Errors

You may encounter the following types of errors when submitting eligibility requests.

Stedi payer errors

Stedi returns errors when it encounters issues with the payer ID you provided.

Error message	Possible causes and resolutions
`Payer is not configured for {transaction type}. Please contact Stedi support to resolve.`	Stedi does not yet support this transaction type for this payer, or there is a mis-mapping of payer IDs. Contact us with the name of the payer, and we'll investigate the issue.
`Payer connection does not support {transaction type}. Please contact Stedi support to discuss connectivity options.`	Stedi has a connection to this payer, but it doesn't currently support this functionality (real-time eligibility or claim submission). Contact us for a timeline on enabling it.
`Payer is not configured. Please check our published payer list or contact Stedi support to resolve.`	Stedi doesn't recognize the payer ID you provided. Double-check the payer ID in the Stedi Payer Network, or contact us with the name of the payer, and we will help you determine the correct payer ID.
`Payer is not supported. Please contact Stedi support to discuss connectivity options.`	Stedi doesn't yet have connectivity to this payer. We're likely already working on it - contact us for details about the connectivity timeline.

The following error resulted from an unrecognized payer ID:

{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "TEST2",
  "errors": [
    {
      "code": "79",
      "description": "Invalid Participant Identification",
      "followupAction": "Please Correct and Resubmit",
      "location": "2100A",
      "possibleResolutions": "Payer TEST2 is not configured. Please check our published payer list or contact Stedi support to resolve."
    }
  ],
  "status": "ERROR"
}

Validation errors

Stedi validates the structure of your eligibility request and will not submit your request to the payer if it is missing required fields or if the data is not formatted correctly. The following Stedi validation error resulted from a missing provider object:

{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "CIGNA",
  "errors": [
    {
      "code": "33",
      "description": "Input Errors",
      "followupAction": "Please Correct and Resubmit",
      "possibleResolutions": "Missing required field: provider"
    }
  ],
  "status": "ERROR"
}

Payer AAA errors

When a payer rejects your eligibility check, the 271 response contains one or more AAA Request Validation segments that specify the reasons for the rejection and any recommended follow-up actions. Stedi includes this information in the aaaErrors object in the response JSON.

Common causes for AAA errors include:

Missing or incorrect information for the subscriber, dependent, provider, or payer. In this case, you should correct any errors before resubmitting.
Issues with payer enrollment. Many of these issues require that the provider contact the payer directly to resolve, due to PHI/HIPAA guidelines.
The payer's system is down or experiencing issues. In this case, the payer may not have actually validated the data in your request. If you receive these types of errors, you should wait a few minutes and resend the request again.

Each error contains a followupAction:

Please Correct and Resubmit
Resubmission Not Allowed | Note that this code doesn't mean you should never resubmit the request. Intermediary clearinghouses may send this code when they have temporarily lost connection to the payer, so this code indicates that you should wait at least a few minutes before retrying instead of retrying immediately.
Resubmission Allowed
Do Not Resubmit; Inquiry Initiated to a Third Party | This code is uncommon
Please Resubmit Original Transaction
Please Wait 30 Days and Resubmit | This code is uncommon
Please Wait 10 Days and Resubmit | This code is uncommon
Do not resubmit; We Will Hold Your Request and Respond Again Shortly | This code is uncommon

AAA errors can be present at multiple different levels in the response, depending on the type. The following example shows an error at the subscriber level (subscriber.aaaErrors):

{
  "subscriber": {
    "memberId": "123456789",
    "firstName": "JANE",
    "lastName": "DOE",
    "entityIdentifier": "Insured or Subscriber",
    "entityType": "Person",
    "dateOfBirth": "19001103",
    "aaaErrors": [
      {
        "field": "AAA",
        "code": "75",
        "description": "Subscriber/Insured Not Found",
        "followupAction": "Please Correct and Resubmit",
        "location": "Loop 2100C",
        "possibleResolutions": "- Subscriber was not found."
      }
    ]
  }
}

However, all errors at the payer, provider, subscriber, and dependents levels are also reported in the top-level errors array in the eligibility check response.

Visit Eligibility mock requests to retrieve more examples of common AAA errors in eligibility responses.

To help with troubleshooting, we include additional strings containing possible causes and resolutions for each AAA error. We periodically update this guidance, so these strings may change at any time and may differ between eligibility responses. Don't build programmatic logic that depends on matching these strings exactly.

Payer

You may receive the following types of errors at the payer level.

Code	Description	Possible causes and resolutions
`04`	Authorized Quantity Exceeded	You included too many patients in the request - you can only request benefits information for one patient at a time. When the patient is the subscriber, put their details in the `subscriber` object. When the patient is the dependent, put the subscriber's details in the `subscriber` object and the patient's details in the `dependents` array.
`41`	Authorization/Access Restrictions	The problem is either: An issue with the `provider.npi` or `provider.federalTaxpayersIdNumber`. This typically indicates that the provider isn't properly enrolled with the payer. An issue with the `portalPassword` or `portalUsername` you provided.
`42`	Unable to Respond at Current Time	The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our recommended retry strategy for payer connectivity issues.
`79`	Invalid Participant Identification	There is a problem connecting with this payer. Contact Stedi support.
`80`	No Response received - Transaction Terminated	The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our recommended retry strategy for payer connectivity issues.
`T4`	Payer Name or Identifier Missing	The problem is either: An issue with the `tradingPartnerName` or `tradingPartnerServiceId`. Check the Payer Network to ensure you're using valid values. A payer processing issue. If the issue persists, contact Stedi support to resolve.

Provider

You may receive the following types of errors at the provider level.

Code	Description	Possible causes and resolutions
`15`	Required application data missing	The payer needs more information about the provider requesting the eligibility check. Try including the `provider.taxId`, typically their EIN or SSN.
`41`	Authorization/Access Restrictions	The problem is either: An issue with the `provider.npi` or `provider.federalTaxpayersIdNumber`. This typically indicates that the provider isn't properly enrolled with the payer. An issue with the `portalPassword` or `portalUsername` you provided. The payer may require other credentialing or enrollment processes.
`43`	Invalid/Missing Provider Identification	The problem is either: The `provider.npi` isn't registered correctly with the payer. The payer requires an agreement to begin processing eligibility checks for this provider. Check the Payer Network to determine whether this payer requires transaction enrollment for eligibility checks. If yes, you must submit a transaction enrollment request for the provider. If not, the payer may still require other credentialing or enrollment processes.
`44`	Invalid/Missing Provider Name	The provider's NPI is registered with an incorrect name for this payer. Verify that the `provider.organizationName` or the `provider.firstName` and `provider.lastName` are correct. If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines. The payer may require other credentialing or enrollment processes.
`45`	Invalid/Missing Provider Specialty	The provider's NPI isn't registered with the payer under the correct specialty. The provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines. The payer may require other credentialing or enrollment processes.
`46`	Invalid/Missing Provider Phone Number	The provider's phone number doesn't match the one registered with the payer or the one in the NPPES system. The provider must contact the payer directly to resolve this issue because of PHI/HIPAA guidelines. The payer may require other credentialing or enrollment processes.
`47`	Invalid/Missing Provider State	The `provider.address` either doesn't match the address registered with the payer or it doesn't match the provider's address in the NPPES system. Ensure the information in `provider.address` is correct. If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines. The payer may require other credentialing or enrollment processes.
`48`	Invalid/Missing Referring Provider Identification Number	The referring provider (specified in `subscriber.providerIdentifier`) either: Isn't enrolled correctly with the payer. Contact Stedi support to resolve. Isn't registered with the payer's health plans. The provider must contact the payer directly to complete the registration process. Must complete additional credentialing or enrollment processes with the payer.
`50`	Provider Ineligible for Inquiries	The provider requesting the eligibility check isn't registered with the payer for the service type in `encounter.serviceTypeCodes`. Ensure the `provider.npi` and `encounter.serviceTypeCodes` are correct. If so, the provider must contact the payer directly to complete the registration process. Contact Stedi support with questions.
`51`	Provider Not on File	The provider isn't registered with the payer. Ensure the `provider.npi` is correct. If so, the provider must contact the payer directly to complete the registration process. This can include credentialing and/or enrollment. Contact Stedi support with questions.
`79`	Invalid Participant Identification	There is a problem connecting with this payer. Contact Stedi support.
`97`	Invalid or Missing Provider Address	The payer requires the address for the provider requesting the eligibility check. Retry with the provider's complete address in the `provider.address` object.
`T4`	Payer Name or Identifier Missing	The problem is either: An issue with the `tradingPartnerName` or `tradingPartnerServiceId`. Check the Payer Network to ensure you're using valid values. A payer processing issue. If the issue persists, contact Stedi support to resolve.

Subscriber

You may receive the following types of errors at the subscriber level.

Code	Description	Possible causes and resolutions
`15`	Required application data missing	The payer likely needs more information about the subscriber to complete the eligibility check. We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`. Given this information, all payers must return benefits details as long as they can find a unique match for the member within their system. Visit patient information to learn more. Try including the `provider.taxId`, typically their EIN or SSN.
`33`	Input Errors	The request doesn't meet the payer’s requirements, which usually means it doesn't contain enough information to identify the patient. We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`. Given this information, all payers must return benefits details as long as they can find a unique match for the member within their system. Visit patient information to learn more.
`35`	Out of Network	The subscriber isn't in the provider's network. Verify that the `provider.npi` is valid. If yes, contact the payer for clarification.
`42`	Unable to Respond at Current Time	The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our recommended retry strategy for payer connectivity issues.
`43`	Invalid/Missing Provider Identification	The problem is either: The `provider.npi` isn't registered correctly with the payer. The payer requires an agreement to begin processing eligibility checks for this provider. Check the Payer Network to determine whether this payer requires transaction enrollment for eligibility checks. If yes, you must submit a transaction enrollment request for the provider. If not, the payer may still require other credentialing or enrollment processes. Contact Stedi support to determine next steps.
`45`	Invalid/Missing Provider Specialty	The `provider.npi` isn't registered with the payer under the correct specialty. The provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines.
`47`	Invalid/Missing Provider State	The `provider.address` either doesn't match the address registered with the payer, or it doesn't match the provider's address in the NPPES system. Ensure the information in `provider.address` is correct. If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines.
`48`	Invalid/Missing Referring Provider Identification Number	The referring provider (specified in `subscriber.providerIdentifier`) either: Isn't enrolled correctly with the payer. Contact Stedi support to resolve. Isn't registered with the payer's health plans. The provider must contact the payer directly to complete the registration process. Contact Stedi support with questions.
`49`	Provider is Not Primary Care Physician	The payer doesn’t list the provider as a primary care physician but requires them to be one. The provider or the patient must contact the payer to update their records.
`51`	Provider Not on File	The provider isn't registered with the payer. Ensure the `provider.npi` is correct. If so, the provider must contact the payer directly to complete the registration process. This can include credentialing and/or enrollment. Contact Stedi support with questions.
`52`	Service Dates Not Within Provider Plan Enrollment	The provider wasn't registered with the patient's health plan on the date of service listed in the eligibility check. Verify that the `provider.npi` and the service dates in the `encounter` object are correct. If so, the provider must contact the payer directly to resolve this issue.
`53`	Inquired Benefit Inconsistent with Provider Type Enrollment	The provider isn't registered with the payer to perform the requested benefit type. Some payers only return benefits that match the provider's taxonomy code. Verify that the `provider.npi` is correct. Verify that the `serviceTypeCodes` or the `procedureCode` and `productOrServiceIDQualifier` in the `encounter` object are correct. Check the provider taxonomy you sent in `provider.referenceIdentification`. It should match what's recorded in the payer's system. If the issue persists, the provider must contact the payer directly to resolve.
`54`	Inappropriate Product/Service ID Qualifier	You provided an invalid `encounter.productOrServiceIDQualifier`. Update the request and resubmit.
`55`	Inappropriate Product/Service ID	You provided an invalid `encounter.procedureCode`. Update the request and resubmit.
`56`	Inappropriate Date	The service dates in the `encounter` object are incorrect or are formatted incorrectly. . Dates must be in YYYYMMDD format. We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
`57`	Invalid/Missing Date(s) of Service	The service dates in the `encounter` object are missing, incorrect, or formatted incorrectly. Dates must be in YYYYMMDD format. We recommend submitting dates up to 12 months in the past or up to the end of the current month. We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
`58`	Invalid/Missing Date-of-Birth	The payer needs the subscriber's date of birth for identification. Include `subscriber.dateOfBirth` in the request. The date should be in YYYYMMDD format.
`60`	Date of Birth Follows Date(s) of Service	The date(s) of service you provided are earlier than the subscriber's date of birth. Check the service dates in the `encounter` object. Check the `subscriber.dateOfBirth`. If this eligibility check is for a newborn, resubmit it with the mother's information instead.
`61`	Date of Death Precedes Date(s) of Service	The date(s) of service you provided are after the patient's date of death. Check the service dates in the `encounter` object. Note that if you don't provide a service date in the request, the payer defaults to using the current date in their timezone.
`62`	Date of Service Not Within Allowable Inquiry Period	The payer doesn't support the date(s) of service you provided. Check the service dates in the `encounter` object. We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
`63`	Date of Service in Future	Some payers don't support future date(s) of service. Check the service dates in the `encounter` object. Check the payer's specific requirements.
`69`	Inconsistent with Patient’s Age	The diagnosis codes provided don't match the patient's age. Check the `subscriber.dateOfBirth`. Check any `subscriber.healthCareCodeInformation[].diagnosisCode` values.
`70`	Inconsistent with Patient’s Gender	The procedure codes provided are inconsistent with the patient's gender. Check `subscriber.gender`. Check the values in `encounter.procedureCode` or `encounter.medicalProcedures[].procedureCode`.
`71`	Patient Birth Date Does Not Match That for the Patient on the Database	The subscriber's birth date doesn't match what's in the payer's database. Check that the `subscriber.dateOfBirth` is correct. If so, contact the payer to resolve this issue.
`72`	Invalid/Missing Subscriber/Insured ID	The subscriber's member ID is either missing or invalid. Check the `subscriber.memberId`. Ensure the member ID doesn't include the Card Issuer Identifier. If you can't locate the correct member ID, try running an insurance discovery check to retrieve the patient's benefits information instead.
`73`	Invalid/Missing Subscriber/Insured Name	The payer doesn't recognize the subscriber's name. Verify that the `subscriber.firstName` and `subscriber.lastName` are valid and spelled correctly. Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering patient names.
`74`	Invalid/Missing Subscriber/Insured Gender Code	The payer requires the subscriber's gender code. Ensure `subscriber.gender` is set to a valid value that matches the payer's records.
`75`	Subscriber/Insured Not Found	The payer couldn't locate the subscriber in their database. We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`. Given this information, all payers must return benefits details as long as they can find a unique match for the member within their system. Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering patient names. Sometimes patients provide outdated insurance information for the wrong payer. If the issue persists, try running an insurance discovery check to retrieve the patient's benefits information instead.
`76`	Duplicate Subscriber/Insured ID Number	The payer found another member with the same member ID in their database. Ensure the `subscriber.memberId` is correct.
`78`	Subscriber/Insured Not in Group/Plan identified	The subscriber isn't in the specified health plan. Verify that the `subscriber.memberId` and `subscriber.groupNumber` are correct. If so, contact the payer directly to resolve this issue.
`98`	Experimental Service or Procedure	Contact the payer for guidance.
`Aa`	Authorization Number Not Found	The prior authorization number the payer has on file doesn't match the one you sent. Verify that the `encounter.priorAuthorizationOrReferralNumber` is correct.
`AE`	Requires Primary Care Physician Authorization	The payer requires a prior authorization number. Add the `encounter.priorAuthorizationOrReferralNumber` to your request and resubmit.
`AF`	Invalid/Missing Diagnosis Code(s)	The payer requires one or more diagnosis codes, or the diagnosis codes you provided are invalid. Ensure the information in the `subscriber.healthCareCodeInformation[]` array is correct.
`AG`	Invalid/Missing Procedure Code(s)	The payer requires a procedure code or the procedure code you provided is invalid. Ensure `encounter.productOrServiceIDQualifier` and `encounter.procedureCode` are set to valid values.
`AO`	Additional Patient Condition Information Required	Contact the payer for guidance.
`CI`	Certification Information Does Not Match Patient	The prior authorization number the payer has on file doesn't match the one you sent. Verify that the `encounter.priorAuthorizationOrReferralNumber` is correct.
`E8`	Requires Medical Review	Contact the payer for guidance.
`IA`	Invalid Authorization Number Format	The `encounter.priorAuthorizationOrReferralNumber` wasn't formatted correctly.
`MA`	Missing Authorization Number	You must include a previously issued referral or authorization number in your request. Set the `encounter.referenceIdentificationQualifier` and `encounter.priorAuthorizationOrReferralNumber` properties and resubmit.

Dependents

You may receive the following errors at the dependents level.

Code	Description	Possible causes and resolutions
`15`	Required application data missing	The payer needs more information about the dependent to complete the eligibility check. We recommend providing the dependent's `firstName`, `lastName`, and `dateOfBirth`, when possible. Many payers return errors when the dependent's date of birth is missing. Try including the `provider.taxId`, typically their EIN or SSN.
`33`	Input Errors	The request doesn't meet the payer’s requirements, which usually means it doesn't contain enough information to identify the patient. We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`. We recommend providing the dependent's `firstName`, `lastname`, and `dateOfBirth`.
`35`	Out of Network	The dependent isn't in the provider's network. Verify that the `provider.npi` is valid. If yes, contact the payer for clarification.
`42`	Unable to Respond at Current Time	The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our recommended retry strategy for payer connectivity issues.
`43`	Invalid/Missing Provider Identification	The problem is either: The `provider.npi` isn't registered correctly with the payer. The payer requires an agreement to begin processing eligibility checks for this provider. Check the Payer Network to determine whether this payer requires transaction enrollment for eligibility checks. If yes, you must submit a transaction enrollment request for the provider. If not, the payer may still require other credentialing or enrollment processes. Contact Stedi support to determine next steps.
`45`	Invalid/Missing Provider Specialty	The `provider.npi` isn't registered with the payer under the correct specialty. The provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines.
`47`	Invalid/Missing Provider State Specialty	The `provider.address` either doesn't match the address registered with the payer, or it doesn't match the provider's address in the NPPES system. Ensure the information in `provider.address` is correct. If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines.
`48`	Invalid/Missing Referring Provider Identification Number	The referring provider (specified in `dependents[].providerIdentifier`) either: Isn't enrolled correctly with the payer. Contact Stedi support to resolve. Isn't registered with the payer's health plans. The provider must contact the payer directly to complete the registration process. Contact Stedi support with questions.
`49`	Provider is Not Primary Care Physician	The payer doesn't list the provider as a primary care physician, but requires them to be one. The provider or the patient must contact the payer to update their records.
`51`	Provider Not on File	The provider isn't registered with the payer. Ensure the `provider.npi` is correct. If so, the provider must contact the payer directly to complete the registration process. This can include credentialing and/or enrollment. Contact Stedi support with questions.
`52`	Service Dates Not Within Provider Plan Enrollment	The provider wasn't registered with the patient's health plan on the date of service listed in the eligibility check. Verify that the `provider.npi` and the service dates in the `encounter` object are correct. If so, the provider must contact the payer directly to resolve this issue.
`53`	Inquired Benefit Inconsistent with Provider Type Enrollment	The provider isn't registered with the payer to perform the requested benefit type. Some payers only return benefits that match the provider's taxonomy code. Verify that the `provider.npi` is correct. Verify that the `serviceTypeCodes` or `procedureCode` and `productOrServiceIDQualifier` in the `encounter` object are correct. Check the provider taxonomy in `provider.referenceIdentification` to ensure it matches what's in the payer's system. If the issue persists, the provider must contact the payer directly to resolve.
`54`	Inappropriate Product/Service ID Qualifier	You provided an invalid `encounter.productOrServiceIDQualifier`. Update the request and resubmit.
`55`	Inappropriate Product/Service ID	You provided an invalid `encounter.procedureCode`. Update the request and resubmit.
`56`	Inappropriate Date	The service dates in the `encounter` object are incorrect or are formatted incorrectly. Dates must be in YYYYMMDD format. We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
`57`	Invalid/Missing Date(s) of Service	The service dates in the `encounter` object are missing, incorrect, or formatted incorrectly. Dates must be in YYYYMMDD format. We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
`58`	Invalid/Missing Date-of-Birth	The payer needs the dependent's date of birth for identification. Include `dependents[].dateOfBirth` in the request. The date should be in YYYYMMDD format.
`60`	Date of Birth Follows Date(s) of Service	The date(s) of service you provided are earlier than the dependent's date of birth. Check the service dates in the `encounter` object. Check the `dependents[].dateOfBirth`. If this eligibility check is for a newborn, resubmit it with the mother's information instead.
`61`	Date of Death Precedes Date(s) of Service	The date(s) of service you provided are after the dependent's date of death. Check the service dates in the `encounter` object. Note that if you don't provide a service date in the request, the payer defaults to using the current date in their timezone.
`62`	Date of Service Not Within Allowable Inquiry Period	The payer doesn't support the date(s) of service you provided. Check the service dates in the `encounter` object. We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
`63`	Date of Service in Future	Some payers don't support future date(s) of service. Check the service dates in the `encounter` object. Check the payer's specific requirements.
`64`	Invalid/Missing Patient ID	The payer requires an additional identifier in the `dependents[].additionalIdentification` object. The required identifier is payer-specific. Check the payer's requirements. Don't include the `healthInsuranceClaimNumber` or `medicaidRecipientIdentificationNumber` unless they're different from the member ID.
`65`	Invalid/Missing Patient Name	The payer doesn't recognize the dependent's name. Ensure that the `dependents[].firstName` and `dependents[].lastName` are valid and spelled correctly. Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering patient names.
`66`	Invalid/Missing Patient Gender Code	The payer requires the dependent's gender code. Ensure `dependents[].gender` is set to a valid value that matches the payer's records.
`67`	Patient Not Found	The payer couldn't locate the dependent in their database. We recommend providing the dependent's `firstName`, `lastName`, and `dateOfBirth`. Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering patient names. Sometimes patients provide outdated insurance information for the wrong payer. If the issue persists, try running an insurance discovery check to retrieve the patient's benefits information instead.
`68`	Duplicate Patient ID Number	The payer found another member with the same member ID in their database. Ensure the `subscriber.memberId` is correct.
`69`	Inconsistent with Patient’s Age	The diagnosis codes provided don't match the patient's age. Check the `dependents[].dateOfBirth`. Check any `dependents[].healthCareCodeInformation[].diagnosisCode` values.
`70`	Inconsistent with Patient’s Gender	The procedure codes provided are inconsistent with the patient's gender. Check `dependents[].gender`. Check the values in `encounter.procedureCode` or `encounter.medicalProcedures[].procedureCode`.
`71`	Patient DOB Does Not Match That for the Patient on the Database	The dependent's birth date doesn't match what's in the payer's database. Check that the `dependents[].dateOfBirth` is correct. If so, contact the payer to resolve this issue.
`77`	Subscriber Found, Patient Not Found	The payer identified the subscriber in their database, but not the dependent. We recommend providing the dependent's `firstName`, `lastName`, and `dateOfBirth`. Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering patient names. If the dependent has a unique member ID, you must submit their information in the `subscriber` object instead.
`98`	Experimental Service or Procedure	Contact the payer for guidance.
`AA`	Authorization Number Not Found	The payer didn't recognize the prior authorization number you provided. Ensure the `encounter.priorAuthorizationOrReferralNumber` is correct.
`AE`	Requires Primary Care Physician Authorization	The payer requires a prior authorization number. Add the `encounter.priorAuthorizationOrReferralNumber` to your request and resubmit.
`AF`	Invalid/Missing Diagnosis Code(s)	The payer requires diagnosis codes, or the diagnosis codes you provided were invalid. Ensure the information in the `dependents[].healthCareCodeInformation[]` array is correct.
`AG`	Invalid/Missing Procedure Code(s)	The payer requires a procedure code or the procedure code you provided is invalid. Ensure `encounter.productOrServiceIDQualifier` and `encounter.procedureCode` are set to valid values.
`AO`	Additional Patient Condition Information Required	Contact the payer for guidance.
`CI`	Certification Information Does Not Match Patient	The prior authorization or referral number the payer has on file for the patient doesn't match the one you sent. Verify that the `encounter.priorAuthorizationOrReferralNumber` is correct.
`E8`	Requires Medical Review	Contact the payer for guidance.
`IA`	Invalid Authorization Number Format	The `encounter.priorAuthorizationOrReferralNumber` wasn't formatted correctly.
`MA`	Missing Authorization Number	You must include a previously issued referral or authorization number in your request. Set the `encounter.referenceIdentificationQualifier` and `encounter.priorAuthorizationOrReferralNumber` properties and resubmit.

Card Issuer Identifier (80840)

All health plans use (80840) as the first five digits of the Card Issuer Identifier.

This is a placeholder value used for standards compliance only, and you shouldn't pass it in an electronic eligibility check. However, many providers and OCR systems accidentally pass (80840) in other eligibility check fields. For example, they may try to pass this value as a subscriber or dependent ID, causing an AAA rejection from the payer.

To prevent these types of mistakes, Stedi automatically suppresses any string containing (80840) in the following fields:

JSON	X12 EDI
`subscriber.memberId`	Loop 2100C `NM109` Subscriber Primary Identifier
Any property in `subscriber.additionalIdentification`	Loop 2100C `REF02` Subscriber Supplemental Identifier
Any property in `dependent.additionalIdentification`	Loop 2100D `REF02` Dependent Supplemental Identifier

If the payer's eligibility response returns an AAA error, Stedi returns the following warning:

The field {FIELD} contains the string "(80840)", which is a known
placeholder prefix for a field that should not be provided in {FIELD}.
We have omitted that value in the request, and the request failed.
Please locate the correct value for {FIELD} and resubmit.

To correct this error, read the documentation for the corresponding field, locate the correct value, and resubmit the eligibility check.

SOAP requests

Our Real-Time Eligibility Check SOAP endpoint respects the error handling rules defined in the CAQH CORE vC2.2.0 Rule.

At a high level, you can experience errors in the following categories:

Authentication errors: Either your API key, your Stedi account ID, or both are invalid.
SOAP faults: Issues with the request Envelope or Header elements, such as malformed XML.
CORE-compliant errors: The request don't conform to CAQH CORE rules for eligibility checks.
X12 EDI validation errors: The X12 EDI transaction doesn't match the required format.
Payer AAA errors: Errors from the payer indicating issues with processing your request.

Authentication errors

If the wsse:Username or wsse:Password values are incorrect within the Header element:

Stedi returns an HTTP 401 status code.
The response includes an ErrorCode element set to UnAuthorized.

The following example shows an authentication error response:

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  <soapenv:Body>
    <COREEnvelopeRealTimeResponse>
      <PayloadType>CoreEnvelopeError</PayloadType>
      <ProcessingMode>RealTime</ProcessingMode>
      <PayloadID>01987b7e-56cc-7871-8520-a22721948fb4</PayloadID>
      <TimeStamp>2025-08-06T22:23:50Z</TimeStamp>
      <CORERuleVersion>2.2.0</CORERuleVersion>
      <Payload></Payload>
      <ErrorCode>UnAuthorized</ErrorCode>
      <ErrorMessage>Invalid username and/or password.</ErrorMessage>
    </COREEnvelopeRealTimeResponse>
  </soapenv:Body>
</Envelope>

SOAP faults

SOAP faults indicate issues with the request Envelope or Header elements, such as malformed XML or missing required elements.

When these errors occur:

Stedi returns an HTTP 400 status code.
The response includes a Fault element that contains details about the error. The Fault element always contains a Code and Reason element. The Code element indicates the source of the error and the Reason element provides a description.

The following example shows a SOAP fault response:

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <soapenv:Body>
        <soapenv:Fault>
            <soapenv:Code>
                <soapenv:Value>soapenv:Sender</soapenv:Value>
            </soapenv:Code>
            <soapenv:Reason>
                <soapenv:Text xml:lang="en">Unable to parse payload as CORE SOAP request</soapenv:Text>
            </soapenv:Reason>
        </soapenv:Fault>
    </soapenv:Body>

</soapenv:Envelope>

Visit the SOAP Fault documentation for more details and a complete list of possible error codes.

CORE-compliant errors

These errors typically indicate issues with the COREEnvelopeRealTimeRequest element that contains the request body. However, they can sometimes indicate specific issues with the SOAP Envelope or Header elements, such as an incorrect SOAP version or invalid credentials.

When these errors occur:

Stedi returns an HTTP 400 status code.
The COREEnvelopeRealTimeResponse element contains an ErrorCode and ErrorMessage with a description.
The Payload element is empty because Stedi didn't process the eligibility check.

The following example shows a CORE-compliant error response:

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  <soapenv:Body>
    <COREEnvelopeRealTimeResponse>
      <PayloadType>CoreEnvelopeError</PayloadType>
      <ProcessingMode>RealTime</ProcessingMode>
      <PayloadID>01987b70-2b7e-7b40-9875-10d3139dcf2a</PayloadID>
      <TimeStamp>2025-08-06T22:23:50Z</TimeStamp>
      <SenderID>TestStedi</SenderID>
      <ReceiverID>Stedi</ReceiverID>
      <CORERuleVersion>2.2.0</CORERuleVersion>
      <Payload></Payload>
      <ErrorCode>PayloadIDIllegal</ErrorCode>
      <ErrorMessage>Illegal value provided for PayloadID. Must be a valid UUID</ErrorMessage>
    </COREEnvelopeRealTimeResponse>
  </soapenv:Body>
</soapenv:Envelope>

The following table lists the possible values for ErrorCode and and their causes:

Error Code	Possible Causes
`CORERuleVersionIllegal`	The `CORERuleVersion` element is not set to `2.2.0`.
`CORERuleVersionRequired`	The `CORERuleVersion` element is missing from the request. Set this to `2.2.0`.
`PayloadIDIllegal`	The `PayloadID` element is not a valid UUID.
`PayloadIDRequired`	The `PayloadID` element is missing from the request. This must be a valid UUID.
`PayloadIllegal`	The `Payload` element is empty or doesn't contain a valid X12 EDI 270 transaction.
`PayloadRequired`	The `Payload` element is missing from the request. This must be a valid X12 EDI 270 transaction.
`PayloadTypeIllegal`	The `PayloadType` element is invalid. Set this to `X12_270_Request_005010X279A1`.
`PayloadTypeRequired`	The `PayloadType` element is missing from the request. Set this to `X12_270_Request_005010X279A1`.
`ProcessingModeIllegal`	The `ProcessingMode` element is not set to `RealTime`.
`ProcessingModeRequired`	The `ProcessingMode` element is missing from the request. Set this to `RealTime` for real-time eligibility checks.
`ReceiverIDIllegal`	The `ReceiverID` exceeds the maximum length of 50 characters.
`ReceiverIDRequired`	The `ReceiverID` element is missing from the request. Visit the Request reference documentation for guidance on which identifier to use.
`SenderIDIllegal`	The `SenderID` exceeds the maximum length of 50 characters.
`SenderIDRequired`	The `SenderID` element is missing from the request. Visit the Request reference documentation for guidance on which identifier to use.
`TimeStampIllegal`	The `TimeStamp` element is not in the correct format. It must be in ISO 8601 format, such as `2024-07-28T12:00:00Z`.
`TimeStampRequired`	The `TimeStamp` element is missing from the request.
`UnAuthorized`	The request is unauthorized. This can happen if the `wsse:UsernameToken` is missing or invalid, or if the API key is incorrect.
`VersionMismatch`	The SOAP version in the request does not match the expected version.

X12 EDI validation errors

Validation errors occur when the X12 EDI transaction doesn't conform to the expected 270 X12 EDI format or contains invalid data.

When there are validation errors, Stedi returns an HTTP 400 status code. There are two possible error cases:

Invalid EDI envelope: There are issues with the ISA or GS header. The ErrorCode element is set to PayloadIllegal, and the Payload element is empty because Stedi couldn't parse the request.

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body>
    <COREEnvelopeRealTimeResponse>
      <PayloadType>CoreEnvelopeError</PayloadType>
      <ProcessingMode>RealTime</ProcessingMode>
      <PayloadID>01987c0b-c8b3-71c1-bd6f-8e26725c7110</PayloadID>
      <TimeStamp>2025-08-06T22:23:50Z</TimeStamp>
      <SenderID>RECEIVER-ID</SenderID>
      <ReceiverID>SENDER-ID</ReceiverID>
      <CORERuleVersion>2.2.0</CORERuleVersion>
      <Payload></Payload>
      <ErrorCode>PayloadIllegal</ErrorCode>
      <ErrorMessage>Error while getting metadata for an X12 file: Error reading EDI: Invalid ISA: ISA-11 must be 'U' for interchange control versions earlier than 00402</ErrorMessage>
    </COREEnvelopeRealTimeResponse>
  </soapenv:Body>
</soapenv:Envelope>

Invalid EDI transaction: Stedi successfully parsed the EDI envelope, but there are validation issues with the rest of the transaction. The ErrorCode element is set to Success, and the Payload element contains a 999 Implementation Acknowledgment describing the errors. This 999 is usually from Stedi, but it can also be from the payer.

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  <soapenv:Body>
    <COREEnvelopeRealTimeResponse>
      <PayloadType>X12_999_Response_005010X231A1</PayloadType>
      <ProcessingMode>RealTime</ProcessingMode>
      <PayloadID>01987c11-ae2e-7f63-801d-cb3529f45952</PayloadID>
      <TimeStamp>2025-08-06T22:23:50Z</TimeStamp>
      <SenderID>RECEIVER-ID</SenderID>
      <ReceiverID>SENDER-ID</ReceiverID>
      <CORERuleVersion>2.2.0</CORERuleVersion>
      <Payload><![CDATA[ISA*00*          *00*          *ZZ*RECEIVER       *ZZ*SENDER         *250806*1910*^*00501*000000001*0*T*:~GS*FA*STEDI*117151744*20250806*191051*10*X*005010X231A1~ST*999*0001*005010X231A1~AK1*HS*1*005010X279A1~AK2*270*1234*005010X279A1~IK3*BHT*2**8~IK4*4*373*8*20240321!1319~IK4*5**1~IK3*BHT*2**8~IK4*4*373*8*20240321!1319~IK4*5**1~IK5*R*5~AK9*R*1*1*0~SE*12*0001~GE*1*10~IEA*1*000000001~]]></Payload>
      <ErrorCode>Success</ErrorCode>
      <ErrorMessage/>
    </COREEnvelopeRealTimeResponse>
  </soapenv:Body>
</soapenv:Envelope>

Eligibility troubleshooting

Payer unable to find patient

Multiple matching records

Information discrepancies

Name mismatches

Retry strategy

Payer connectivity issues

Real-time eligibility checks

Scheduled eligibility checks

Other common error cases

Errors

Stedi payer errors

Validation errors

Payer AAA errors

Payer

Provider

Subscriber

Dependents

Card Issuer Identifier (80840)

SOAP requests

Authentication errors

SOAP faults

CORE-compliant errors

X12 EDI validation errors

On this page