If you’ve run your numbers through two or three benefit screeners and gotten Medicaid eligibility answers that flatly contradict each other, the culprit is often not a bug in the arithmetic. It’s a missing branch in the logic. Medicaid is not one program with one income test — it is a federal-state partnership where the eligibility rules genuinely diverge depending on whether your state adopted the expansion pathway created under the Affordable Care Act. A screener that doesn’t explicitly account for that divergence isn’t giving you a rough estimate. It’s giving you an answer to a different question than the one you asked.
What actually changes between expansion and non-expansion states
Before expansion existed as an option, most state Medicaid programs restricted adult eligibility along two dimensions at once: income and category. “Category” meant you generally needed to fit into a recognized group — pregnant, a parent of a minor child, over 65, or meeting disability criteria — before your income was even evaluated. Being low-income wasn’t sufficient on its own for most working-age adults without children.
The expansion pathway changed the categorical piece for states that adopted it. In an expansion state, adults within a certain income band can qualify based on income alone, without needing to fit one of the older categorical boxes. That’s a structural change, not just a generosity increase. It means the eligibility test itself has a different shape depending on geography.
This matters for screening tools because two states can show a household with identical income and identical household composition landing in completely different places:
- In an expansion state, that household might land solidly within Medicaid’s income range as an adult-only household, no other qualifying trait needed.
- In a non-expansion state, that same household might be evaluated only against the older, generally lower income thresholds that apply to specific categories — and if no one in the household fits a recognized category, income level almost doesn’t matter. They’re simply not being evaluated on the expansion pathway because it doesn’t exist where they live.
The income thresholds themselves also differ by state and by category, and they get revised periodically. This article isn’t going to hand you a number, because the number depends on your state, your household size, and the date you’re reading this — and quoting one here would go stale and potentially mislead you. What you should be checking on your state’s official Medicaid site or through your state’s health insurance marketplace is (1) whether your state expanded Medicaid at all, and (2) what the current income thresholds are for the category that applies to your household. Those two facts, confirmed at the source, are what any screener result should be measured against.
How some tools hardcode one assumption for all fifty states
Building a screener that correctly branches on expansion status is more work than building one that doesn’t. A developer has to maintain a lookup table of which states have expanded, keep it updated as legislatures revisit the question, and route each user through the correct set of income tests based on that status. A simpler — and cheaper — way to build a national tool is to pick one assumption and apply it everywhere.
In practice, this shows up in a few recognizable patterns:
- The optimistic default. The tool assumes expansion rules apply nationally, because that’s the simpler single income test to code, and because it produces a friendlier, more inclusive-looking result. Users in non-expansion states get told they likely qualify for Medicaid based on income alone, when in their actual state they would also need to meet a categorical requirement that the tool never asked about.
- The conservative default. The tool assumes the older categorical model everywhere, asking about pregnancy, dependent children, age, or disability status as gatekeeping questions before it even looks at income. Users in expansion states who don’t fit any of those categories get screened out immediately, even though their state would actually evaluate them on income alone.
- The stale lookup table. The tool does branch by state, but the underlying table hasn’t been updated since it was built, and expansion status has changed since then in a state or two. This is a slower-moving error but a real one, since expansion adoption has continued to shift as individual state legislatures and ballot measures revisit the question.
None of these patterns necessarily reflect bad faith. A screener aimed at a general audience, built with a limited budget, often has to choose between complexity and maintainability, and eligibility logic that branches fifty ways is expensive to build and keep current. The problem is that the tool rarely tells you which shortcut it took. It just presents a single, confident-looking result with no visible seam where the assumption was made.
Why a coverage gap can appear invisible in a poorly built calculator
One of the more consequential quirks of non-expansion states is what’s often called the coverage gap: a band of income that is simultaneously too high to qualify for the state’s traditional, categorical Medicaid and too low to qualify for subsidized marketplace coverage, which generally has a income floor built into its own eligibility formula. Households in that band aren’t ineligible for one program and eligible for another — they can be genuinely unmatched by either, in a state that didn’t adopt expansion.
This gap is easy to code around by accident, not because a developer wants to hide it, but because most calculators are built as a chain of independent yes/no checks rather than a map of the whole landscape. A typical flow might work like this: first check Medicaid eligibility using whichever assumption the tool has hardcoded; if that returns no, move on and check marketplace subsidy eligibility using its own separate formula; if that also returns no, display a generic “you may not qualify based on the information provided” message.
Nothing in that flow is technically wrong. Each individual check may be computing its own eligibility test correctly. But the output collapses two very different situations into the same flat sentence. “You don’t qualify for either program” reads identically whether you’re a household with income too high for any program by a wide margin, or a household sitting squarely inside a coverage gap that exists specifically because of your state’s policy choice. The first case is a normal negative result. The second is a structural feature of your state’s decision not to expand, and it’s worth knowing which one you’re looking at — not because it changes what programs you can access, but because it explains why the result feels inconsistent with what you might have heard about Medicaid income limits elsewhere.
A well-built tool will name the gap explicitly when a household lands in it, usually with language along the lines of “your income falls in a range not currently covered by either program in your state.” A tool that just returns a flat no for both programs, with no distinguishing language, isn’t wrong about the individual checks — it’s just not telling you the whole story, and it’s on you to notice the silence.
Checking whether a tool actually reflects your state’s expansion status
Since you can’t always tell from the output whether a screener handled this correctly, it helps to test the tool directly before trusting its answer. A few concrete checks:
- Look for a state selector that actually changes the questions asked, not just the branding. If a tool asks the exact same sequence of questions regardless of which state you pick — same categorical questions, same income thresholds displayed — that’s a sign it’s running one national assumption rather than branching correctly.
- Confirm your state’s expansion status independently first. Your state’s official Medicaid agency site or your state’s ACA marketplace site will state plainly whether your state has expanded Medicaid. Know that answer before you run any screener, so you can check the tool’s behavior against a fact you already hold rather than letting the tool tell you something you have no way to verify.
- Watch for categorical gatekeeping questions in a state you know has expanded. If you’re in an expansion state and a tool asks you upfront whether you’re pregnant, disabled, or a parent before it will even consider your income, and offers no path forward if you answer no to all of them, it’s likely running non-expansion logic on you incorrectly.
- Watch for the absence of any categorical questions in a state you know hasn’t expanded. If you’re in a non-expansion state and a tool evaluates you purely on income with no follow-up about category, it may be overstating your eligibility by applying expansion-style logic where it doesn’t exist.
- Check the date the tool claims to reflect. Expansion status and income thresholds have both changed in individual states over time. A tool with no visible “last updated” indicator, or one that hasn’t been touched in a year or more, is a candidate for the stale-lookup-table problem, especially if your state has had any recent legislative activity on the topic.
- Treat a screener result as a hypothesis, not a verdict. Regardless of how a tool is built, the only way to get a determination that actually counts is applying through your state’s Medicaid agency or marketplace directly. The screener’s job is to help you decide whether that application is worth your time, not to substitute for it.
None of this means generic screeners are useless — they’re often a reasonable first pass, especially for programs like SNAP or LIHEAP where the state-by-state structural variation is smaller. Medicaid is simply one of the places where the underlying program isn’t uniform across the country, and a tool’s convenience depends entirely on whether it was built to reflect that unevenness or built to paper over it. The fastest way to tell the difference is to already know your own state’s expansion status before you start, so you have something solid to check the tool’s assumptions against.
