Worked example: Structured Settlement in Delaware

Example inputs

This worked example shows how to model a structured settlement in Delaware (US-DE) using DocketMath and a jurisdiction-aware statute window for timing. It’s written for planning and workflow purposes—not as legal advice.

Here is a simple illustration for Delaware. These values are for demonstration only and should be replaced with your actual inputs.

• Principal or amount: $100,000
• Rate or cap: 10%
• Start date: 2025-01-15
• End/as-of date: 2025-09-30

Scenario summary

• A claimant expects to receive an award that may be paid over time via a structured settlement arrangement.
• The key timing question is whether a claim would generally need to be brought within Delaware’s general statute of limitations (SOL).
• Because this example does not identify a claim-type-specific sub-rule, it uses Delaware’s default general SOL period.

Delaware SOL rule used in this example (timing window)

• General SOL period: 2 years
• General statute: Title 11, §205(b)(3) (Delaware Code)
• Source: https://delcode.delaware.gov/title11/c002/index.html?utm_source=openai

Inputs for the DocketMath “structured-settlement” calculator

Below are the concrete values used to generate the output.

Calculator-related assumption

Structured settlements often involve negotiated assumptions (e.g., escalation, discount rate, tax and allocation mechanics). DocketMath focuses on the timing and cash-flow structure inputs you provide; it does not “decide” legal rights.

If your actual settlement agreement uses different frequencies (quarterly, annual) or escalation terms (fixed vs. CPI), change the inputs accordingly—your outputs will shift materially.

Example run

Run the Structured Settlement calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

Step 1: Compute the Delaware general SOL deadline (timing gate)

Using the general rule:

• General SOL period: 2 years
• Anchor date: 2026-01-10

General SOL deadline = 2028-01-10

Because this walkthrough does not use any claim-type-specific sub-rule, it applies the default general period from 11 Del. C. §205(b)(3).

Step 2: Build the structured settlement cash flows

Given the inputs:

• Lump sum: $25,000 on 2026-04-15
• Monthly payments: $2,500/month starting 2026-04-15
• Term: 10 years (120 monthly payments)
• Discount rate: 4.0% APR

A simplified timeline model looks like this:

Step 3: Run the DocketMath structured settlement calculation

Open DocketMath at the primary action:

• Primary CTA: /tools/structured-settlement

Then enter the inputs (anchor date, payment start date, monthly payment, lump sum, term, discount rate). DocketMath generates outputs such as:

• Total nominal value (lump sum + sum of all periodic payments)
• Present value (PV) of the payment stream, discounted at the provided rate
• Payment count / cash-flow schedule indicators (based on frequency and term)

Output (illustrative from the entered inputs)

Using the numbers above:

1. Number of monthly payments

   • 10 years × 12 months/year = 120 payments

2. Total nominal value

   • Lump sum: $25,000
   • Periodic payments: 120 × $2,500 = $300,000
   • Total nominal = $325,000

3. **Present value (PV)

   • PV depends on discounting and timing (including monthly spacing and the first payment date).
   • With 4.0% APR, PV will be meaningfully less than $325,000, because payments arrive over time.

DocketMath computes PV based on your entered frequency (monthly) and timing (first payment date).

Step 4: Tie the timing gate to the structure

This example connects the SOL timing window to the payment schedule:

• SOL deadline (general/default): 2028-01-10
• Structured payments begin: 2026-04-15

Under these inputs, periodic payments begin before the general SOL deadline. That can be relevant for planning and coordination, but enforceability and settlement eligibility can still depend on the specific claim type and facts—which this walkthrough does not model.

Sensitivity check

Even in a single jurisdiction, structured settlement outputs can swing based on a few numeric inputs. Here are three sensitivity checks you can run in DocketMath quickly.

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

1) Discount rate sensitivity (PV is the most sensitive output)

Re-run only the discount rate while keeping everything else the same.

Why it matters: If your assumptions reflect different investment yields, cost of capital, or discount conventions, the PV output can change significantly even though the nominal cash flows stay at $325,000.

2) Payment start date sensitivity

Change payment start date by ±90 days:

• Start date earlier: 2026-01-15
• Start date later: 2026-07-14

Expected impact:

• Earlier start increases PV because payments occur sooner.
• Later start decreases PV because more time elapses before cash flows arrive.

3) Monthly payment sensitivity (nominal and PV scale together)

Change monthly payment from:

• $2,500/month → $2,250/month (−10%) or $2,750/month (+10%)

Expected impact:

• Nominal total changes proportionally for the periodic stream (lump sum stays fixed unless you also change it).
• PV moves in the same direction, typically nearly proportional.

Checklist for repeatable runs

Use these toggles consistently when documenting your analysis:

Related reading

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