Choosing the right Structured Settlement tool for Brazil
7 min read
Published April 15, 2026 • By DocketMath Team
Choose the right tool
Run this scenario in DocketMath using the Structured Settlement calculator.
Choosing the right Structured Settlement tool for Brazil is less about finding a single “best” calculator and more about matching your case facts to the tool’s inputs and Brazil-aware (BR) constraints. With DocketMath, the goal is to run scenarios quickly—different payment schedules, inflation/escalation assumptions, and start dates—while keeping your BR configuration consistent.
Start with what “structured settlement” means in your workflow
Before you enter any numbers in DocketMath, clarify which workflow you’re trying to support:
- Compliance-minded planning: You want payment schedules that stay internally consistent with your Brazil setup and don’t accidentally mix incompatible assumptions (for example, how discounting and timing are applied).
- Damage economics / modeling: You want to convert a claim amount (or a target present value) into a stream of payments using a chosen structure (e.g., lump-sum + installments, or fully amortized installments).
- Settlement packaging: You need schedule-ready outputs—tables of payments, totals, and present-value snapshots—to support negotiations and internal review.
Each workflow maps to a different way you’ll configure the structured-settlement calculation.
Use the right DocketMath tool: structured-settlement
For Brazil, the most direct match is the DocketMath Structured Settlement calculator (tool page: /tools/structured-settlement). Use it when you have:
- A total settlement amount or a **target present value (PV)
- A payment schedule design (monthly, annual, staged, etc.)
- A start date and a duration (or number of periods)
- Optional assumptions such as a discount rate (if you want PV) and timing conventions, where applicable
If you’re already working in the DocketMath workflow, start with /tools/structured-settlement and focus on building clean, labeled scenarios.
Note: DocketMath helps you structure and quantify scenarios. It doesn’t replace legal review of Brazil-specific settlement mechanics (such as approval pathways or tax treatment). Treat outputs as planning inputs, not final legal conclusions.
Pick inputs that actually change the output in Brazil scenarios
The structured-settlement calculator is only as useful as the assumptions you feed it. The inputs below are the most practical to validate because they directly change the schedule and the present value.
| Input you provide in DocketMath | Typical example for BR workflow | What changes in the output |
|---|---|---|
| Total amount (or target PV) | BRL 2,500,000 | Sets the scale of the payment plan (schedule totals and PV anchor) |
| Payment frequency | Monthly or annual | Determines number of payments and how cash flows are spaced |
| Start date | 2026-07-01 | Shifts timing used in present value (later start generally lowers PV, all else equal) |
| Duration / number of periods | 60 months / 5 years | Changes how long cash flows run and the number of scheduled rows |
| Structure type | Equal installments vs. staged increases | Alters per-period amounts (early vs. late cash flow profile) |
| Discount rate assumption | e.g., 8% annually (or equivalent effective rate) | Changes PV and the “implied” level of payments under your structure |
| Inflation/escalation (if you model it) | 4% annual escalation | Raises later payments; PV impact depends on discounting vs. escalation |
Even small timing adjustments (for example, starting ~30 days later) can move present value materially—especially when discount rates are high and the horizon is long. That’s why scenario labeling matters (more on that below).
Use jurisdiction-aware rules for Brazil (BR) intentionally
When you configure the calculation for BR, the objective isn’t to “guess” Brazil-specific mechanics. It’s to keep your calculations coherent with a BR-focused configuration profile so scenario outputs are comparable and explainable.
In practice:
- Set jurisdiction to BR in the tool so the calculation runs under your BR-aware conventions/configuration.
- Use one assumption set per scenario. If you change discount rate, escalation, or start date, create a new scenario rather than mixing assumptions.
- Match the schedule design to negotiation needs:
- If you want predictability, use equal installments or a stable staged profile.
- If cash-flow planning matters, adjust frequency (monthly vs. annual) and duration and compare PV.
A quick “tool selector” decision for Brazil
Use this sequence to choose the right DocketMath setup quickly inside /tools/structured-settlement:
- Do you have a total settlement amount and want a payment stream?
Enter the amount, choose your schedule (frequency, start date, duration), and run the scenario to generate installments. - Do you have a target present value and want to back into payments?
Use PV as the anchor and solve for installment levels under your schedule assumptions. - Do you need to compare multiple structures (staged vs. equal)?
Run separate scenarios and compare the schedule table and PV snapshot side-by-side. - Do you need a negotiation-ready summary?
Use the generated schedule and totals as your working document, alongside your internal notes about assumptions.
When you align inputs to your intended workflow, you can move from “settlement discussion” to “settlement math” fast—without losing track of which assumptions drove which result.
Next steps
Once you’ve chosen the DocketMath structured-settlement tool for BR, the next steps are about validating sensitivity and turning outputs into decision-ready artifacts.
Use the Structured Settlement tool to produce a first pass, then share the output with the team for review. You can start directly in DocketMath: Open the calculator.
1) Define your scenario list (minimum 3)
Set up at least three scenarios so you can see sensitivity instead of relying on a single run:
- Scenario A (baseline): Your preferred discount rate and structure (e.g., equal monthly installments for 60 months).
- Scenario B (timing): Same structure and assumptions, but shift the start date (e.g., start 3 months later).
- Scenario C (structure): Same total amount (or PV target), but use a staged profile (e.g., higher early payments vs. higher later payments).
In DocketMath, treat each as a separate run so the math and assumptions don’t blur.
2) Document assumptions next to each run
For each scenario, capture the key inputs:
- Total amount (or target PV)
- Start date
- Frequency
- Number of periods / duration
- Discount rate assumption (if PV is enabled)
- Any escalation/inflation assumption
This is what lets you explain, quickly and clearly, “why the payment changed” when stakeholders ask.
Warning: Discount rate and timing are typically the biggest drivers of present value. If two scenarios differ only by discount rate, don’t compare them as though they represent the same economic bargain.
3) Use the output schedule for review, not just acceptance
Treat the schedule table as a quality-control artifact:
- Check totals: Does the sum of payments match your entered target (or match after rounding)?
- Check period count: Is the number of rows consistent with your duration?
- Check edge dates: If the tool uses month-to-month or day-count conventions, confirm your intended start and end dates.
If the tool rounds installments, be mindful that rounding often affects the final payment (e.g., last payment adjusted to reconcile totals).
4) Stress test with a fast “what if” sweep
Before finalizing, run a small sweep to test robustness:
- Discount rate: ±1.0 percentage point (e.g., 7% vs. 8% vs. 9%)
- Duration: shorten vs. extend (e.g., 48 vs. 60 vs. 72 months)
- Structure: equal installments vs. staged
Even a 6–9 run sweep can reveal whether the plan is stable or highly sensitive to one assumption.
5) Prepare a decision-ready summary for stakeholders
Your internal deliverable should include:
- The selected scenario’s payment schedule
- A present value snapshot (and the discount rate used)
- A short bullet list describing what changed vs. baseline (e.g., “later start date” or “staged payments”)
If your team wants consistency across matters, reuse the same scenario template each time you model BR structures—so outputs remain comparable.