chc93

OK... he hasn't reached NRA. Then, I think forfeit everything, as you say. In fact, he forfeits everything when he "retires" (terminates) since non-vested (assuming vesting schedule is as such). So subsequent death is not relevant?

Wouldn't he become 100% vested upon "retirement"?

Yes... but for a single sum distribution of the entire PVAB if in-service distributions are allowed (cannot stay in the DB plan), I think the RMD can be calculated using the DC method. But have to check for 436 restrictioins, 110% funded, etc...

Don't forget that all participants must be 100% vested upon reaching Normal Retirement Age. Yes... so define NRA as later of 65 or 5 years of participation. That should get you through the 3 year vesting. All assuming the participant is at or near age 70 at plan inception.

We have seen instances where the loan amount is increased by the loan initiation fee. The actual loan amount is paid to the participant, the loan fee is paid to whoever...

That's actually really neat... but just thinking, if the owner should die before they are vested, what would happen to the ER side? Usually benefits are fully vested upon death while employed.

If the "solo" participant is near or over age 70 at plan inception, a vesting schedule... like 3-year cliff, will delay RMD's. FWIW

I asked the provider of the docs and they said they took care of this, any updates are filed appropriately and both the participant and myself would be advised of any changes. Not exactly the case - I was asking (sorry for not being clear) if I run it on a custodial platform what additional measures should I take to ensure that it is all running properly. What I've noticed is that some providers (EG Vanguard) split the transactions into EE/ER at time of contribution whereas others (TD Ameritrade) do not. I just wanted to make sure that if we were with a custodian like TD (using their model prototype plan that they update) that contributions were tracked properly. Well... I had one recent solo 401k plan where the sole participant set up 2 TD Ameritrade accounts... one to hold his rollover, and the other to hold his 401k deferrals. And both TD accounts were linked so a consolidated statement was also available. So even with TD, you should be able to set up 2 TD accounts... one for EE, one for ER, and also get a consolidated statement. And this may be even better than Vanguard, as the EE and ER money can be invested differently.

What about this... Employee is an "employoee" of Company A and Company B... but is in an ineligible class in Company B while employed with Company A. The day that he moves to Company B, he moves from an ineligible class to an eligible class, and is immediately eligible if he previously met the eligibility requirements of Company B while in the ineligible class.

Well... the instructions to Line 3 specify "single-sum distribution". So I would think that for a participant who has been receiving a "periodic" distributions, when a final distribution of the remaining payments is paid in a single payment, that would be a "single-sum distribution" and would be reported on Line 3.

I think she gets the match on the "extra" $150 deferral. The fact that she deferred $200 on the 4th payroll doesn't "fix" the problem of the actual missed deferrals. The participant may be in the same place after her "fix", but the fact of the matter is that the plan still failed to follow the deferral election. Say another participant actually deferred $50 for the first 3 payrolls, $200 for the 4th payroll, and back to $50 thereafter. They both should get the same match. ??

I think the key is "no less rapidly". So if $70,000 transfer, "ratably" over 7 years is $10,000 per year. So *at least* $10,000 has to be allocated each year. Just my thoughts...

Back when paper filing, the postmark was the indicator of timely filing. Since you couldn't get a postmark on Saturday or Sunday or holidays, the instructions allowed a postmark on the next business day. But now with mandatory electronic filing, a postmark is not required, so it seems that the deadline whether Saturday, Sunday, or holidays shouldn't have to be moved. Well... the instructions haven't changed, so August 1 it is.

So... is a loan an option in this particular case?

We have the same situation. Corp B signs on as a participating employer to Corp A's plan. One 5500 with "multiple-employer plan" checked in Part I A, and attached a list of the participating employers as noted in instructions. Note... small plan (<100 participants).

Would you consider that this is to "prevent eviction" from a principal residence?

In the past, I've heard that the IRS only looks for the 5558 *after* they get a report from DOL/EFAST that the filing is past the due date. Since you'll be filing before the due date, the IRS will never even look for a 5558.

In the few cases I've seen, the company tells us what the payroll periods are for their tax year and what is reported on the W-2. And that's what we use. I think being consistent is what matters.

The proposal specifically says that they want to process it through EFAST2 so that both extension and filing is processed by the same system. I still think that a batch feature will be available through third party vendors though. The proposal also states that you could still file on paper if you prefer that method Thanks... obviously I didn't read through the proposal <g>

I would think that the e-5558 would be filed through the IRS FIRE system, and not DOL/EFAST2, like the 8955-SSA, 1099-R, etc since the DOL/EFAST2 don't need these forms. So if e-filed through IRS FIRE, I would assume a "batch" file can be submitted like the 8955-SSA and 1099-R. Wishful thinking?

We recently worked on a plan that had such investment. We initially used the fair market value on the 5500, but the auditors insisted on the contract value. We called the Office of the Chief Accountant at EBSA and they said to use the fair market value on the 5500. However, the plan's auditor said that their benefits department said to use the contract value. The auditor essentially said that the contract value is the fair market value. So the client instructed us to use the contract value, which we did since the client sill sign the 5500.

In a similar situation that we had, the plan year for the "new" plan was amended to coincide with the existing plans. This was after we found out about the "new" plan, but was amended prior to the start of the current plan year for the existing plans.

Also, isn't the 50% requirement only at the time the loan is taken, and not for the life of the loan.

I thought of this too. If the effective date of the merger is 1/1/2014, how many participants were there on 1/1/2014? If zero, then no audit. But still need a final 5500 for 2014. Also, I think the dates on the 2014 5500 would be 1/1/2014 - 1/31/2014 (somewhere, I thought I heard/read that the ending date on the 5500 has to be the last day of a month, but I may recall incorrectly).

There is no reason, since all non-frozen plans perforce allow new participants in on the first day of the plan year, for 5500 software to just assume that the end of last year count is correct for the start of this year. If the 5500 software prepopulates this year's starting counting with last year's ending count, give serious thought to finding a new 5500 software provider. I know. That kinda was my point. If the software is merely carrying forward last years data, then's its wrong. But if it is known that it is just a carry-over, then we can safely ignore it for all plans. However, if the program is calculating these numbers, or flat-out reporting the BOY should equal EOY, than the program has egregious flaws and should definitely be replaced. Thanks for the comments. Our 5500 software carries over the EOY from prior year to BOY to current year. But also our 5500 software is not tied in to our valuation software, so there is no way that the 5500 software can calculate the correct BOY counts. As you say, as long as we know this, we can make appropriate changes. My main concern was with electronic filing, and if the EOY from prior year not equal to BOY of current year would cause any problems. Our software vendor says "no problems". So all is good. Thanks again...