You've been told Health Reimbursement Arrangements are the cure-all for rising premiums. A consumer-driven solution that gives employees choice while keeping costs in check. But after spending over a decade inside benefits architecture, I've watched too many HRAs implode not because the concept is flawed, but because the setup is structurally backward.
Most HRAs are built like compliance aircraft carriers designed to solve a rowboat problem. Employers draft ERISA documents and run 105(h) tests before asking the question that matters: What behavior are we funding?
What Standard HRA Setups Focus On
Standard HRA setups focus on three things:
- Comparability rules (nondiscrimination testing under 105(h))
- ERISA document drafting (the plan document, SPD, trust agreements)
- Integration logic with a group health plan, individual coverage, or Medicare, depending on the HRA type
All three are necessary, and none of them is strategic. The real problem is that HRAs are backward-looking expense accounts pretending to be forward-looking health tools.
- A standard HRA pays after a claim occurs → employee gets care → employer pays the bill
- A prevention-first design pays for preventive action → employee gets healthier → the claim never happens → savings accumulate
The compliance framework doesn't have to change. The funding trigger does, and that shift moves dollars from paying sickness to funding prevention.
Three Compliance Rules Most HRA Setups Get Wrong
1. Section 105(h) Nondiscrimination Testing
If your HRA is self-insured, and most are, you're subject to IRC Section 105(h) nondiscrimination testing. The rules aren't impossible. The documentation is where plans fail. Plans most often fail when the design passes testing on paper but the enrollment data, claim substantiation, and employee classification records don't match the plan document.
The fix is operational discipline. Build the audit trail into your enrollment system from day one. Most platforms treat compliance as a monthly report you run later. Smarter systems treat it as a data-validation gate at setup.
2. COBRA Continuation Coverage
An employer sets up an HRA. Everyone loves it. Then someone quits, and you're funding claims for a former employee under COBRA. If the plan documents don't have proper spend-down provisions, you can end up liable for months of medical expenses you never budgeted for.
HRAs are group health plans, so COBRA applies. IRS Notice 2002-45 is explicit: a compliant HRA continues the participant's maximum reimbursement amount, adjusted for further contributions and reimbursed claims, and COBRA must be offered even when the plan has a spend-down provision that lets a departing employee use remaining funds.
A debit card with auto-substantiation is a legitimate operational tool here. It matches each transaction to a qualified expense at the point of sale and keeps the account balance current. It doesn't extinguish COBRA. The continuation obligation ends only when the defined benefit is exhausted or the COBRA period runs out.
3. Medicare Secondary Payer and Part D Creditable Coverage
An employee turns 65 and enrolls in Medicare, and two rule sets now sit next to your plan. Under Medicare Secondary Payer rules, an employer with 20 or more employees can't treat an active employee differently because they turned 65. The plan must offer the same benefits on the same terms, and you can't offer a financial incentive to drop it. If the plan covers prescription drugs, CMS also requires an annual determination of whether that coverage is creditable, plus a disclosure notice to Medicare-eligible participants.
The penalty for skipping the notice lands on the participant, not the employer. It's a lifetime Part D late enrollment penalty charged when someone goes 63 or more days without creditable drug coverage and then enrolls. The employer's obligation is the annual determination and the notice.
The structural fix is to design for Medicare on the front end in a way the rules allow. That might mean an ICHRA that can pair with Medicare, or a small-employer arrangement where Medicare is primary. Quietly excluding Medicare-eligible active employees from a large employer's plan is the one move that creates the exposure you were trying to avoid.
From Expense Account to Investment Account
Most HRAs are configured as expense accounts. They should be configured as investment accounts.
The compliance architecture stays the same: ERISA plan documents, 105(h) testing, substantiation, and audit trails. What changes is the funding trigger. Instead of paying claims, you fund preventive actions. Instead of sending money to providers after a claim, you route it to both immediate rewards and long-term wealth: store dollars now, retirement contributions later. WellthCare™ is the first Health-to-Wealth Benefit System that operationalizes this shift, rewarding every verified preventive action with store dollars and automatic retirement contributions at zero copay.
That shift changes the plan type, and that detail is where many setups go wrong.
Why a Rewards-First Design Isn't an HRA
An HRA has a fixed legal definition. IRS Notice 2002-45 describes it as an arrangement funded solely by the employer that reimburses medical care expenses under §213(d) after they are incurred. Reimbursement is the whole job: an expense is incurred, substantiated, and paid. Preventive care counts, since §213(d) includes the prevention of disease, so an HRA can reimburse a screening bill or an annual physical.
A rewards-first design does something different. It pays store dollars and retirement contributions when a preventive action is verified, and that payment isn't tied to a specific incurred expense. That mechanic belongs to a supplemental medical plan under IRC §105, not a reimbursement account. Forcing it into an HRA plan document is where setups go wrong, because no funding trigger can rewrite the HRA's reimbursement rule.
The HRA menu also expanded in 2020. Individual coverage HRAs integrate with individual plans or Medicare, excepted benefit HRAs don't integrate at all, and qualified small employer HRAs serve businesses under 50 employees. The setup question is which vehicle fits the funding trigger. The compliance discipline is the same across all of them: ERISA documents, 105(h) testing, and substantiation.
The Operational Fix: A Closed-Loop Data System
In my experience auditing implementations, the #1 setup failure is data integration architecture. Most TPAs treat HRA integration as a one-way file feed: you send eligibility data, they process claims, you get reports. This is broken by design.
The right setup creates a closed-loop system:
- Health action occurs (preventive care, scan, lab work)
- Verification system confirms completion
- Funding engine automatically deposits rewards
- Compliance record is generated in real time
- Employer reporting reflects actual behavior, not projections
Without this loop, you can't validate actions, fund rewards automatically, or maintain compliance-grade audit trails. Most HRA setups are one-way streets. A closed loop moves data in both directions.
Pay for Sickness or Invest in Health
I ask every employer the same question during HRA design: "Do you want to pay for sickness? Or invest in health?"
Your answer determines how you define eligible expenses, how you trigger funding, and whether the plan becomes a cost center or a wealth-building engine. Both directions are possible within the same federal frameworks. The difference is what you choose to fund.
Two decades of HRA history shows one pattern: reimbursement alone hasn't made people healthier, because reimbursing a claim doesn't change the behavior that produced it. A system that funds prevention can, because it pays for the action before the disease arrives. The HRA of the future pays claims and builds wealth.
This article is for general information only and is not legal, tax, or medical advice. Employers should consult their own advisors.