How to run Structured Settlement in DocketMath for Tennessee

6 min read

Published June 4, 2026 • By DocketMath Team

Under review

missing_or_unverified_packet

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

Step-by-step

Below is a practical workflow for running a Structured Settlement calculation in DocketMath for Tennessee (US-TN), using jurisdiction-aware rules. This guide is written to help you get accurate numbers—not to provide legal advice.

1) Start from the right tool

Open the Structured Settlement calculator: /tools/structured-settlement
Confirm the jurisdiction selector is set to Tennessee (US-TN).

If you don’t see US-TN selected by default, switch it before entering any amounts. Your payout schedule and totals depend on jurisdiction-specific settings.

2) Enter the core financial inputs

DocketMath’s structured-settlement calculator typically uses these concepts (names may differ slightly in the UI):

Present value / lump-sum amount (the amount to be “structured”)
Discount rate / interest rate assumptions (used to model future payments)
Payment frequency (e.g., monthly, annually)
Term (how long payments last) or end date
Payment pattern (level payments vs. increasing payments, if your UI supports it)

Use consistent units:

If payments are monthly, ensure your rate assumption is consistent with how the calculator interprets periodicity.
If the calculator expects an annual rate, don’t enter a monthly rate and label it annual.

3) Choose the payout schedule options that match Tennessee’s structure logic

For Tennessee, the calculation needs to follow the general/default period.

Important: No claim-type-specific sub-rule was found. That means you should rely on the default/general period logic in the tool for US-TN, rather than selecting or assuming a specialized period mode for particular claim types.

Note (Tennessee, US-TN): This workflow uses the general/default period because no claim-type-specific sub-rule was found.

4) Confirm the default period logic is actually being applied

As you build your schedule, check for signals that the calculator is using the default period logic:

The first payment date (if your UI asks for a start date)
The implied number of payments based on term/end date
Whether the UI labels the period mode as default period (or indicates you’re in the default/general configuration)

If DocketMath indicates you’re using default period assumptions, leave it enabled unless you have documentation showing your scenario truly matches a different mode. Avoid mixing a default period setting with any separate “special period” option—doing both can cause timing assumptions to be applied twice.

5) Run the calculation and review the outputs

After you submit:

Review the payment schedule (each payment date and amount)
Check the total payout (sum of all payments)
Verify the present value / discounted value matches the calculator’s modeled assumptions
If the UI provides both nominal and discounted views, compare both

Quick reality checks:

If the schedule spans a longer duration, nominal totals generally rise.
If the discount rate increases, the same present value typically supports a lower future payment stream (because each dollar of present value “earns” more under the model).

6) Export or copy results for case documentation

When you’re ready for your case file:

Copy the schedule (or export if the tool supports it)
Record the inputs used for the run: lump-sum/present value, discount rate, payment frequency, start date, and term/end date
Save screenshots/exports for auditability

If you run multiple scenarios, keep each run’s settings distinct—DocketMath outputs are only reproducible if the assumptions are documented.

7) Iterate with “what-if” changes

Structured settlement results are sensitive to assumptions. Run controlled variations:

Change term (e.g., 10 years vs. 15 years)
Change discount rate (e.g., 2.5% vs. 4.0%)
Change payment frequency (annual vs. monthly)

Use a one-change-at-a-time checklist so you can explain differences:

Keep lump-sum / present value the same
Keep payment pattern the same
Change only one variable per iteration (rate OR term OR frequency)

Common pitfalls

Structured settlement runs typically fail due to inputs and schedule configuration rather than the underlying math. Watch for these issues in DocketMath for Tennessee (US-TN):

Assuming claim-type-specific period rules exist in Tennessee
- For this TN workflow, no claim-type-specific sub-rule was found, so the tool should use the general/default period logic.
- If your process leads you to select a claim-type-specific period mode, stop and verify the jurisdiction and period configuration.
Mismatched time units (monthly frequency vs. annual rate interpretation)
- Example: entering “0.04” while assuming it’s a monthly rate (when the calculator treats it as an annual rate) can significantly distort outcomes.
- Confirm how DocketMath interprets the discount rate relative to the payment frequency.
Ambiguous start dates
- Some schedules interpret “start date” as the first payment date; others treat it as the valuation date used to discount the future stream.
- If the first payment shifts by even a month, the schedule and discounted values can change.
Trusting totals without cross-checking present value
- A schedule can appear reasonable in nominal totals while not aligning with the present value assumptions.
- Always confirm the tool’s discounted/present value output is consistent with your chosen present value and discount rate.
Changing multiple settings at once
- If you adjust rate, term, and frequency in the same run, you won’t know which assumption drove the difference.
- Prefer one-change-at-a-time comparisons.

Pitfall to avoid: Using Tennessee default period logic while also applying a separate manually chosen “special period” (if your UI offers it) can double-apply timing assumptions and skew the payment schedule.

Try it

Ready to run a Tennessee (US-TN) structured settlement calculation in DocketMath?

Go to /tools/structured-settlement
Select Tennessee (US-TN)
Enter:
- Present value / lump-sum amount
- Discount rate
- Payment frequency
- Start date (if requested)
- Term/end date
Submit and check:
- The payment schedule table
- Total nominal payout
- Any discounted/present value outputs

If you want to compare scenarios, try two runs:

Run A: baseline assumptions
Run B: increase the discount rate by +1.0% while keeping everything else identical
Then compare how the payment amounts and totals change.