Inputs you need for Structured Settlement in Brazil
5 min read
Published April 15, 2026 • By DocketMath Team
Inputs you will need
Structured settlement in Brazil (often used in the context of personal injury, workplace accidents, or other civil claims) typically requires a consistent set of underwriting and documentation inputs so DocketMath can compute a payment schedule and produce a documentation-ready “shape” of the deal.
Below is a practical, checklist-style list of inputs you’ll want to gather upfront. The goal is to minimize rework—each missing input usually forces a re-run of the calculator and a redesign of the settlement payment plan.
Core inputs (settlement economics)
Claim / beneficiary inputs (who receives and how)
Tax, deductions, and compliance-adjacent inputs (process realism)
Structured settlements often interact with Brazil’s broader tax and reporting environment. DocketMath can help you structure the payment plan you’re negotiating, but you’ll still need operational confirmation on tax treatment with your advisors (this is not legal or tax advice).
Collect these “process” inputs:
Legal-structure readiness inputs (documentation scaffolding)
Even without drafting here, you’ll want to align your model with how the agreement will be signed and implemented.
Note: DocketMath is designed to turn settlement inputs into a consistent payment schedule. It doesn’t replace legal drafting or tax classification. Use the output to drive negotiations and documentation planning, not to finalize legal obligations.
Where to find each input
Use the checklist below as a “source map.” The idea is to connect each input to where you can reliably obtain it in your workflow.
| Input | Typical place to capture it | What to look for |
|---|---|---|
| Settlement date / effective date | Draft settlement agreement; settlement term sheet | “Commencement date,” “effective date,” or “first payment date” |
| Total settlement amount (BRL) | Term sheet; court agreement draft; insurer proposal | Ensure it matches the agreed gross amount |
| Payment frequency | Proposal schedule; insurer / payor exhibit | Monthly vs. quarterly is usually explicitly stated |
| Payment count / term | Payment exhibit; negotiated duration | The schedule often states “for X years” |
| Interest / growth assumption (if any) | Internal model; commercial proposal; trustee docs | Look for “index,” “inflation,” or assumed rate language |
| Beneficiary type | Settlement agreement and personal data intake | Individual name vs. institutional recipient |
| Beneficiary residence | Intake form; KYC packet | Residency and ID details for operational handling |
| Indexing preference | Term sheet language | Inflation-linked references often appear as a clause |
| Tax responsibility (process) | Payor instructions; compliance checklist | “Withholding” and “reporting” responsibilities |
| Payment method | Settlement agreement implementation section | Bank transfer details vs. dedicated account process |
| Milestones | Medical/treatment plan summaries; negotiated exhibit | Concrete dates for milestone triggers |
A quick operational workflow that works in Brazil:
- Collect the term sheet values (amount, term, frequency, start date).
- Verify beneficiary details and residency flags.
- Confirm indexing or fixed-payment treatment.
- Run DocketMath to generate the schedule.
- Back-check the schedule against the agreement exhibit you’ll attach.
Run it
Once inputs are gathered, you can produce a structured payment schedule using DocketMath’s structured-settlement calculator in the BR (Brazil) jurisdiction context.
- Open the calculator and choose the Brazil (BR) jurisdiction context.
- Enter inputs in this order (recommended to reduce errors):
- Settlement date / first payment date
- Total settlement amount (BRL)
- Payment type (lump sum + installments vs. fully periodic)
- Term and payment frequency
- Indexing or interest/growth assumption (if applicable)
- Beneficiary and payment method flags (for documentation realism)
- Review the output:
- Payment schedule table (dates + amounts)
- Totals reconciliation (sum of payments vs. settlement amount)
- Any computed cadence outputs (e.g., end date based on count/frequency)
If you want to jump straight to the primary call-to-action:
- Use DocketMath Structured Settlement (BR): **/tools/structured-settlement
How outputs change when inputs change
Below is a quick “impact map” so you can predict what changes in the output:
| Change you make | Likely effect on output |
|---|---|
| Increase total settlement amount (BRL) | Every periodic payment scales up; totals reconcile to the new gross amount |
| Extend term by 1 year | Payments often decrease (spread across more installments) |
| Switch frequency (monthly → quarterly) | Payment count drops; amounts per payment generally increase to keep totals aligned |
| Add indexing / growth assumption | Later payments may increase or shift depending on how the model applies growth |
| Move settlement start date | Schedule dates shift; milestone alignment may require re-checking |
Pitfall: Changing frequency (monthly vs. quarterly) without updating the term or payment count often produces schedules that look “reasonable” but misalign with what your settlement exhibit requires. Always reconcile the total payment count and end date after each run.