How to run Structured Settlement in DocketMath for Utah

Step-by-step

Run a Utah structured settlement calculation in DocketMath by using the Structured Settlement calculator with jurisdiction-aware rules for US-UT. This walkthrough focuses on generating the tool’s structured settlement timeline and payment schedule outputs—not on legal drafting or strategy.

1) Start the calculator in DocketMath

1. Open the tool: /tools/structured-settlement
2. If the interface asks for jurisdiction, select Utah (US-UT).
3. Confirm the calculator mode is Structured Settlement (not a general annuity-only mode).

2) Enter the financial inputs DocketMath needs

Use the fields exposed by the calculator and enter numbers with your preferred precision (whole dollars vs. cents).

Common inputs you’ll use include:

• Total settlement amount (or the starting “principal” for the stream)
• Payment structure (e.g., level payments, escalation, or a specified payment schedule)
• Payment timing (start date and/or payment frequency)
• Number of payments (or an end date)
• Discount / rate assumptions (if DocketMath includes a present value step)
• Inflation/escalation assumption (if escalation is modeled)

If you already have an annuity or settlement statement, you can mirror the payment amounts and dates into DocketMath to reproduce the schedule.

3) Use Utah jurisdiction-aware rules (US-UT)

When you set US-UT, DocketMath applies a Utah-specific ruleset aligned to the Utah Structured Settlement Protection Act (Utah Code §§ 78B-6-1101 to 78B-6-1108).

A key concept in the Act is the restriction on transferring structured settlement payment rights without satisfying the statutory framework. The Act includes broad language stating, in substance:

• “No direct or indirect transfer of structured settlement payment rights shall be effective … and no structured settlement obligor or annuity issuer shall be required to make any payment … to any transferee of structured settlement payment …” (Utah Code §§ 78B-6-1101 to 78B-6-1108)

In practical terms for a calculator run:

• DocketMath’s outputs are designed for modeling the payment schedule and related numeric figures based on your inputs.
• The jurisdiction setting ensures any Utah-specific logic included in the platform’s rules is applied where applicable.

4) Confirm the timing logic and “default period”

In this workflow, no claim-type-specific sub-rule was found that would alter the period logic based on claim category. Because of that:

• Default period behavior (US-UT): apply the general/default period logic (no claim-type-specific sub-rule detected).

Before you export or rely on the output, do a quick timing check:

• Does the schedule start on the date you entered?
• Are payments spaced at the selected frequency (monthly, quarterly, annually, etc.)?
• Do totals match expected sums (accounting for rounding)?

5) Review outputs and scenario-check

After calculation, review at least:

• Payment schedule table (amount by date)
• Totals (sum of payments and any present value figure, if included)
• Derived outputs (for example, effective term or remaining-balance assumptions, if the tool shows them)

Then run one sensitivity test to confirm the model responds to your assumptions:

• If you used a rate or escalation assumption, adjust it slightly (for example, +0.5% or -0.5%) and confirm PV and totals move in the expected direction.

6) Export/share outputs for the next step

If DocketMath offers export options, use them to move from “math model” to a shareable documentation pack. Keep your input assumptions visible so downstream reviewers can trace where outputs came from.

Final checklist before you finalize:

• Jurisdiction set to Utah (US-UT)
• Start date and frequency match the settlement/annuity documentation
• Escalation or rate inputs match what your source contract/statement supports
• Totals reconcile with your source amounts (allowing for rounding)
• No claim-type-specific period logic was assumed (default period applied)

Common pitfalls

Even when the math is correct, structured settlement runs often fail due to data hygiene or mismatched assumptions. Common issues when running US-UT in DocketMath include:

1. Mixing payment dates with payment frequency

   • Example: entering “monthly payments” while also providing an end date that forces irregular spacing.
   • Result: DocketMath generates dates that don’t match the intended schedule.

2. Putting escalation/rate assumptions in the wrong place

   • Some tools compound rates; others model escalation as step increases.
   • If you switch escalation on/off or change the assumption type between documents and the tool run, totals can drift.

3. Assuming Utah has claim-type-specific sub-rules for periods

   • In this workflow, no claim-type-specific sub-rule was found, so you should use the general/default period.
   • If your internal process expects different period logic by category, you’ll need to reconcile that outside the calculator.

4. Treating schedule math as legal compliance

   • Utah’s Act includes a broad restriction on effective transfers of structured settlement payment rights unless statutory requirements are satisfied (Utah Code §§ 78B-6-1101 to 78B-6-1108).
   • A payment schedule alone does not address transfer effectiveness.

5. Rounding mismatches

   • Present value and schedule totals can differ by a few dollars when cents, rounding rules, or compounding conventions differ.
   • Treat DocketMath as model-based math and align rounding conventions to your source documents when possible.

Try it

You can run your Utah structured settlement calculation right away in DocketMath:

1. Go to /tools/structured-settlement
2. Select Utah (US-UT)
3. Enter your payment schedule inputs (amounts, dates, frequency, and any rate/escalation assumptions)
4. Review the generated payment schedule table and totals
5. Sanity-check:

   • Payments occur on the exact dates you expect
   • Total payments match your settlement/annuity summary (within rounding)
   • Scenario changes (like rate/escalation tweaks) move PV in the expected direction

If you want extra confidence in how the tool applies your assumptions, compare two scenarios side-by-side:

• Scenario A: your current rate/escalation assumptions
• Scenario B: a modest adjustment (e.g., ±0.5% on a rate input)

That comparison helps confirm DocketMath is applying your assumptions in the way you intended.

Related reading

• How to calculate Structured Settlement in Philippines — Full how-to guide with jurisdiction-specific rules
• Worked example: Structured Settlement in Philippines — Worked example with real statute citations
• Inputs you need for Structured Settlement in Philippines — Input checklist with sourcing guidance