How to run Structured Settlement in DocketMath for Montana

Step-by-step

This guide walks you through running a Structured Settlement calculation in DocketMath for Montana (US-MT). It also shows how to apply Montana’s jurisdiction-aware assumptions—specifically around time-to-file (SOL)—so your scenario setup stays consistent with Montana’s general rules.

1) Start the Structured Settlement calculator

1. Open the tool here: **/tools/structured-settlement
2. If DocketMath prompts you for jurisdiction, choose:

   • Jurisdiction: Montana
   • Jurisdiction code: US-MT

2) Confirm the SOL assumption DocketMath will use

DocketMath’s jurisdiction-aware setup matters when you’re modeling timelines tied to claim filing.

For Montana, the jurisdiction data you’re using provides a general/default limitations period:

• General SOL Period: 3 years
• General Statute: **Montana Code Annotated § 27-2-102(3)
• Source: https://www.nolo.com/legal-encyclopedia/montana-personal-injury-laws-and-statutes-of-limitations.html

Important: This dataset does not include a claim-type-specific sub-rule. So, no specialized SOL period should be substituted. In this workflow, the calculator setup should treat 3 years as the general/default SOL.

Practical implication: When the tool asks you for dates tied to filing deadlines (or “latest action date” logic), make sure those timeline assumptions are based on a 3-year general limitations period.

3) Enter structured settlement inputs

In the Structured Settlement calculator, enter the terms of the payment plan. Field names can vary slightly, but the concepts below are typically present:

• Total settlement amount (the gross amount being structured)
• Payment schedule (e.g., periodic payments with a stated frequency)
• Timing (when the first payment starts; immediate vs. a chosen future date)
• Discount rate / rate of return assumption (if the tool includes it)
• Any lump sum portion (if supported by the tool)

How outputs change based on these inputs

Use this mental model while you experiment:

• More total settlement amount → higher present value and larger equivalent payment amounts.
• First payment later → often lower present value (cash flows arrive later).
• Higher/lower discount rate → changes the mapping from total amount to an equivalent structured stream.
• Different payment frequency (e.g., monthly vs. quarterly) → changes the shape of the installment schedule and the displayed periodic amounts.

4) Tie the timeline to Montana’s general SOL (3 years)

If your structured settlement scenario includes timing constraints (like a filing deadline), align those assumptions to Montana’s general SOL:

• General SOL: 3 years
• Statutory basis: **Montana Code Annotated § 27-2-102(3)

Practical approach inside DocketMath:

1. Identify the trigger date you’re using as the clock start in your scenario (for example, a “date of injury” or another event date you select inside the calculator).
2. If the tool shows or derives a deadline from that trigger date, ensure it uses 3 years for the SOL-related date logic.
3. Do not replace the SOL with a different claim-type-specific period unless you have a clearly sourced rule for that specific claim type (your current jurisdiction data provides only the general/default period).

5) Run the calculation and review the payment breakdown

After you submit:

• Review the payment schedule results (amounts by installment and timing).
• Check the summary figures (commonly present value / equivalent totals / totals by time periods, depending on how DocketMath displays results).
• Confirm the outputs match your intended structure:

  • Payment amounts should align with your selected frequency.
  • The first payment timing should reflect what you entered.
  • If there is a lump sum, confirm the tool allocates it correctly relative to the periodic payments.

If your workflow links structured settlement output to timeline fields (e.g., “deadline” shown on the scenario), verify the displayed or calculated deadlines use 3 years under § 27-2-102(3).

6) Save or screenshot the scenario for comparison

Structured settlement modeling is usually iterative. To understand sensitivity:

• Run a version with your baseline first-payment date.
• Run a version where the first payment is delayed (same total amount, same frequency).
• Run a version where you change payment frequency (if your scenario allows it).

Compare the outputs to see how sensitive the structure is to the timing and rate assumptions you selected.

Common pitfalls

Structured settlement workflows often go off track due to setup drift—especially when SOL-related assumptions get mixed into payment-plan inputs.

• Using the wrong Montana limitations period

  • Your jurisdiction data supports a general/default SOL of 3 years under Montana Code Annotated § 27-2-102(3).
  • Because no claim-type-specific sub-rule was found, don’t substitute a different SOL period for a specific claim type in this workflow without a clearly sourced rule.

• Confusing the SOL “trigger date” with structured settlement start date

  • The SOL-related trigger date (used to model deadlines) is not the same thing as the payment schedule start date.
  • Keep these concepts separate so you don’t end up with a structure that “balances” mathematically but doesn’t match your scenario intent.

• Letting rate assumptions drift

  • If the calculator includes a discount rate / rate of return, choose it deliberately and keep it consistent across comparisons.
  • Even small rate changes can alter present value and the equivalent payment stream.

• Entering the wrong payment frequency

  • “Monthly” vs. “yearly” (or monthly vs. quarterly) can materially change installment amounts and timing.
  • Confirm the payment frequency field before running.

  Warning: If you don’t clearly separate (1) timeline dates used for SOL assumptions from (2) dates used to generate the payment schedule, you can end up with a plan that looks consistent in the numbers but is conceptually mismatched to your scenario.

• Overlooking lump sum allocations

  • If the tool supports a lump sum component, ensure the total settlement amount and the lump sum add up consistently with the periodic components you selected.

Try it

Use this quick test run to sanity-check your setup in DocketMath for Montana (US-MT):

• Open: **/tools/structured-settlement
• Set Jurisdiction to **Montana (US-MT)
• Use a simple structure:

  • Total settlement amount: pick a round number (e.g., $100,000)
  • Payment schedule: choose a basic periodic installment approach
  • First payment timing: set a clear date relative to your scenario start
  • Discount/return assumption: choose one rate and keep it fixed for this mini-series

Then run three comparisons:

1. Baseline: your chosen first-payment date
2. Delayed start: keep total amount and frequency the same, move the first payment later
3. Faster payments: increase payment frequency (e.g., quarterly vs. monthly), if your scenario/workflow supports it

Finally, ensure any SOL-related deadline or timeline outputs in your scenario reflect:

• General SOL: 3 years
• Statute: **Montana Code Annotated § 27-2-102(3)
• Default-only approach: no claim-type-specific sub-rule is included in your provided jurisdiction data

If anything looks inconsistent, adjust your inputs (especially dates, first-payment timing, frequency, and rate), then rerun.

Related reading

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