Why Eligibility Verification Fails for the Same Payers Every Month

The list your front desk already knows by heart

Ask anyone at your front desk which payers fail eligibility checks and they will answer before you finish the question. The same four or five names, every month. They will also tell you what they do about it: run the check again, then log into the payer portal, then pick up the phone.

That workaround is treated as a fact of life, a cost of taking that payer's patients. It is not. A failure that repeats against the same payer every month is not bad luck and it is not a diligence problem at the desk. It is a structural problem that a retry will never fix, and in most practices nobody has ever sorted the failures to find out which structure it is.

Electronic eligibility is nearly universal. That is the confusing part

On paper, eligibility is a solved problem. The 2024 CAQH Index put health plan adoption of electronic eligibility and benefit verification at 96 percent for medical, across roughly 31.5 billion checks a year. Eligibility is about half of all administrative transaction volume in medicine.

The same report counted about 3.8 billion checks that were still done partially electronically, which mostly means portals, and roughly 630 million done by phone, fax or email. On the provider side, CAQH priced an electronic check at about 2 dollars of staff cost, a portal check at about 4.46, and a manual one at about 8.57. It put the provider savings still on the table from moving the rest to fully electronic at 11.5 billion dollars a year.

Read those two facts together. The rails exist, the payers support them, and billions of checks still fall off them onto a person. Some of that is habit. Part of it is the pattern this article is about: an electronic check that fails, gets retried, fails the same way, and then gets done by hand. The practice paid for the automation and is paying for the manual check too.

The rejection already tells you why

When an electronic eligibility request fails, the payer's 271 response does not just say no. It returns a rejection code, called an AAA code, that names the reason. Most practice management systems surface it somewhere. Very few practices do anything with it except read it one patient at a time.

The codes sort into two families, and the difference is the whole point.

The first family is transient. Code 42 means the payer is unable to respond at the current time. Code 80 means no response was received. These are downtime, throttling, and connectivity. Stedi's eligibility troubleshooting documentation recommends retrying these automatically, and that is correct. A retry is the right answer to a payer that is briefly down.

The second family is structural. Code 72 is an invalid or missing subscriber ID. Code 73 is an invalid or missing subscriber name. Code 75 is subscriber not found. Code 79 points at the payer identification itself. None of these get better on the second attempt. The request that failed at 8:02 will fail identically at 8:03, and at 8:03 next month, because nothing about the request changed.

A front desk that retries everything is treating both families the same way. One of them it should retry. The other it should route somewhere, and the somewhere is usually not the front desk.

Three reasons the same payer fails every month

Sorted by payer and by code, the recurring failures tend to land in a small number of causes. Here are the three that come up most.

The payer wants something your request does not carry. Some payers require more than the standard fields. Stedi documents Medi-Cal, Kern Family Health Care and AltaMed as requiring a provider PIN on the eligibility request itself. If your system is not configured to send it, every check against that payer fails, for every patient, forever. Nobody at the desk can fix that by typing more carefully. It is a one-time configuration change that nobody has been asked to make.

Your provider is not enrolled the way the payer thinks. A provider who is not properly enrolled with a payer, or is enrolled under a different NPI, tax ID or location than the one on the request, will be rejected consistently regardless of how accurate the patient data is. This one looks like a patient problem at the desk and it is not. It belongs to credentialing, and it is often a symptom of a location or roster change that was never pushed to that payer in that payer's format.

Your data and the payer's matching logic disagree about a format. Names with hyphens, suffixes, and apostrophes. Member IDs with or without a prefix. Dates entered one way and matched another. Plan products that share a card design but route to a different payer ID. Each payer has its own matching behaviour, and a practice sees the same subscriber not found against the same payer because the same kind of record meets the same rule every time.

The first cause is a configuration fix. The second is an enrollment fix. The third is a registration standard. Not one of them is a front desk effort problem, which is why training the front desk again has not moved it.

Why nobody sorts them

The data is sitting there. The reason it never gets used is who touches it.

An eligibility failure is resolved at the moment of check-in, by a person whose job at that moment is getting the patient into a room. The workaround succeeds, the patient is seen, and the failure disappears into the day. No one is asked to count them. The front desk is measured on throughput, credentialing is measured on enrollment dates, and billing sees the consequence weeks later as a denial with a different code on it.

That consequence is real. Experian Health's 2025 State of Claims survey of 250 revenue cycle leaders found missing or inaccurate data was the most cited cause of denials, at 50 percent of respondents, and incomplete or inaccurate registration data was cited by 32 percent. We covered what those downstream denials cost in rework, and the short version is that the eligibility failure nobody logged at 8:02 is often the denial somebody works by hand a month later.

What this means before you buy anything

Eligibility verification is a crowded category. Clearinghouses, RPA vendors, verification outsourcers, and now AI agents that will log into payer portals on your behalf. Some of these are useful. But notice what most of them sell: a faster or cheaper way to perform the check, including the check that fails.

An AI agent that works a payer portal every time the electronic check rejects is, for the structural failures, automating the workaround. It will do it tirelessly and it will be billed per transaction. Meanwhile the missing PIN stays missing and the enrollment gap stays open. You end up with a very efficient process for not fixing a configuration setting. That is the same trap we described in prior authorization, where automating submission without fixing what gets submitted just produces denials faster.

The questions that decide whether a tool is the answer are ones your own data can answer first:

• What share of your eligibility failures are transient codes, and what share are structural?
• Of the structural ones, how concentrated are they by payer? If three payers account for most of the volume, you probably have three fixes, not a platform purchase.
• For the payers that fail every month, has anyone checked enrollment and payer-specific request requirements, or has the desk been absorbing it?
• When a check fails and gets done by hand, does anyone record that it happened?

If the answers show a long tail of genuinely varied failures across many payers, a better tool may earn its keep. If they show a handful of payers failing for a handful of reasons, the fix is cheaper than any demo you will be shown, and it should come before one. The math in our piece on automation ROI applies here: a tool priced against your current failure volume is priced against a baseline you have not cleaned up yet.

The honest edge

An article can tell you that your recurring eligibility failures are almost certainly structural, and that the rejection codes already sort them. It cannot tell you which of your payers are failing for which reason, whether the root is configuration, enrollment or registration, or how much of your manual verification volume disappears once those are fixed. That takes pulling your 271 responses and sitting with your credentialing records for a while.

If your front desk can name the payers that fail every month, the problem is already diagnosed in their heads and nowhere else. Talk to us about sorting your eligibility failures, and whether the answer is a tool, a setting, or an enrollment fix nobody was asked to make.