Salary Definitions are used to specify how ProVal should generate an individual’s salary history, up to and including salary for the year beginning on the valuation date. Salary will be re-created back to the date of hire specified in the Active Data portion of Census Specifications. The Salary Definition specifies the current salary field and enumerates the fields that contain historical salary. Be sure to specify current salary in a manner consistent with calculation of final average salary, if applicable (and vice versa): see Plan Attributes - Pension Modes or Plan Attributes - OPEB Mode for details. In addition to Census Specifications library entries, Salary Definitions may also be referred to by certain custom operators or by specifications for the U.S. qualified plan Internal Revenue Code (IRC) Sec. 415 benefit limits. (See the Regulatory Data topic of Valuation Assumptions for more information about Sec. 415 benefit limits.)
Name may be any descriptive phrase, including spaces, under which to save this Salary Definition.
ProVal expects the Current salary field (annual amount starting on valuation date) to contain the employee’s annual salary amount for the year beginning on the valuation date. In many cases, the salary for this period is to be estimated from the previous year’s salary. To have ProVal do this automatically, select the “<impute from prior salary>” choice for this field. The current salary will then be computed by applying the salary scale specified under the Salary Increases topic of Valuation Assumptions to the previous year’s historical salary. Of course, choice of “<impute from prior salary>” is influenced by what data has actually been furnished as the most recent salary: actual compensation for the plan year or for the preceding plan year (e.g., W-2 compensation when the plan year coincides with a calendar year), or a rate of pay on a particular date. For example, if the plan year is the calendar year 1999, the valuation date is 1/1/1999 and the most recent salary furnished is 1998 W-2 earnings, then you would select “<impute from prior salary>” in order to “update” the earnings to the 1999 earnings that ProVal expects to find in the current salary field. On the other hand, if rates of pay as of 1/1/1999 were furnished instead, and if salaries are expected to remain at those rates throughout 1999, then the furnished rate of pay, without adjustment, represents the 1999 salary and should be entered in the current salary field. (Note that if the salary scale is not constant – that is, the salary inflation rate varies by calendar year and/or the salary merit scale varies by age and/or service – and you impute current salary from the prior year salary, ProVal, appropriately, selects the varying salary inflation rate that is associated with the prior year and “looks up” the salary merit scale rate that applies for the plan member’s age and/or service as of the valuation date anniversary in the prior year.)
Special treatment is required, particularly in the qualified mode, when the valuation date is not the first day of the plan year. Consider, for example, a valuation as of 12/31/1998 for a plan year beginning 1/1/1998, with 1998 W-2 earnings furnished for the plan year. Furnished earnings do not represent salary for the year beginning 12/31/1998 but must be entered in the current salary field, as ProVal will select the IRC section 401(a)(17) annual compensation limit for 1998 (the year of the valuation date) and compare it to current salary (which therefore should contain 1998 earnings).
Even if the plan’s benefit formula(s) are not based on salary (e.g., the benefit amount is $10 per month for each year of service), records for your active data must contain a salary field. If your active data does not already contain a salary field, you may use Define Field by Expression (on the Database menu) to create one and put a dummy current salary amount (e.g., $30,000 for all records) in this field. Then specify the field as the Current salary field in your Salary Definition. Note: In the U.S. qualified and U.S. public modes, under the Regulatory Data topic of Valuation Assumptions, you may wish to make the 100% of average compensation limit of Internal Revenue Code Section 415 “Not Applicable” when you use a dummy salary field.
Use historical salaries toggles whether to use historical database fields when re-creating the salary history or to recreate salary history by using the salary scale assumption retrospectively instead. If the “<impute from prior salary>” option has been selected for current salary, then you must check this box and input an historical field.
The box entitled Historical Salary Field asks for the fields in which to find prior years’ salaries. “1” refers to the most recent prior year, and the box will expand to accommodate any number of historical years (just press the ENTER key when the cursor is on the last row). Do not enter the salary intended for the “current salary” field (i.e., generally for the year beginning on the valuation date) in this box. If the “<impute from prior salary>” option has been selected for current salary, then you must enter at least one year of historical salary, in row 1.
There are two possible definitions for Invalid historical salaries: one considers a zero value invalid and will replace it; the other retains zero as a legitimate salary amount. Both choices will treat missing values as invalid.
Leading invalid values will be discarded; replacement option for embedded invalid values determines how ProVal is to replace historical salary amounts that are considered invalid. This parameter applies only to invalid values of salaries embedded in the salary history, that is, missing, and possibly zero, values in between two valid values. Any leading invalid values, that is missing, and possibly zero, values for years prior to the first year of valid historical salary, are reconstructed by applying the salary scale retrospectively to the earliest valid salary. Consider the following example:
| Year | Historical Salary |
| 1 | 70,000 |
| 2 | -- |
| 3 | 60,000 |
| 4 | 50,000 |
| 5 | -- |
| 6 | 40,000 |
| 7 | -- |
Suppose the salary scale (inflation and merit combined) is 4%. Regardless of the replacement option for embedded invalid values selected, the historical salary used for year 7 will be 38,461.54 (40,000 ¸ 1.04). What historical salaries are used for years 2 and 5 will depend on the replacement option selected. Under the Level salary, backwards option, it will be 70,000 for year 2 and 50,000 for year 5. Under the Salary assumption, backwards option, it will be 67,307.69 for year 2 [70,000 ¸ 1.04] and 48,076.92 [50,000 ¸ 1.04] for year 5. Under the Interpolate option, it will be 65,000 [(70,000 + 60,000) ¸ 2] for year 2 and 45,000 [(50,000 + 40,000) ¸ 2] for year 5. Note: under the Interpolate option, if two years of salary in a row are missing, then ProVal fills in the missing salaries by adding a third of the difference between the available salaries to the lower salary, to derive a salary for one of the years for which salary is missing, and adding two thirds of the difference to derive a salary for the other year (and so forth for interpolating over a gap of a larger number of years).
The Salary in year of hire parameter determines how to replace the historical salary amount that corresponds to the salary in the year of hire. This parameter applies only to salaries in the past, that is, to historical salaries. It does not apply to the current salary because the “current” salary occurs in the future (i.e., it is the salary for the year beginning on the valuation date). In addition, this parameter does not apply to new entrants in a Core Projection because historical salaries and the attendant options are ignored for new entrants. Furthermore, this parameter is ignored when running a Group calculation from within the PIA Calculations Tool.
-
Annualize salary in the year of hire replaces historical salary in the year of hire, if any, by multiplying the historical salary corresponding to the year of hire by the ratio of total number of days in one year (assuming 366 days equals one year) divided by the number of days worked in the year of hire.
-
Exclude partial years replaces historical salary in year of hire, if any, by excluding the historical salary corresponding to the year of hire and rolling the most recent valid salary backwards in accordance with the valuation salary inflation and merit scale assumptions. However, in the case where only one historical salary exists (e.g., new hires) and current salary is not specified (i.e., there is no other salary to roll back from), this option replaces the salary in the year of hire with an annualized amount as described in the preceding bullet.
-
Do not adjust indicates that the historical salary corresponding to the year of hire, if any, should be used without adjustment (e.g., the field already contains an annualized salary for the year of hire). This option will use the historical salary for the year of hire directly as contained in the database field.
The Custom limit parameter allows you to apply a limiting value for this Salary Definition. Select the limit from the options in the drop-down list:
-
U.S. Internal Revenue Code section 401(a)(17) limit
-
lesser of the 401(a)(17) limit and the U.S. social security wage base
-
Canadian yearly maximum pensionable earnings
-
a Custom Regulatory Table that has already been defined and unhidden in the current Project
You can access the library of custom regulatory data tables, to edit an existing table or create a new one, by clicking the 
button.
If a Custom limit is specified, it will be applied wherever this Salary Definition is used, thus
-
before any other calculations are performed (e.g., if this Salary Definition is used in a PIA calculation, the salary will be limited before any steps are applied to calculate the PIA) and
-
to compute both benefits (e.g., if this Salary Definition is used in an accrual basis operator such as #SALARY) and Valuation Salary, and PVFS for entry age normal liability calculations, if this Salary Definition is used to define the Valuation Salary parameter of the Census Specifications.
Any other required limits will also be applied. For example, if this Salary Definition is used for the #FAS operator in U.S. public mode (in which mode the standard #FAS operator limits salary to the IRC section 401(a)(17) compensation limit), the salary first will be limited to the Custom limit and then to the 401(a)(17) limit applied by the operator. For this reason, you might not need to apply a Custom limit within the Salary Definition. On the other hand, the Custom limit parameter might be necessary in some instances. In particular, it is most useful if the Valuation Salary is specified as the sum of multiple Salary Definitions and each of those Salary Definitions has its own plan-specific limit; use of the Maximum Compensation Limit for PVFS & valuation salary parameter of the liability methods topic of the Valuation Assumptions command will not suffice in this situation because that parameter will limit only the sum of the multiple Salary Definition values.
A Custom limit will be ignored when the census data is screened (see Screen Data for more information).