Most COBRA articles read like a compliance flashcard: 20 employees, qualifying event, 18 or 36 months, send the notice. That’s technically right-and it’s also why so many teams get blindsided. In practice, COBRA eligibility isn’t where employers fail because they “didn’t know the rule.” They fail because they can’t prove what happened when HR, payroll, the carrier, and the COBRA administrator all have slightly different versions of the truth.
So here’s the less-talked-about reality: COBRA eligibility is a data-integrity requirement disguised as a benefits rule. If you can’t reliably answer who was covered, when coverage was active, which event triggered rights, and whether the right notices went to the right people on time, you don’t have an eligibility process-you have a reconstruction problem waiting to happen.
The COBRA question you actually have to answer
At the center of most disputes is a deceptively simple test: was the person covered under the plan the day before the qualifying event? That “day before” standard sounds clean until you try to execute it with real systems, real file feeds, and real-world timing issues like end-of-month terminations, retro changes, and carrier processing lags.
If your organization treats COBRA as “something the vendor handles,” it’s easy to miss that the highest-risk moments happen upstream-when your systems decide (or fail to decide) that someone is eligible, and when they record (or fail to record) the evidence you’ll need later.
Start with the right unit: the qualified beneficiary
COBRA rights attach to a Qualified Beneficiary (QB), not simply “the employee.” That’s a big deal operationally because COBRA isn’t just a continuation option for one person-it’s often multiple people with their own rights tied to the same event.
- The covered employee (if covered the day before the event)
- The employee’s spouse (if covered the day before the event)
- The employee’s dependent child(ren) (if covered the day before the event)
The common failure here is structural: many HR and benefits setups treat dependents as “fields” on the employee record rather than as individuals with their own coverage states. When a qualifying event hits, spouse and dependent records are incomplete, outdated, or never properly enrolled in the first place-so the COBRA offer is incomplete too.
The “20 employees” rule isn’t a headcount shortcut
COBRA generally applies if an employer had 20 or more employees on more than 50% of its typical business days in the prior calendar year. That’s not a casual headcount check; it’s a measurement methodology.
Two details regularly cause trouble:
- Part-time employees count, typically as a fraction of a full-time equivalent based on hours.
- Controlled group rules can require aggregating related entities under common ownership.
Employers that hover around the threshold-common in hospitality, retail, staffing, and franchise structures-can get caught assuming they’re exempt without a defensible calculation. If you can’t reproduce your prior-year determination with documentation, you’re relying on memory instead of compliance.
COBRA applies to group health plans, not “anything health-related”
COBRA continuation obligations generally attach to a group health plan (think medical, dental, vision, and certain other arrangements depending on how they’re structured). It does not apply to benefits like life insurance or disability.
The modern twist is that benefit stacks aren’t tidy anymore. Telehealth-only programs, onsite clinics, EAPs with clinical components, and account-based designs can blur the line between what’s COBRA-covered and what isn’t. The fix isn’t guesswork-it’s classification: document what each component is, how it’s sponsored, and how it ties back to plan documentation and administration.
The “day before” rule is where systems drift becomes legal risk
COBRA eligibility often hinges on timing details that don’t show up in a policy summary. Here’s what creates the mess:
- Termination date vs. last day worked
- Coverage ending end-of-month vs. ending on the event date
- Payroll/HRIS showing “active” while the carrier file shows “termed”
- Retroactive changes made after the fact due to processing or eligibility cleanups
When those records don’t reconcile, the question stops being “what does COBRA say?” and becomes “what can we prove?” That’s why COBRA should be designed like a traceable process, not a one-time notice event.
Gross misconduct: a high-stakes eligibility shortcut
Yes, COBRA can be denied in cases of termination for gross misconduct. But it’s narrowly interpreted and can be very risky to apply casually.
If you deny COBRA and your rationale doesn’t hold up, you’ve created a benefits denial situation that can escalate quickly. Many organizations are better served by treating gross misconduct as a decision that requires formal review and documented support-not an informal label attached at termination.
Dependents are where COBRA eligibility quietly breaks
COBRA compliance often unravels not on the employee record, but on the dependent side-especially when dependent verification audits and retroactive updates are involved.
A particularly underappreciated issue: retroactive dependent terminations can overwrite history. If your system simply “corrects” a dependent’s eligibility retroactively, you may accidentally eliminate the documentation that supports QB status, notice delivery, or election rights. Even when the employer ultimately has a defensible position, retro edits can make it painfully hard to demonstrate what coverage looked like at the moment it mattered.
Eligibility isn’t complete until you can prove notice timing
COBRA is time-sensitive. So the eligibility question includes more than “who qualifies.” It also includes whether your process reliably detected the qualifying event, validated who the QBs were, and triggered the correct notices within required timeframes.
Breakdowns often come from very practical gaps:
- Divorce or dependent status changes reported late (or to the wrong channel)
- Missing addresses for spouses/dependents
- Incomplete event codes sent to the COBRA administrator
- An assumption that carrier termination automatically triggers COBRA (it doesn’t)
Even if a vendor generates notices, you still need a clean chain of evidence showing what the vendor received and when. Outsourcing administration doesn’t eliminate the need for governance.
A better way to run COBRA: track states, not paperwork
If you want COBRA eligibility to be reliable-and defensible-model it like a system with defined states and logged transitions. That means tracking two parallel stories: the person’s coverage status and the qualifying event workflow.
1) Coverage eligibility states (per person)
- Active covered
- Active not covered (waived/ineligible)
- Terminated (with coverage end date)
- COBRA offered (not elected)
- COBRA elected (paid/active)
- COBRA terminated (reason-coded)
2) Qualifying event workflow states (per event)
- Event detected (source recorded)
- Event validated (QB roster confirmed)
- Notice triggered (timestamp + method)
- Election pending
- Election accepted/denied (with reason)
- Coverage reinstated (carrier confirmation)
Most COBRA failures are “state mismatch” failures-coverage terminated at the carrier but the election notice never went out, the employee event was processed but dependents were never instantiated as QBs, or COBRA was elected and paid but reinstatement failed due to a file or timing issue. A state model surfaces those mismatches early, when you can still fix them.
What to do next: five practical controls
If you want to lower COBRA risk without turning your team into compliance detectives, focus on controls that make eligibility provable and repeatable.
- Adopt a QB-first mindset: treat spouses and dependents as individuals with coverage states, not just attachments to the employee record.
- Preserve “as-of” eligibility: don’t allow retroactive edits to overwrite historical states without a controlled process and audit trail.
- Standardize event coding: termination vs. reduction in hours vs. loss of dependent status should be unambiguous across HRIS, payroll, and vendor feeds.
- Instrument your notice process: log when the event was known, when it was sent to the vendor, when notices were generated, and which QBs received them.
- Reconcile elections and reinstatements: confirm that paid elections reliably result in carrier reinstatement, and capture proof.
The bigger takeaway
COBRA eligibility requirements aren’t just legal definitions-they’re a stress test for your benefits infrastructure. When your eligibility data, dependent governance, and event workflows are tight, COBRA becomes predictable. When they’re loose, COBRA turns into a costly exercise in reconstructing timelines after the fact.
Fix the data model and the process, and COBRA stops being a recurring fire drill. It becomes what it was always supposed to be: a defined, trackable continuation right administered consistently, with confidence and proof.