How to run Structured Settlement in DocketMath for Brazil

7 min read

Published April 15, 2026 • By DocketMath Team

Step-by-step

Run this scenario in DocketMath using the Structured Settlement calculator.

You can run a Structured Settlement calculation in DocketMath for Brazil (BR) by combining the tool’s inputs with jurisdiction-aware assumptions you select for the timing, escalation (if any), and time-value-of-money (discount rate). The goal is to model a payout stream (often over multiple years) rather than a single lump sum.

Note: This guide shows how to run the structured settlement calculator in DocketMath for Brazil. It’s not legal advice or a tax opinion—use it as a modeling workflow to prepare questions for your advisors.

1) Open the Structured Settlement tool

  1. Go to the primary call-to-action: /tools/structured-settlement
  2. Select Brazil (BR) as the jurisdiction (or confirm BR is pre-selected if your interface remembers prior choices).
  3. Choose the structured settlement calculator type (if you see multiple calculators).

2) Define the settlement timeline inputs

Structured settlement modeling typically depends on when payments occur and how long the stream runs. In DocketMath, you’ll typically provide inputs such as:

  • Start date / first payment date
  • Number of payment periods
  • Payment frequency (e.g., monthly, quarterly, annual—whichever options appear in the tool)
  • Payment pattern (e.g., fixed payments each period or a different schedule)

What changes in outputs:
When you alter the start date or frequency, the tool updates the timing of each payment date/period, which affects:

  • the present value of the structured stream,
  • the total nominal payout,
  • and any schedule table you generate.

3) Enter the lump sum or initial funding amount

Many structured settlement models use one of two “directions”:

  • Funding → payments: you enter the funding/lump sum, and the tool computes the implied payout schedule.
  • Payments → funding: you enter the target payout schedule (or payment amounts), and the tool computes the implied funding/present value.

Use whichever option DocketMath presents in your view. Practical workflow:

  • If you’re modeling from an existing settlement value, enter the lump sum / funding first.
  • If you’re modeling from negotiated payment amounts, enter the payment amount per period (or the payment formula) and let the tool compute the implied funding.

What changes in outputs:
Changing the funding amount scales the entire stream, which changes:

  • the present value (generally moving proportionally, depending on the tool’s structure),
  • and the per-period payout (in “funding → schedule” mode).

4) Set discount rate / growth assumptions (Brazil-aware)

Structured models require a time-value-of-money assumption (often a discount rate). In DocketMath for Brazil, use the field labeled for:

  • discount rate, interest rate, inflation/growth, or similar (exact wording depends on the calculator UI)

If the tool includes a Brazil-specific mode or jurisdiction-aware defaults, enable it for BR. Otherwise, input the rate you want to use for the model.

What changes in outputs:

  • A higher discount rate typically produces a lower present value for the same payout schedule.
  • A lower discount rate typically produces a higher present value for the same payout schedule.
  • If the tool includes inflation/growth, the difference between nominal and real economics can matter more over longer timelines.

5) Choose payout escalation (if available)

Some models allow payment escalation (for example, scheduled annual increases). If DocketMath provides fields such as:

  • escalation rate (annual increase)
  • step-ups (scheduled changes)

Set escalation to match the economic terms you are modeling.

What changes in outputs:
Escalation typically increases the nominal total paid over time, and can also shift present value depending on how escalation interacts with the discount rate.

6) Review the output schedule and summary metrics

After you run the calculator, DocketMath should show at least:

  • a period-by-period schedule (payments by date/period), and
  • summary metrics (e.g., present value and totals).

Use these checks:

  • Do payments land on the dates you intended?
  • Does the number of periods match your timeline?
  • Are totals consistent with the funding or payout inputs?

If there’s a table view, copy/export the results into your internal notes if your environment supports it.

7) Save or compare scenarios (run multiple variants)

A structured settlement is rarely “one and done.” Create scenarios that change only one major variable at a time so differences are explainable, for example:

  • Scenario A: fixed payments, longer term
  • Scenario B: fixed payments, shorter term
  • Scenario C: payments with escalation
  • Scenario D: different discount rate assumption

In DocketMath, rerun the tool with only one major change per scenario.

Interpretation tip:
If present value changes significantly when you tweak discount rate, that indicates the valuation is sensitive to time-value assumptions—capture this sensitivity in your notes.

8) Convert the modeling results into a settlement narrative

While DocketMath doesn’t replace drafting, you can turn your model into a structured internal summary, such as:

  • Settlement start: [date]
  • Payment frequency: [frequency]
  • Term: [# periods]
  • Payment amount/pattern: [fixed/escalating]
  • Discount rate assumption: [rate]
  • Results: present value, total nominal payout, and the schedule

Keep your narrative aligned with the exact inputs you used in the tool.

Common pitfalls

Structured settlement modeling is easy to mis-specify. Watch for these recurring issues when running DocketMath for Brazil (BR):

Example: You intend yearly payments, but the tool is set to monthly. The schedule table will look “busy,” and totals won’t align with expectations.

Some workflows are “funding → payments,” others are “payments → funding.” If you enter both inconsistently, the tool may still produce results, but your scenario won’t reflect the structure you mean to model.

People often input an inflation-like number into a discount rate field (or vice versa). That can materially distort present value.

It’s common for present value to be lower than total nominal payouts once discounting is applied. Don’t treat the gap as an error—treat it as the expected effect of time value.

If you change the term, escalation, and discount rate in a single run, it becomes hard to explain why results moved. Prefer one-factor changes per scenario.

Off-by-one period errors can happen when the start date doesn’t align with the chosen frequency.

Warning: A structured settlement can look “reasonable” in the schedule table while still being inconsistent with your intended funding mechanics. Always verify the tool’s mode (funding-to-schedule vs. schedule-to-funding) and confirm the total number of periods.

Try it

Ready to run your first Brazil-structured settlement model in DocketMath?

  1. Open the tool: /tools/structured-settlement
  2. Confirm Brazil (BR) is selected.
  3. Use a simple starting point:
    • Choose a start date
    • Pick a payment frequency (e.g., annual)
    • Set payment count (e.g., 10 periods)
    • Enter either funding amount or payment amount, based on what the tool expects
    • Enter a single discount rate assumption
  4. Click Calculate / Run
  5. Review:
    • the schedule table
    • the present value and total nominal payout
  6. Create one comparison run:
    • keep everything the same, but change discount rate by a small amount (e.g., +1%) to observe sensitivity.

If you want a quick reference while you test, revisit the same calculator entry at /tools/structured-settlement.

Related reading