How to run Structured Settlement in DocketMath for West Virginia

Step-by-step

Run this scenario in DocketMath using the Structured Settlement calculator.

You can run a Structured Settlement calculation in DocketMath for West Virginia (US-WV) using jurisdiction-aware settings. This guide walks you through a repeatable workflow and explains how West Virginia’s general default limitations period (not a claim-type-specific one) may affect what you see in the tool’s outputs.

1) Open the Structured Settlement calculator

Start here for the fastest route:

• Primary CTA: /tools/structured-settlement

Once the tool loads, confirm you’re using the Structured Settlement calculator (not a different financial/claim calculator).

2) Set the jurisdiction to West Virginia (US-WV)

In the calculator’s jurisdiction controls:

• Choose West Virginia or US-WV (jurisdiction code: US-WV)

DocketMath should then apply jurisdiction-aware rules available for the US-WV configuration.

3) Enter the settlement cash flow assumptions

Structured settlement modeling depends on the payment schedule you’re testing. Fill in the inputs the calculator requests, typically including:

• Total settlement amount (or an equivalent starting value)
• Payment timing (for example, first payment date or elapsed timing)
• Payment frequency (for example, annual, monthly)
• Number of payments (or an end date)
• Payment type structure (lump sum + installments, or installments only)
• Discount rate / yield (if the tool includes a time-value-of-money parameter)

If the UI asks for a lump-sum portion, enter it in a way that stays consistent with the installment portion so the total matches your intended figure.

How outputs change:

• Changing payment timing moves cash earlier/later, which can materially change present value (PV) even if the total nominal amount stays the same.
• Adjusting the discount rate changes how heavily future installments are discounted (higher rate generally lowers PV).

4) Add West Virginia limitations-period awareness (general default)

For West Virginia, the jurisdiction data you’re using here reflects the general/default statute of limitations:

• General SOL Period: 1 years
• General Statute: W. Va. Code §61-11-9
• Source: https://codes.findlaw.com/wv/chapter-61-crimes-and-their-punishment/wv-code-sect-61-11-9/

Important: the jurisdiction data note says no claim-type-specific sub-rule was found. That means the tool is treating the 1-year general period as the default model input/rule reference in the absence of a more specific limitation rule.

How this affects your DocketMath run:

• Any DocketMath “jurisdiction-aware” logic tied to time windows will reflect the 1-year general default rather than a claim-specific period.
• If your payment schedule starts or ends outside that general window, you may see timing-related warnings or flags depending on how the tool surfaces limitation awareness.

5) Run the calculation and review the outputs

Once your schedule and jurisdiction are set:

• Click Calculate (or the tool’s equivalent action)

Review each output section. Common structured settlement outputs include:

• Present value (PV) of the scheduled payments
• Payment schedule breakdown (payment-by-payment totals, if shown)
• Total nominal payout (sum of installments + any lump sum)
• Comparison metrics (for example, PV vs. nominal, or PV differences across scenarios)

Practical workflow tip: Run at least two scenarios to understand sensitivity:

• Scenario A: same payments, earlier start
• Scenario B: same payments, later start

Even modest timing changes can shift PV noticeably.

6) Iterate using “what-if” adjustments

To make the model useful, don’t stop at one run. Common iterations include:

• Change the first payment date by 6–12 months
• Increase/decrease the discount rate (if adjustable) to test sensitivity
• Switch the lump sum vs. installment proportions while keeping the nominal total constant

How outputs change (typical behavior):

• Earlier payments generally increase PV.
• Higher discount rates generally decrease PV.
• Moving more value from later installments into earlier payments usually increases PV.

7) Capture results for your record

When the tool provides a summary, export/copy/screenshot results if DocketMath supports it. Keep at least:

• Jurisdiction: US-WV
• Input schedule: timing, frequency, number of payments, lump sum/instalments
• Limitations-period reference used: general/default 1-year rule tied to W. Va. Code §61-11-9
• Output totals/PV: nominal payout and PV (and any flags/messages)

This makes it easier to compare versions later.

Common pitfalls

Below are frequent issues when running structured settlement modeling in a West Virginia (US-WV) workflow.

• missing a required input
• using a stale rate or rule
• ignoring calendar or holiday adjustments
• skipping documentation of assumptions

Capture the source for each input so another team member can verify the same result quickly.

1) Using the wrong limitations-period assumption

DocketMath can only apply what’s configured for the jurisdiction. In this West Virginia setup:

• The general/default SOL is 1 years
• Based on W. Va. Code §61-11-9
• No claim-type-specific sub-rule was found in the provided jurisdiction data

If your situation relies on a different limitations rule, your timing-aware output may not reflect the correct rule.

2) Entering inconsistent totals

A structured settlement is essentially a cash-flow model. Common input mismatches include:

• Lump sum + installments don’t add up to the intended total
• “Number of payments” doesn’t match the end date
• Payment amount differs from what the schedule implies

Result: PV and totals won’t line up with your underwriting assumptions.

3) Forgetting to test sensitivity

A structured payout can look stable at one discount rate and change at another. For more reliable comparisons:

• Run at least two discount rate values (for example: baseline and ± adjustment if the tool allows it)
• Keep the payment schedule identical while changing only the rate

4) Mixing timing formats

Watch for UI traps like:

• “Days from now” vs “actual calendar dates”
• “Start date” vs “first payment date”

Consistency prevents off-by-one timing errors that can shift PV.

5) Treating PV as legal entitlement

Present value is a financial metric, not a legal finding. Use PV to compare settlement structures and the effect of timing/discounting—not to conclude what must be paid under any particular legal theory.

Try it

If you want a quick self-check before running a serious scenario, try this mini-exercise inside DocketMath:

• Set jurisdiction to US-WV
• Use a simple structure: one lump sum + 4 equal installments (or 8 equal installments)
• Keep the nominal total fixed across two runs
• Change only the first payment timing (for example, “earlier” vs “later”)
• Confirm the tool is referencing the general/default 1-year SOL under W. Va. Code §61-11-9
• Compare PV results and note the direction of change

After you run it, check whether:

• PV goes up when payments move earlier
• PV goes down when payments move later
• Totals remain consistent when nominal structure is held constant

If DocketMath shows a limitations-aware indicator, verify it aligns with the general 1-year default (since no claim-type-specific sub-rule was found in the provided West Virginia data).

To launch the workflow again, use:

• /tools/structured-settlement

Related reading

• Structured Settlement Calculator Guide for Alabama
• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado