How to run Structured Settlement in DocketMath for New York

Step-by-step

Run this scenario in DocketMath using the Structured Settlement calculator.

You can run a Structured Settlement calculation in DocketMath for New York (US-NY) and get jurisdiction-aware outputs—without manually tracking date math. Use this workflow to focus on what to enter, what DocketMath calculates, and how outputs typically change when you adjust inputs.

1) Open the Structured Settlement calculator

1. Go to the tool: /tools/structured-settlement
2. Confirm the jurisdiction selector shows New York (US-NY) (or select it if prompted).

This matters because DocketMath applies jurisdiction-aware timing rules for New York when it computes relevant windows around filing/limitations.

2) Enter the structured settlement and payment structure inputs

In the Structured Settlement tool, you’ll typically provide inputs such as:

• **Lump sum (if any)
• Start date for the structured payments
• Payment frequency (e.g., monthly, yearly)
• Number of payments or end date
• Payment amount (and any escalation terms, if the UI supports them)
• Discount rate / present value assumptions (if the calculator includes them)

How outputs change:

• Move the start date forward → usually reduces present value, because more payments occur farther in the future relative to the calculator’s reference point.
• Increase duration (more payments / later end date) → increases total future payout, and present value may rise or fall depending on the discount rate and payment timing.
• Change frequency (monthly vs. yearly) → changes the timing pattern of receipts, which can shift present value even if the total amount over multiple years is similar.

3) Add any timing/limitations window you want DocketMath to reference

For New York, DocketMath’s jurisdiction-aware default timing reference in this workflow uses New York’s general criminal procedure limitations period:

• General SOL Period: 5 years
• **General Statute: N.Y. Crim. Proc. Law § 30.10(2)(c)
• Source: https://www.nysenate.gov/legislation/laws/CPL/30.10

Important constraint (per the brief): no claim-type-specific sub-rule was found in the jurisdiction notes provided. So this workflow uses the general/default 5-year period as the governing timing reference and should not assume an alternate SOL for a specific claim type.

In the calculator UI, look for a field such as:

• “limitations period,” “lookback window,” “earliest filing date,” or “deadline”
• a toggle like “use jurisdiction default”

Recommended approach: if the tool provides a jurisdiction default, select it rather than entering a custom window. If you must override it, record the override in your own notes so you can interpret later outputs correctly.

4) Review what DocketMath outputs (and map them back to your inputs)

After you submit inputs, DocketMath typically returns results in two categories:

A) Settlement cash-flow summary

• Total future payout
• Schedule timing (start/end)
• Payment count based on frequency and duration

B) Discounted / scenario results

• Present value of the structured payments (and possibly lump sum components)
• Optional comparisons if the tool supports multiple scenario runs

Connect outputs to inputs:

• If the start date changes, the present value often moves noticeably even when the amount per payment stays the same.
• If frequency changes, you’ll usually see a different payment count and a different timing pattern—both of which can change present value.
• If the discount rate changes, present value can change substantially even if the cash-flow schedule stays the same.

5) Run a baseline scenario, then adjust one variable at a time

To keep interpretation clean, follow this order:

1. Run Scenario 1 using your best estimate inputs.
2. Change only one input.
3. Rerun and compare:

   • present value
   • total payout
   • payment count / end date
   • any displayed timing window reference

A practical adjustment checklist:

This makes it easier to explain why results moved between runs—without guessing.

6) Capture the jurisdiction-aware timing reference alongside the financial results

If DocketMath surfaces a limitations window reference (or “jurisdiction default” label), capture it next to the financial outputs for your run documentation.

For New York in this workflow, confirm the tool references:

• the general 5-year default
• based on **N.Y. Crim. Proc. Law § 30.10(2)(c)

This supports consistency across runs and helps prevent confusion later when you compare the timing reference to the payment schedule assumptions.

Common pitfalls

Structured settlement calculations are straightforward to run but can be easy to misread—especially when timing assumptions and discounting interact. The most common issues in DocketMath workflows for New York (US-NY) typically include:

1. Assuming the wrong limitations window

   • DocketMath’s New York timing reference used in this workflow is the general/default 5-year period.
   • No claim-type-specific sub-rule was identified in the provided jurisdiction notes, so you should not assume a different SOL for a specific claim type based on this template alone.
   • Always verify the calculator is using the jurisdiction default (when applicable).

2. Mixing up “start date” vs. the calculator’s reference date

   • Many users enter the payment schedule start date correctly, but misunderstand what date DocketMath uses as the baseline for discounting.
   • Result: the payment schedule can be right while present value seems “unexpected.”

3. Confusing payment frequency with the intended duration

   • Example: selecting monthly but providing an annual-oriented duration or payment count.
   • Outcome: the number of payments and the implied schedule length change, which changes both total payout and present value.

4. **Focusing on present value only (or total payout only)

   • Present value can decrease even when total future payouts increase, especially with a higher discount rate and later receipt dates.
   • Compare both:

     • total future payout
     • present value

5. Not documenting scenario assumptions

   • If you rerun multiple scenarios without noting what changed, it becomes hard to interpret deltas.
   • Keep a short internal log of: start date, frequency, end date/number of payments, discount rate, and whether you used jurisdiction default vs. custom limitations.

Try it

Use this quick run plan to validate your US-NY setup in DocketMath:

1. Open /tools/structured-settlement
2. Set the jurisdiction to New York (US-NY).
3. Enter your payment schedule:

   • start date
   • frequency
   • payment amount
   • number of payments or end date
4. Keep the limitations window on the jurisdiction default:

   • New York general default: 5 years
   • Based on **N.Y. Crim. Proc. Law § 30.10(2)(c)
   • Source: https://www.nysenate.gov/legislation/laws/CPL/30.10
5. Run the calculation and save the outputs.

Then do two sanity-check tweaks:

• Move the start date forward by 30 days and rerun

  • Expect: present value should decrease (payments occur later relative to the discounting baseline).
• Change frequency from monthly to yearly (keeping the same overall calendar coverage as best you can) and rerun

  • Expect: a different payment timing pattern and present value shift due to receipt granularity.

Final verification step:

• If DocketMath displays a limitations deadline or timing window reference, confirm it reflects the general 5-year default and does not switch to a different claim-type period. This matches the “no claim-type-specific sub-rule found” constraint in the brief.

Related reading

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