In order to set up the plan rules for a conversion, you will need the latest plan document or other form of documentation that describes how the pension plan should be administered (collective bargaining agreement for example).

While it may be useful to have prior versions of the plan document, this is not required for initial conversion.

If possible, you should make an electronic copy of the plan document as this can then be stored into the DB Precision electronic archive for easier retrieval.

You should have a copy of the actuarial valuation report as of the Conversion Date. You will need to be able to match participant counts with the counts found in the participant data summary section of the report.

In addition, you can use the plan provisions section of the report to get a quick overview of the plan's provisions.

Participant data should generally be brought into DB Precision as of the last date that an actuarial valuation report was produced. You should use the final source of data used for the valuation and make sure that the participant counts match up with the data summary in the valuation report.

It is best to take this data directly from the software that was used to generate valuation liabilities (ProVal for example). If this is not available, then you should take the data from the last step of data work before it was used for liability determination (if any subsequent adjustments were made to the data, this will complicate the process of matching participant counts).

You will be working with your data in an Excel file, so your data should either exists as or be converted to an Excel format.

At a minimum, your data should include the following items:

• Social Security Number: if this is not available for all or any participants, you will need to create a fake SSN as follows. Assign or use a 3- or 4-digit ID for the sponsor (0001 for example) and then assign in ascending order 3-digit numbers to each participant with an unknown SSN (001, 002, etc.). Then assign a new fake SSN by combining two (if using a four-digit sponsor ID) or three (if using a three-digit sponsor ID) nines (99 or 999) with the sponsor ID and person ID. You should then have a series of nine-digit numbers (990001001, 990001002, etc. for example) representing fake SSNs for each person with an unknown SSN. You should eventually try to get true SSNs for all participants but should not hold up the conversion for this.
• Participant Name: if you have first, middle, and last name already split out, import each separately. Otherwise, you can import participant names and have DB Precision split them out for you.
• Gender
• Date of Birth
• Date of Hire: only required for active and ineligible participants.
• Benefit Amount: only required for retired, beneficiary, and terminated vested participants.
• Benefit Payment Form: only required for retired, beneficiary, and terminated vested participants.
• Beneficiary Date of Birth: only required for retired participants.

If you are not using the standard PensionSoft payment election forms package, then you will need to make sure that you have all required forms in a Microsoft Word format.

In addition, to test the calculation results, it is best to have sample benefit calculations available. You should try to obtain at least one example of each of the following:

• Benefit at Normal Retirement Date
• Benefit at Early Retirement Date: if they are multiple early retirement reductions, you should have at least one for each.
• Benefit at Late Retirement
• Break-in service
• Lump Sum Payout
• Small Benefit Cashout

An additional source of checking calculation results is to compare DB Precision calculations against results from completed benefit statements. These statement results should be as of the DB Precision conversion date (latest valuation date).