How to run Structured Settlement in DocketMath for Tennessee

Step-by-step

Follow these steps to run a Structured Settlement calculation in DocketMath for Tennessee (US-TN) using jurisdiction-aware rules. This walkthrough is designed for accuracy and repeatability—especially when you need the numbers to match your settlement structure assumptions.

• Select Tennessee in the Structured Settlement tool.
• Enter the trigger dates and any caps or rates.
• Run the calculation and save the output.

1) Open the Structured Settlement tool

1. Go to the primary call-to-action: /tools/structured-settlement
2. Confirm you’re on the Structured Settlement calculator (not the general settlement calculator or a timeline tool).

2) Select Tennessee jurisdiction (US-TN)

DocketMath uses jurisdiction-aware defaults for the calculator workflow. Set:

• Jurisdiction: US-TN (Tennessee)

If the interface asks about jurisdiction or rules, choose Tennessee explicitly. This matters because statute-driven timing assumptions (like default periods) can change based on jurisdiction settings.

3) Enter the settlement structure inputs

Most Structured Settlement calculators require a set of structure and timing fields. Use the same assumptions consistently across runs so you can compare scenarios.

Typical inputs you’ll enter include:

• Start date / first payment date (or an equivalent “beginning” date)
• Payment frequency (monthly, quarterly, annual, or another supported cadence)
• **Payment amount(s)

  • either a single level payment amount, or
  • stepped amounts by year/segment (if supported)
• Number of payments or end date
• Discount rate / interest rate / yield (depending on what DocketMath asks for)
• Payment type assumptions (e.g., level vs. stepped) if exposed as a switch

If your form uses different labels, keep the underlying meaning consistent:

• “Amount” determines cashflow.
• “Timing” determines when cashflow occurs.
• “Rate/yield” determines present value.

4) Run the calculation and review the outputs

After entering inputs, run the calculation. DocketMath will return outputs similar to:

• Total nominal payouts (sum of all scheduled payments)
• Present value (cashflows converted to a single value using the provided discount rate)
• Payment schedule summary (sometimes shown as a table)

Because the calculator is sensitive to timing and rate, small changes to either the schedule or the discount rate can meaningfully change the present value.

5) Apply Tennessee timing context (default period)

When you’re modeling litigation settlement timing, DocketMath may incorporate or surface timing-related assumptions. For Tennessee, the general/default statute period you should treat as the baseline is:

• General SOL Period: 1 years
• General statute: Tennessee Code Annotated § 40-35-111(e)(2)
  Source: https://law.justia.com/codes/tennessee/title-40/chapter-35/part-1/section-40-35-111/

Per the project note, no claim-type-specific sub-rule was found. That means you should apply this 1-year general/default period as the default timing assumption in Tennessee within this workflow, rather than attempting to infer a shorter or longer deadline for a specific claim category that you haven’t explicitly identified in your inputs.

6) Use scenario runs to test how outputs change

Run at least two scenarios so you can quantify sensitivity. For example:

• Scenario A: baseline payment amount and discount rate
• Scenario B: adjust discount rate by ±1% (or whatever increment the tool supports)
• Scenario C: adjust start date by 30–90 days if the tool allows it

Track what changes:

• Present value will usually move more than nominal payouts when the discount rate changes.
• If you shift the start date later, cashflows arrive later, typically lowering present value (all else equal).

A simple decision table helps keep your runs organized:

7) Export or capture results for your settlement record

If DocketMath provides an export/download, use it. If it doesn’t, copy:

• the payment schedule summary
• the nominal total
• the present value result
• the parameter values you entered (so anyone reviewing your math can reproduce it)

This reduces the risk of “mismatched assumptions” when the structured settlement terms are discussed with others.

Common pitfalls

These are the mistakes that most often distort Structured Settlement outputs in DocketMath for US-TN workflows.

• Mixing timing assumptions

  • Example: entering “start date” as the agreement date in one run and the “first payment” date in another. Present value will differ because discounting depends on when cash arrives.
• Using an inconsistent discount rate

  • Even a 0.5% or 1% difference can shift present value meaningfully.
• Changing payment cadence without updating totals

  • Quarterly vs. annual payments can look “close” in nominal totals but produce very different schedules and present value.
• Forgetting the Tennessee default timing period framing

  • Your Tennessee baseline timing assumption should be treated as the general/default 1-year period tied to Tennessee Code Annotated § 40-35-111(e)(2). Your note indicates no claim-type-specific sub-rule was found, so avoid “guessing” a different SOL for a claim category that you haven’t mapped into your model inputs.
• Assuming the tool auto-chooses legal deadlines

  • DocketMath calculations are math-driven. If a deadline affects your inputs (like start timing), you must reflect that in the entered dates or structure timing—not rely on the calculator to “discover” the right deadline for every scenario.

Try it

Ready to model a structured settlement for Tennessee in DocketMath?

1. Open the tool: **/tools/structured-settlement
2. Set:

   • Jurisdiction: US-TN
3. Enter:

   • start/first payment date
   • payment amount(s)
   • frequency
   • number of payments or end date
   • discount rate/yield
4. Run the calculation.
5. Compare at least two scenarios (baseline vs. adjusted discount rate, or baseline vs. delayed start) and record:

   • Nominal total payouts
   • Present value
   • any schedule table values DocketMath shows

Before you finalize results, sanity-check these items:

• Do payments occur when you expect them to?
• Does the output’s payment count match your entered end date (or number of payments)?
• Is the discount rate consistent across runs?

If you’re also validating related settlement math, you may find it helpful to review other DocketMath calculators—start with the structured-settlement workflow, then branch out from there.

Related reading

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