Can someone tell me what a "QSERP" is?

[AndyH]

The context is a non profit DB with participants above the comp limit. A non qualified has been discussed but the 457 taxation rules are a problem. Now someone is proposing a "QSERP". Any ideas on how that might help?

[richard]

A QSERP is a "qualified SERP."

As odd as that sounds, here's how it works.

Say you've got a 1% final average pay DB plan. An executive earns $240,000 (150% of the 401(a)(17) limit). The regular qualified DB plan cannot recognize any part of his pay above $160,000. A common design is a non-qualified SERP that provides a "make-up" benefit, equal to the "regular DB formula" based on his entire pay, minus the qualified DB benefit.

The SERP is, of course, non-qualified; and results in various issues(benefit security, income taxation, and FICA taxation). Various approaches (Rabbi Trusts, Secular Trusts, COLI, etc.) have been used to deal with these issues.

The QSERP is an attempt to "put" the non-qualified SERP into the qualified DB plan. Since the DB plan cannot EXPLICITLY reflect the executive's entire pay, the QSERP accomplishes this using the back-door approach. The QSERP is actually the exiting DB plan, modified as follows. In this example, the DB plan would provide a 1% of final average pay benefit for all employees except for the executive, and a 1.5% of final average pay benefit for the executive. This is not a safe-harbor formula, and must be tested using the general test under 401(a)(4).

[in many cases, the general test will work. However, the testing is very tricky, and significanly different from the approaches typically used to get a "new comparability" profit sharing plan to pass. Also, the general test must be performed each year.]

Also, the plan formula for the executive must be (in theory) modified periodically. This would need to occur as the ratio of the executive's pay changes relative to the inflation-adjusted 401(a)(17) limit. (Stated differently, the execitive's formula would have to change if his pay raises were different from inflation.)

Tricky stuff, probably not in the spirit in which the 401(a)(4) regulations were designed, probably not for the faint-of-heart, but creative.

[AndyH]

Thank you very much for the response. Can I ask a couple of followup questions?

1. You indicated that it must be general tested each year. Is there some difference between this and other general tested plans that would invalidate the three year testing cycle, or do you say this just because it would be prudent?

2. Are there any other unusual testing issues? You've implied complications in the general test. The situation I'm dealing with is a fairly large plan. Are there any "tricks" typically used in the testing, or common quirks?

The executives that it would be geared for are around 60-63 with long service. The existing formula is a non integrated safe harbor.

3. Is the enhanced benefit formula typically done by class, or is there some other approach which might make it more palatable in terms of employee relations?

Again, thank you very much for the information.

[richard]

#1. While typically for a large group, general testing once every 3 years will suffice, in this case, I would do it every year. I'm not sure if it is merely being prudent, though. Let's me illustrate.

I have a non-safe harbor DB plan covering about 600 employees. All employees (including the 20 HCEs) receive the same formula. While we might fall slightly out of compliance once in a while because of minor employee demographic changes (e.g., an old HCE gets a large raise), the 3-year cycle is OK.

In your case, you will have a separate benefit formula for a few HCEs. Here, any demographic changes on those HCEs will be magnified since they have a different benefit formula. While I can't specifically say why, my gut feel is that I would feel fairly comfortable arguing 3-year demographics with the IRS in my case (one formula for all employees) than in your case (a different formula for a few HCEs).

#2 - Other than the usual stuff for testing DB plans. Often, cross-testing the DB plan on contributions works if there are non-HCEs older than the "enhanced" executives. In your case, this probably doesn't work. Careful selection of groups is powerful, along with the choice of testing method (accrual, accrued-to-date and projected), choice of compensation, and choice of testing date. Often combining this with a DC plan helps (many such plan sponsors offer profit sharing plans as well). In your case, the biggest factor that will help will be imputing disparity. (This will help a lot, though the age and longevity of your executives will be a problem.)

Another idea is to phase the enhancement in gradually. (In my previous post discussing a $240,000 employee, if a 1.5% formula won't work this year, try 1.2%, and if the demographics change next year, increase it to 1.3%., etc. Be careful, here. Really tricky.)

#3 - Employee relations are a problem. Whether you define the "enhanced executives" by group (which will be difficult if you would like different gross-up percentages), by job title (which I like better), or by employee name (which, believe it or not, the IRS finds acceptable --- I, however, do not), you will have the issue of the SPD to consider. Some feel that employees need only receive that part of an SPD that affects them (for example, in a plan that covers hourly and salary employees, the SPD given to hourly employees doesn't have to mention the benefit formula for salaried employees, and vice versa); I'm uncomfortable with this. As a practical matter, this can be included in the body of the SPD, and (hopefully?) most employees won't notice.

Alternatively, if there are enough "enhanced" HCEs so they meet 401(a)(26) on their own (unlikely, but I'll mention anyway), you could set up a separate DB plan for them (or just for the additional benefit). The other employees then won't have to be told.

[AndyH]

Thank you, Richard, this information is invaluable. Hopefully, we'll be able to return the favor in the future.

[Guest Ted Munice]

A client of ours recently added a QSERP provision to their DB plan (over 400 employees - integrated PIA offset formula). This involved adding the "accrued benefit" under the SERP to the accrued benefit under the plan. The additions were spelled out in dollar amounts and the QSERP participnts were spelled out by name. The general test was passed using the accrued to date method (there are a number of techniques that make this work in most cases, particularly if you have a steady stream of new entrants). The restated plan document was submitted to the IRS for a determination ruling (although the QSERP provision was not highlighted for a particular ruling - this was jusy part of a normal restatement). The IRS came back with 28 questions on the document. Not one had to do with the QSERP provisions.

[richard]

To Ted and Andy:

I've seen Ted's approach, and the IRS response (or nonresponse) is quite typical. My personal preference (call it style) is to not name individuals or specific dollar amounts. But that's just my preference and comfort level.

[Guest Jane Francis]

Does anybody have any concern that a QSERP could be viewed by the IRS as a benefit right or feature that then would fail coverage testing?

[Guest merlin]

BRF may or may not be an issue. Why would it be any more of a problem to have a "tiered " benefit structure than it is to have a tiered allocation structure in a dc plan? The potential problem I see is the anti-cutback rules. Once the QSERP benefit has been accrued,isn't it protected under 411(d)(6)? If the general test fails won't this result in additional accruals for NHCEs?Given what you're trying to do and who you're trying to do it for this could be considerable. I guess this is where the "not for the faint-of -heart" requirement comes in.