Why Structured Settlement results differ in Brazil

The top 5 reasons results differ

Run this scenario in DocketMath using the Structured Settlement calculator.

Structured Settlement outcomes for Brazil in DocketMath can diverge even when the “case value” looks the same. In practice, the differences usually come from inputs that affect timing, indexation/inflation, and discounting—then from jurisdiction-aware rules that interpret those inputs slightly differently.

Below are the most common drivers to check when you compare two Brazil scenarios.

1. When the first payment starts

   • A settlement with a first installment in month 1 versus month 12 changes the discounting horizon and the present value (PV).
   • Even a 30–90 day shift can move the PV enough to flip which structure looks “best” in your comparison.

2. **How the schedule is defined (periodic vs. capped vs. last payment)

   • Two schedules with the same total number of installments can still differ if one scenario includes:

     • a final “catch-up” payment,
     • a prorated first payment,
     • or a different interval length (monthly vs. quarterly).
   • DocketMath’s structured-settlement calculator builds the cashflow timeline from those schedule rules, so PV will follow that timeline.

3. Indexation / inflation assumptions applied to installments

   • Brazil-focused models often include an indexation component so payments maintain purchasing power.
   • If one scenario applies indexing and another doesn’t (or uses a different index rate input), PV can change materially because the future cashflows change, not just the discounting.

4. Discount rate assumptions and compounding conventions

   • Small differences in the discount rate (e.g., 6.0% vs. 7.5%) can produce meaningful PV differences, especially over longer horizons.
   • DocketMath distinguishes how time is converted into periods (and applies compounding assumptions accordingly), so “the same” nominal discount rate may not map to the same PV if periodization differs.

5. Whether the model implies lump-sum liquidation vs. a structured payout

   • Some input sets implicitly model a hybrid (partial lump sum + stream).
   • If the “lump sum portion” is treated separately from the structured stream, the PV split and any internal feasibility/eligibility checks in the tool’s logic can differ.

How to isolate the variable

Use DocketMath’s structured-settlement workflow to run a controlled “single-change” test. Start from a baseline scenario, then change only one input at a time.

1. Pick a baseline

   • Keep constant:

     • payment frequency,
     • number of installments,
     • installment amount (or total payout),
     • start date of first payment,
     • and whether indexing is enabled (and its value).

2. Change exactly one driver per run

   • A practical order for fastest diagnosis:

     • Run A: baseline
     • Run B: adjust first payment date by +/− 3 months
     • Run C: adjust discount rate by +/− 1.0%
     • Run D: toggle indexation on/off (or change index rate by a small increment)
     • Run E: modify interval length (monthly ↔ quarterly) while keeping total count comparable
     • Run F: alter final payment logic (e.g., whether there is a catch-up / final adjustment)

3. Track impact with a quick comparison table

1. Interpret the results

   • If one variable causes the majority of the difference, you’ve found the primary driver.
   • If the PV gap is spread across multiple runs, the discrepancy is likely the result of compounded effects (e.g., timing + indexation + discount rate interacting).

If your goal is to reconcile two parties’ numbers, this approach helps you identify whether the mismatch is primarily a timing mismatch, an indexation mismatch, or a discounting mismatch—rather than assuming the economics are inherently different.

Also, if you need to reproduce inputs quickly, start here: /tools/structured-settlement

Gentle reminder: This is not legal advice. Structured settlement calculations can be sensitive to assumptions, and jurisdiction-aware rules may require careful input verification.

Next steps

1. Confirm your cashflow timeline

   • Verify:

     • the start date,
     • payment cadence,
     • and how DocketMath translates dates into internal periods.
   • A small date alignment issue can shift period counts and materially change PV.

2. Normalize rate inputs

   • Ensure both scenarios use the same “bundle” of assumptions:

     • discount rate,
     • compounding/period convention,
     • and indexation settings.
   • If one scenario changes only “the discount rate” but uses a different period convention, the PV impact may not match your expectation.

3. Document the input set you used

   • Save your DocketMath structured-settlement inputs (screenshots or exports).
   • This makes it easier to explain why PV changed and prevents assumption drift during review.

4. Do a targeted sensitivity pass

   • Once you identify the top 1–2 drivers, test ±10% (or similarly sized adjustments) to confirm:

     • direction of impact (PV up/down),
     • and rough magnitude.

Related reading

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