Renewals, Now by API

Ask anyone who administers pre-tax benefit accounts how renewals work, and you'll hear some version of the same story. Once a year, plans get rebuilt. Calendars get relinked. Contribution schedules get re-entered by hand. Files move back and forth between systems, often on someone else's timeline, and everyone holds their breath until it clears.

That's how our industry has always done renewals. They're file-based, manual, and slow. And because they only come around once a year, nobody stops to ask whether it has to be that way.

We think it doesn't. So we built renewal APIs, and one of our TPA partners, Rocky Mountain Reserve, is already running on them.

Why renewals got stuck

The old way wasn't anyone's bad idea. It's just how benefits software was built. In a lot of systems, you build each plan from scratch every year. If the platform uses calendars for scheduled contributions, you relink those calendars to the plans by hand, one at a time. It's a pile of manual setup that has to happen in a narrow window, and every manual step is a chance to introduce an error right before a plan year starts.

That works, in the sense that it eventually gets done. But it's a lot of effort spent re-creating something that already existed last year, and it ties up smart people in data entry during one of the busiest stretches of the year.

How we made renewals better

The renewal APIs are what set this apart. A partner makes essentially one large call that renews every plan in a plan year. It stands up the new plan year and sets everything up. You can override names or plan codes if you don't want our defaults, and feed in your own data as part of the call. If your plan information already lives in your own system of record, you don't need to re-key it into ours. You set it up once on your side and send us the updates to configure. For a partner with volume, that's renewals at the scale and speed APIs make possible, with no clicking through screens at all.

The same power is available in the UI through our quick renewal module, for employers and partners (administrators) alike. As long as you're not making substantial changes and the plans stay largely as they were, you run them through the module and it handles the setup. It links the payroll calendars automatically. Our calendars also auto-extend every six months, so once a calendar is set, it mostly takes care of itself. If a date needs a small adjustment, say the 15th lands on a Saturday, you can edit it right there in the module while you renew.

‍

The APIs and the module share the same engine, so you can mix and match to fit the moment, and both cover the full range of accounts: FSA, HRA, HSA, dependent care, and commuter, all renewed at once.

Our partners can also build plans for the new plan year from scratch when a unique renewal calls for it. Even then, our partners are able to work from templates rather than a blank page, alleviating much of the heavy lifting.

Health plan renewals, now included

We recently extended both the module and the APIs to cover health plan renewals too. To be clear about what that means for benefit accounts: we're not talking about standing up a medical plan the way a carrier would. We're talking about the health plan settings that drive how an HRA, HSA, or FSA behaves, essentially, the rules that determine when an account pays.

Those settings can be time-consuming to rebuild. Often the structure of the plan is staying exactly the same, and only the amounts change, because insurance premiums went up. Take a donut HRA design, where the HRA pays, then the participant covers an out-of-pocket layer, then the HRA pays again. You can renew that whole structure for the following year and link it to the right account, usually the HRA, in one step. The design carries forward intact, and you just update the amounts as needed.

What it looks like in practice: Rocky Mountain Reserve

Rocky Mountain Reserve uses both APIs and the renewal module across their account base. For their large number of clients with a January 1 start date, where there's a lot of volume at once, they ran their plan year renewals through the renewal APIs. For off-cycle groups, or when they get a client's information early, they'll use the module and the UI instead. Since it's the same engine, team can pick whichever path a given renewal calls for.

The result is the kind of change that's hard to really appreciate unless you've lived the old way. Work that used to be very manual and take hours now takes minutes, and in a lot of cases seconds. And the errors that come from rebuilding plans by hand are designed out of the process.

"Elevate's renewal APIs are a huge improvement for our operational team. It’s hands-free on our end, giving our team so much time back during this busy season.

Even when we use the renewal module, it cuts our average renewal time to just five minutes. Five minutes! The entire experience is smooth from start to finish. It's another great tool from Elevate that truly saves us time."
— Jake Anderson, Chief Administration Officer, Rocky Mountain Reserve

Renewals are one piece of a bigger pattern

APIs for renewals aren't a one-off. They come from the same place as the rest of what we build: the belief that benefit administration should be automated and integrated, that work should run in real time instead of in batches, and that the people doing the work shouldn't be stuck doing by hand what software can do for them.

The takeaway

Renewals have been file-based and manual for so long that most of the industry treats the annual scramble as a fact of life. It isn't one. When the architecture is built for it, a renewal can be one API call, or five minutes in a module, instead of hours of rebuilding plans by hand. While others are promising these advancements are “on the roadmap,” it's already how our partners work today.