Replacing Hard-Coded Parameters

I am updating an app that allows EOTI users to add records (submit permit applications) to a table (Permit Applications) .

There is a formula-number [Amount Due] field derived from several [*Category*] field values. The logic includes 40-50 hard-coded values (fees and expiration dates for pro-rating). The fees and dates will be changing in the near future. The payments are processed externally and not connected to QB. However, existing QB records will report an incorrect Amount Due when the hard-coded fees/dates change and be inconsistent with the external Payment system.

I am considering 3 solutions to replace the hard-coded logic, but I am looking for feedback and/or alternate suggestions.

1. Update the existing table. Create a new field for each of the 40-50 parameters and replace the hard-coded logic with the related fields. Use Default Values to initialize values for new records. Going forward, update the Default Value when fees/dates change.
2. Create a new table (Parameters).
• Structure Options:

1. Each parameter is a separate field. A single record supports all 40-50 parameters. A single relationship to the parent Parameters table supports 40-50 pairs of lookup/snapshot fields in the existing child table. The snapshot fields support a point-in-time value, so fees/dates may be updated when required. Alternately, the Parameters table could include a new record when any parameter changes and the snapshot fields would not be necessary.
   ~OR~
2. Each parameter is a new record with [Category], [Param Name], and [Param Value] field values. The Permit Applications table includes a formula [Related Parameter] field (similar logic to existing [Amount Due] field, but identifies the parameter instead of hard-coded values) to support one pair of lookup/snapshot fields with the permit amount. Like the other table structure, this design could either be limited to a single record for each parameter or new records when values change.

3. Use a Pipeline to update an editable [Fee Amount] field (from a Parameters table) when records are added.

Note: I prefer non-pipeline solutions because I am one of several staff supporting almost 200 apps, so updating/reviewing pipelines requires me to logout of my user account and login with our shared/service account. Then I have to identify the correct pipeline from a continually increasing population.