Tom Poje

didn't hear it. does that mean I have to add one to the next talk I do? (By the way Andy, I am penciled in to do something on cross tested this fall.)

Hopefully everyone is 100% vested! I know they always say a plan can impose a 2 year wait if everyone is 100% vested, but it actually pertains that require more than a 1 year wait, not just a 2 year wait. anyway, a safe harbor can not impose more than a 1 year wait because the 401k can not impose more than a 1 year wait. new comparability or cross tested plans are still profit sharing plans and as such could have the eligibility you have described. you can also have a 401k feature (just not safe harbor) that has eligibility = to the 1 year max wait

Only NHCEs have to receive the safe harbor, so it is certainly possible to exclude the HCEs from this contribution. But if, in your plan, you have more than 2 HCEs, then either all get or all don't get, again according to the terms of the document. and, just for clarification, a safe harbor is not really a QNEC - see notice 98-52, VIII D - they even include an example. I've referred to them as SHNECs for lack of a better term.

Thanks for the compliments, although I'd classify the solution to more of a lucky guess! I didn't expect it to help your problem! Hopefully you won't have too many reports that you have designed that might have the same 'problem' lurking about. By the way, at Relius 8 any report with user fields has to be fixed by adding a new table - sometimes twice if you are using both plan spec user fields and census user fields. if it gets to that point, I have a powerpoint explanation about going about that process. It is a bizarre concept (at least to me) using the same table to pull data from both census and plan specs. ANd be careful, I lost a lot of my user field info when I converted.

Patti: aside from the problem you are having, I think the sort has a possible problem If I understand things correctly you have a sort HCE code category last name first name If two people had the same name the system would not print one of them. I only say this because I had a similar report and two people named for example, John Smith - and the second one would never print usually you would have an additional sort 'soc sec #' to prevent that. (or replace 'last name' with rptee.sortname and replace 'first name' with SSNUM)

top paid group only applies to comp, not 5% owners

I am scared to ask, but in particular, are you referring to leveraged ESOPs? and how to process, etc? I have done, some might consider bizzare way of tracking the loan and stuff. I can't imagine there being a specific ESOP group, especially since the system tracks shares, it shouldn't be any different than regular plan processing for a normal plan, except perhaps if you want a diversification report.

gee whiz Blinky, you have your line of products and you are a poet-philosopher on top of all that!

my understanding of the rules (and they certainly could be wrong) would be as follows: Before plan can test under a(4) each employee must receive at least 5% (or 1/3 the rate of the highest HCE) This 5% consists of all nonelectives contributions. I have yet to come across an exception saying 'except nonelectives used in the ADP or ACP test' so, I would say yes they count toward satisfying the gateway. however... now you can a(4) test. 1.401(k)-1(b)(5)(i) and (ii) and also 1.401(m)-1(b)(5)(i) and (ii) require plan to satisfy a(4) with and without the QNEC. I would find it hard to believe plan can pass a(4) without the QNEC. I have heard others argue you can't use QNECs to satisfy gateway precisely because you end up in the a(4) test and now you have people who might not have received a full gateway. (e.g. they received 3% profit sharing and a 2% QNEC but when testing without the QNEC they now only have 3% - which obviously doesn't satisfy gateway. Again, it depends on how you interpret the statement (this is from the preamble in the Federal Rehister 6/29/01) Gateway for Cross-Testing "Under the final regulations, as under the proposed regulations, a plan satisfies the minimum allocation gatewayif each NHCE in the plan has an allocation rate that is at least one third of the allocation rate of the HCE with the highest allocation rate, but a plan is deemed to satisfy the gateway if each NHCE receives an allocation of at least 5% of the NHCEs compensation (within the meaning of section 415©(3))." Did a person receiving a QNEC receive 5% allocation rate? I vote yes. Therefore I have crossed the gateway and can now cross test, following the cross testing rules. or is it I am cross testing, I need to check to see if the NHCE receives the 5% and without the QNEC he doesn't...so I can't cross test.

in other words, suppose plan made a calendar year election. (Document driven, or if I understand things correctly from reading the Erisa Outline Book, if document does not have HCE language then it is your choice) since plan year begins 11/1/02 you would look at comp earned 1/1/2002 - 12/31/2002 I assume then you use the 2002 limit which is 90,000 - so conceivably the person might not be an HCE

well, I guess in Blinky's case that sort of.... 'winds up the voting' on this issue.

well, you are thinking of a QMAC. you can't simply treat a match as a QMAC unless the document permits QMACs. There is a difference between the two, even if the match is always 100% vested - the distribution rules being the major difference. if test is close to passing, you might try testing comp = comp - deferrals (again providing definition of 414(s) in the document allows it)

if there is an hours requirement or last day provision, then yes. the proposed regs hold that an individual who gets zero has received a lesser rate than an hce, one of the requirements for a safe harbor match. perhaps the IRS is saying that is the way it should have been interpreted in the past as well.

correct (maybe) if plan is top-heavy, and top heavy goes to all participants then the daughter has to get the 3% rather than 0% - but not the gateway as she is an HCE.

http://www.stupid.com/stat/WUP2.html

ah,time for a bit of explanation. the term date field. this is one of those fields that rarely should be entered by hand. I have had to slap people across the wrists for doing things like that. this field does not actually mean 'termination date' but rather, 'termination date from the plan'. thus, an ineligible ee who quits would never have a date in this field. and the category code on an ineligible will list the reason why ineligible. if data is enetered in status date and status, then running eligibility will set the term date field (if ee is an actual participant) in the same vain, if ee quit one year and is paid out the next, changing status to paid out and changing status date will not change the term date. if ee is rehired (changing status date and status), system will delete the term date when eligibility is run. ..................... on another note, a common problem I have seen in coding plan specs is plan entry requirements - initial participation - the same value should be entered across the board. never an X for terminees, even if terminees are excluded from contributions. this is an entry field, not an allocation field. enetering an X will produce incorrect results on coverage and nondiscrim testing.

and, unless something is changed in the proposed regs, the discretionary match (since in this example an hours requirement is attached) will have to be tested when those regs go into effect in the future.

when you are doing the dcm (or for that matter the download) are you downloading the 'term date' into term date or into status date? If it is downloaded into status date, then you should be able to run a census report before eligibility to check for possible changes. I don't remember if census audit records changes on the download, but I never liked the length and format of that report.

the best I have is a census report that will indicate people who have compensation but also have a term date prior to plan year begin. logically those would be rehires, but thats about the close as I can come to generating something.

Archimage: maybe better to name owners by attribution owners not by attribution that way you do not overlap. if the first group is owners, that includes both mom and daughter while that is possible, and an additional contribution could be made to mom why not be as flexible as you can get

well, again it depends. max deductibilty (25% of eligible pay) is based on total, not date of entry comp. so again, it depends on what you might need.

I think you still have to make the full match deposit because the document says 25% up to 6%. Have to follow the terms of the document. I would hold that the forfeitures would reduce 2004 amount since the actual distribution of excess didn't take place until 2004.

for what purpose? If top-heavy, entry date doesn't matter, it is entire year. gateway minimum is also 415 comp, but can be limited to date of entry!

Dave said he is aware of problem, and is trying to fix the problem of attachments

might try the following, it will pull all contributions (by source). must be sure to click on "all accounts including those with no activity" to make this work (in case someone transfered out all money. another of my specialty reports. haven't tried this one for awhile, but I assume it still works. (OK, I have one that will do this, but something is broken. I attached a 'rpt' file a couple of weeks ago and it worked fine. now the system won't take it, says you can not upload this type of file. You will have to ask Dave Baker (The Head Honcho of the Website) what has happened)