Common eligibility failure modes and how to fix them

It’s 3 AM. You’re on-call and just got paged. A customer – a 24-hour hospital in Des Moines – can’t verify patient coverage. Every eligibility check they send is failing.

You’re staring at a cryptic AAA error. More failures, now from other customers, are starting to come in. Account management wants answers.

You don’t know where to start. Is it your system? Your clearinghouse? The payer?

—

We’ve been there. Healthcare billing is a distributed system with multiple single points of failure. Even if you do everything right, things break: a payer goes down, a provider enters the wrong data, a request times out.

Stedi’s helped hundreds of teams debug eligibility issues.

This guide outlines the real-world scenarios where we’ve seen eligibility checks fail – and what we’ve found works. You’ll find common failure patterns, diagnostic tips, and how Stedi helps resolve each scenario.

For more tips, check out Eligibility troubleshooting in the Stedi docs.

You’re getting AAA 42 errors – a payer is down

Payer outages are common and often opaque. When you get an AAA 42 (Unable to Respond at Current Time) error or see a spike in timeouts for a specific payer, it usually means one of the following:

• The payer is having intermittent issues. They’re down for now but may be back up shortly.

• The payer is having a prolonged outage. This can be because of planned maintenance or a system failure on their end.

• An intermediary clearinghouse that connects to the payer – not the payer itself – is down.

These scenarios return the same errors, so it's hard to tell them apart.

What you’ll see

• AAA 42 errors from the payer

• A spike in timeouts for requests to the payer.

• Requests that fail even after retries

• Increased latency on failures

An example AAA 42 response:

{
 "errors": [
    {
      "field": "AAA",
      "code": "42",
      "description": "Unable to Respond at Current Time",
      "followupAction": "Please Correct and Resubmit",
      "location": "Loop 2100A",
      "possibleResolutions": "This is typically a temporary issue with the payer's system, but it can also be an extended outage or the payer throttling your requests (https://www.stedi.com/docs/healthcare/send-eligibility-checks#avoid-payer-throttling)."
    }
  ],
  ...
}

What helps
Whether it’s a full-blown outage or just a flaky payer, the remediation steps are the same:

• Check with Stedi to confirm the issue.
  
  

• If you’re using Stedi’s Eligibility API, retry the requests with exponential backoff. For suggested retry strategies, see Retry strategy in the Stedi docs.
  
  This is the most important remediation step. Most Stedi customers simply give up on retries too early. You’re not billed for eligibility checks that return a AAA 42 error, so there’s little incentive not to retry.

Avoid using cached or stale responses. This can cause false positives, which ultimately lead to denied claims.

What Stedi does
Where possible, Stedi uses multiple, redundant payer routes with automatic failover and retries to minimize the impact of intermediary clearinghouse outages. In many cases, our customers don’t notice an outage.

If the payer itself is down – or their designated gateway clearinghouse is down – there's no workaround. No clearinghouse can get traffic through. For widespread outages, we reach out to the payer or the gateway clearinghouse – and we notify affected customers in Slack or Teams.

A patient says they're covered, but eligibility checks return "Subscriber/Insured Not Found"

Payers can only return an eligibility response if the request matches exactly one member in their system.

If they can’t find a match, they return an AAA 75 (Subscriber/Insured Not Found) error. That usually means one of two things:

• The patient isn’t in the payer’s system.

• The patient information in the request doesn’t match what the payer has on file

What you’ll see
An AAA 75 error in the eligibility response. For example:

{
  "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."
      }
    ]
  }
}

You may also see:

• AAA 15 – Required Application Data Missing

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

• AAA 73 – Invalid/Missing Subscriber/Insured Name

What helps
In your app or support flow, prompt the provider to:

• Check that the member ID matches what’s on the insurance card. Include any prefix or suffix.

• 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. Ask about recent name changes.

• If the details look correct, make sure you’re sending the request to the right payer.

Note: Some payers allow a match even if either the first name or DOB is missing (but not both). If you’re not sure about the first name’s spelling, omitting it may improve your chances of a match. Most payers aren’t strict about matching first names exactly.

