How to run Structured Settlement in DocketMath for Oregon

Step-by-step

This guide walks you through running a Structured Settlement calculation in DocketMath for Oregon (US-OR) using jurisdiction-aware rules. You’ll see exactly what to enter, what the output means, and how changes in inputs affect the results.

1) Start the Structured Settlement calculator

1. Open the DocketMath Structured Settlement tool: ./tools/structured-settlement
2. Find the jurisdiction selector and set it to Oregon (US-OR).

What this changes:

• The calculator applies jurisdiction-aware logic and Oregon-specific labeling/handling where applicable (for example, how outputs are presented and how certain settlement-related fields are treated).

2) Choose the settlement inputs

Structured settlement calculations typically require (a) a payment schedule and (b) discounting / present value assumptions. In DocketMath, you’ll usually enter inputs in these categories:

A. Payment schedule

• Payment frequency (e.g., annual, monthly)
• Start date (date of the first payment)
• End date or number of payments (depending on what the UI asks for)
• **Payment amount(s)

  • Some runs support a single constant amount or a step-up/step-down structure (multiple amounts across different periods).

B. Calculation assumptions

• Discount rate (used to convert future payments to present value)
• Discount timing convention (if your UI offers a choice that specifies how/when discounting is applied relative to payment dates)

**C. Metadata (optional but useful)

• Settlement type or notes (helps you keep track when exporting or comparing scenarios)
• A lump sum vs. periodic payments toggle, if the tool provides one

If the tool offers an “import” or “set schedule” mode:

• Prefer building the schedule explicitly (by payment dates and amounts) rather than compressing payments into a single lump number. Explicit scheduling usually makes it easier to verify results and trace changes across scenarios.

3) Enter dates using real calendar dates

Use actual calendar dates rather than relative offsets.

Example:

• Payment start: 2026-05-01
• Frequency: monthly
• End: 2031-04-01 (or enter the number of payments if the UI requires it)

Why this matters:

• Even small date shifts can change the time-to-payment, which changes the discounted present value.

4) Set the discount rate carefully (and consistently)

The discount rate is typically one of the biggest levers in a structured settlement model.

A practical check you can use:

• Run the same payment schedule twice:

  1. Once with the default rate shown by DocketMath
  2. Again with a comparison rate (for example ±1.00 percentage point)

Expected output direction:

• Higher discount rate → lower present value
• Lower discount rate → higher present value

5) Review the output breakdown

After you run the calculation, DocketMath should display output values such as:

• Total periodic payments (nominal total)
  Sum of all future payments without discounting.
• Present value (PV)
  Discounted value of the same payment stream under your discount rate assumption.
• Payment-by-payment details or schedule summary (depending on the UI)

How to interpret it:

• Nominal total answers: “How much is paid out over time?”
• Present value answers: “What is that stream worth in today’s dollars given the discount rate?”

6) Adjust inputs and compare scenarios

DocketMath is most useful when you iterate. Create a small set of scenarios and compare them side-by-side:

• Scenario A: baseline schedule + baseline discount rate
• Scenario B: same schedule + discount rate +1.00%
• Scenario C: step-up schedule (if supported) + baseline discount rate

Checklist for meaningful comparisons:

• When changing discount rate, keep payment dates constant.
• When changing the payment schedule, keep the discount rate constant.
• Label scenarios (A/B/C) so you don’t accidentally mix outputs from different assumptions.

7) Export or copy results for workflow use

If DocketMath provides export options (CSV/PDF/copy-to-clipboard), use them after you finalize your scenario selection.

A good export practice:

• Export the schedule table and the PV summary
• Include the discount rate and the payment schedule inputs in your copied snapshot

This reduces the risk of mismatches later when numbers are reused in notes, spreadsheets, or discussions.

Common pitfalls

Here are the issues that most often cause Oregon Structured Settlement runs to produce confusing or inconsistent outputs in DocketMath.

• missing a required input
• using a stale rate or rule
• ignoring calendar or holiday adjustments
• skipping documentation of assumptions

Capture the source for each input so another team member can verify the same result quickly.

Payment timing mistakes

• Pitfall: Using a start date that doesn’t match the first actual payment date in the agreement.
• Consequence: Present value shifts because every payment is discounted from a different point in time.

Discount rate inconsistency

• Pitfall: Changing the discount rate without tracking which outputs correspond to which assumption.
• Consequence: You might compare PV numbers that were calculated under different rates, making scenario comparisons invalid.

Frequency vs. number-of-payments mismatch

• Pitfall: Entering “monthly payments” while also setting an end date that produces a different number of payments than expected.
• Consequence: The nominal total may still look plausible, but the PV changes because the time horizon changes.

Stepped schedules handled as lump payments

• Pitfall: Collapsing step payments (e.g., $2,000 then $2,500) into a single constant amount to “simplify.”
• Consequence: You lose fidelity; DocketMath can’t model the true cash-flow timing and amount changes.

Date format confusion

• Pitfall: Mixing date formats (for example 05/01/2026 vs 2026-05-01) if the UI accepts multiple formats.
• Consequence: Silent parsing differences can move dates by month/day.

Oregon-specific workflow expectation

Structured settlement processes can involve Oregon-related administrative or settlement review steps depending on case context. Even though DocketMath focuses on calculation, your real-world workflow may require additional supporting documentation.

• Pitfall: Treating the PV output as a “final approved amount” without aligning it to the settlement terms you intend to implement.
• Consequence: Downstream paperwork may not match the assumed schedule or timing.

Try it

Follow this quick “mini-run” to validate you’re set up correctly in DocketMath for Oregon (US-OR).

Open the Structured Settlement calculator and follow the steps above: Run the calculator.

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

Quick scenario to test

• Jurisdiction: **Oregon (US-OR)
• Payment frequency: Annual
• Start date: 2027-01-01
• Number of payments: 5
• Payment amount: $10,000
• Discount rate: Use the current default shown in the tool
• Run calculation

What you should check on the results screen

Use this checklist before you trust the output:

Compare two discount-rate runs

Duplicate the same scenario:

1. Discount rate at default → capture PV
2. Discount rate +1.00 percentage point → capture PV again

Expected direction:

• PV should decrease in run #2.

If PV moves opposite your expectation, revisit:

Related reading

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