What Stedi does
Stedi offers real-time support for eligibility issues over Slack and Teams. We’ve helped customers quickly diagnose data mismatches by highlighting exactly where the payer couldn’t find a match. Our support team responds within minutes and can spot common formatting issues that might otherwise take hours to debug.

You get a valid eligibility response, but it’s missing benefits

This usually comes down to the Service Type Code (STC) in the request. In requests, the STC tells the payer what kind of benefits you’re asking for, like medical, dental, or vision.

STCs are standardized, but payers don’t have to support all of them. Some payers only respond to a small set. Payers also don’t return benefits for STCs not covered by the related plan.

The only way to know which STCs a payer or plan supports is to test. For tips, check out How to pick the right STC (when there isn’t one).

What you’ll see
If you’re using Stedi’s Eligibility API, most benefit details come back in the benefitsInformation object array. Each object in the array has a serviceTypeCodes field.

• If no benefitsInformation objects include the requested STC, the payer or the plan probably doesn’t support the STC.
  
  

• If the STC shows up but the details you need aren't there, be sure to check any other returned STCs. Some payers return patient responsibility information under STC 30, while others may use a more specific STC code. If you still can’t find the details, the payer may not return that data in eligibility responses. 

If the response includes your STC but still lacks enough detail to determine whether the service is covered and the patient responsibility, you may need to get the missing information by calling the payer or using their portal. Some teams do this programmatically with an AI voice agent or portal scraping.

What helps

• Check that you're using the right STC.
  
  For a cheat sheet, see How to pick the right STC. For a full list, see Service Type Codes in the Stedi docs.
  
  

• Re-run the request with a baseline STC (like STC 30 for medical or STC 35 for dental).
  
  

• Test different STCs against the baseline to see what each payer supports.

What Stedi does
We’ve tested thousands of payer responses. In addition to our How to pick the right STC blog, we maintain internal payer-specific guidance on which STCs return which benefits. If a payer omits key details, we help teams explore alternatives – whether that’s trying another STC, making a payer call, using the payer portal, or a mix.

The patient doesn’t know their payer or member ID

Eligibility checks only work if the payer can match the request to one specific member. Some payers can match using just name and date of birth. Others require a member ID. All eligibility checks require a payer ID.

What you’ll see
If you don’t know the payer, you can’t submit a check – you don’t know which payer to send it to.

If you leave out the member ID and the payer requires it, you’ll likely get an AAA 72 (Invalid/Missing Subscriber/Insured ID) error.

What helps
Use insurance discovery. It lets you search for active coverage using basic demographic info like name, DOB, ZIP code, and SSN.

Success rates vary depending on the provided patient data – from 25% with basic info to 70%+ with more comprehensive details. For tips, see How to use insurance discovery.

What Stedi does
Getting insurance discovery right out of the gate can be tough. If you’re getting started, our team can help you set up workflows and provide prompts to ensure you get the most out of it.

How would I know if Stedi is down?

Outages are extremely rare for Stedi. We run entirely on AWS with a redundant, multi-region cloud architecture, and we have automated systems for deployment safety. We also maintain redundant routes for payers wherever possible, so a single intermediary clearinghouse or even a widespread payer outage won’t take us down.

What you’ll see

• A notice on our status page

• 500 HTTP status code errors when running eligibility checks.

What helps
Contact Stedi.

What Stedi does
If an outage does happen, we reach out to affected customers immediately in Slack and Teams. We also update our status page. You’ll get clear status updates, including timelines and next steps.

Behind the scenes, our team works across regions to fix the issue fast. Once it’s resolved, we share what went wrong with customers and what we’re doing to make sure it doesn’t happen again.

Don’t debug alone

Eligibility failures happen. With so many players – payers, intermediaries, gateways, providers – it’s not a matter of if, but when one makes a mistake. When your eligibility checks fail, your clearinghouse should help.

If you’re seeing one of these issues – or something new – reach out. We can help.