How to calculate Settlement Allocator in Brazil

Quick takeaways

Run this scenario in DocketMath using the Settlement Allocator calculator.

• Settlement Allocator (BR) in DocketMath turns a settlement agreement’s total amount into case-by-case allocations (for example, damages/principal vs. costs) using Brazil-specific jurisdiction-aware rules.
• You typically allocate in two layers: (1) allocation of the settlement “pool” and (2) mapping that pool to claim components (such as principal/damages and ancillary items).
• Your result changes most when you adjust claim component weights, who receives which component, and how the agreement treats costs/fees.
• Use DocketMath to generate an allocation table that is consistent, auditable, and easy to reconcile back to the settlement wording.

Inputs you need

Before you run the Settlement Allocator (Brazil / BR) in DocketMath, gather inputs that reflect how Brazilian settlements are commonly drafted and broken into components.

Use this intake checklist as your baseline for Settlement Allocator work in Brazil.

• jurisdiction selection
• key dates and triggering events
• amounts or rates
• any caps or overrides

If any of these inputs are uncertain, document the assumption before you run the tool.

1) Settlement-level information

• Total settlement amount (BRL)

  • Example: BRL 1,250,000.00
• Allocation basis date (optional, but recommended)

  • Helps you timestamp figures for internal reconciliation (for example, “as of 15 Mar 2026”).
• Payment structure

  • One-time payment vs. installments. Even if DocketMath allocates the total first, installments often affect how you reconcile later.

2) Claim components and allocation rules

You’ll need a list of claim components that the settlement covers (names vary by agreement). Common categories you may see:

• Damages / principal
• Interest (if separately treated)
• Monetary correction (if separately treated)
• Contractual or statutory penalties (if included)
• Costs and expenses
• Attorneys’ fees (often handled distinctly depending on drafting)

For each component, capture:

• Component label
• Whether it is included in the settlement pool
• Weight or fixed amount (choose one method per component, consistently)
• Allocation method

  • Weight-based (percentages across components)
  • Fixed amount (hard BRL amounts per component, with the remainder distributed)
  • Hybrid (fixed for some components + weights for the remainder)

3) Parties and recipient mapping

Settlement allocation depends on who receives what.

• Payee list

  • Plaintiff(s) / claim holder(s)
  • Co-claimants (if applicable)
  • Third parties (if included in the agreement)
• Recipient-to-component mapping
  Example approaches:

  • “All damages go to Party A; costs split 70%/30% between Party A and Party B.”
  • “Costs: BRL 120,000 to Party A; BRL 80,000 to Party B.”

4) Allocation constraints (the “guardrails”)

These prevent outputs that conflict with settlement drafting:

• Minimum/maximum caps per component (if the settlement states caps)
• Remainder rules

  • If fixed amounts don’t sum to the total, decide where the remainder goes:

    • “Distribute remainder across weight-based components proportionally”
    • “Apply remainder to principal/damages”
• Rounding preference / precision

  • Brazilian BRL allocations are sensitive to cents. Decide how you want rounding handled (commonly 2 decimals).

5) Jurisdiction-aware toggles (BR)

DocketMath’s BR jurisdiction-aware rules are designed to fit common Brazilian allocation conventions. You’ll typically set:

• **Brazil jurisdiction profile (BR)
• Allocation view

  • “Component view” (what each component is worth)
  • “Recipient view” (what each party gets)
  • “Both” (often best for auditability)

How the calculation works

DocketMath’s Settlement Allocator (BR) produces a structured allocation from your settlement total by applying a consistent set of steps. Conceptually:

1. Determine the settlement pool
2. Allocate the pool to components
3. Split component amounts among recipients
4. Validate totals and constraints

Step 1: Compute the settlement pool

Start with the Total settlement amount (BRL) you enter.

If your agreement distinguishes amounts that are outside the pool (for example, separate items the settlement treats differently), handle it by either:

• excluding them from the Total settlement amount you input, or
• marking the corresponding components as included = no so DocketMath does not allocate them.

Output: a normalized “pool” number that all component allocations must sum to.

Step 2: Allocate the pool to components

DocketMath supports component allocation using weights, fixed amounts, or hybrid logic.

A) Weight-based allocation

If you provide weights for included components, DocketMath computes:

• Component amount = Pool × (component weight / sum of weights)

Example (hypothetical):

• Pool: BRL 1,000,000
• Included components with weights:

  • Damages: 70
  • Costs: 20
  • Attorneys’ fees: 10
    Sum weights = 100

Then:

• Damages = 1,000,000 × 70/100 = 700,000
• Costs = 1,000,000 × 20/100 = 200,000
• Fees = 1,000,000 × 10/100 = 100,000

B) Fixed amount allocation

If components have fixed amounts:

• DocketMath assigns those fixed BRL values first.
• Then it calculates the remaining pool (if any).
• The remainder is distributed using your remainder rule:

  • proportionally across weight-based components, or
  • to a designated remainder component (commonly “Damages/Principal”).

C) Hybrid allocation (fixed + weights)

Hybrid setups are common when an agreement explicitly quantifies some items and leaves others bundled.

• DocketMath handles fixed components first.
• Then it uses weights to allocate the remainder across the remaining included components.

Important: if fixed components exceed the pool, allocations can’t go negative. In that case, you’ll need to revise inputs or the tool’s configuration.

Step 3: Split component amounts among recipients

Once DocketMath calculates each component’s amount, it distributes them to parties based on your mapping rules:

Common patterns:

• Component-only ownership

  • Damages → Party A only
  • Costs → Party A/B split
• Recipient weight splits

  • “Party A gets 60% of all damages; Party B gets 40%”
• Direct BRL allocations

  • “Costs: BRL 120,000 to Party A; BRL 80,000 to Party B”

DocketMath ensures recipient totals:

• sum correctly within each component, and
• sum to the overall settlement pool.

Step 4: Validate totals, constraints, and rounding

Brazil-focused workflows often require tight reconciliation.

DocketMath typically:

• applies a rounding precision (commonly 2 decimals),
• ensures rounding deltas are absorbed according to your remainder/rounding settings.

You should confirm:

• Total allocated = Total settlement amount
• No component exceeds caps (if provided)
• Recipient mapping has no unallocated gaps

Common pitfalls

• Component weights don’t match what you intended

  • If you omit a component or mis-mark included = no, weight-based allocations will shift unexpectedly.
• Fixed amounts exceed the pool

  • Even a small mismatch (for example, BRL 1.00) can create a negative remainder.
  • Fix by verifying whether your typed “Total settlement amount” includes the items you fixed (costs/fees, corrections, etc.).
• Mixing “included” and “outside pool” items

  • If the agreement states certain amounts are separate payments, don’t allocate them. Either exclude them from the pool input or mark them included = no.
• Recipient mapping only covers part of the components

  • You might allocate damages correctly but leave costs/fees unassigned, creating imbalance that DocketMath will flag.
• Rounding creates off-by-one-cent totals

  • Hybrid allocations are especially sensitive. Make sure your remainder/rounding handling aligns with how the agreement expects cents to be handled.

Sources and references

No external sources were used for this walkthrough. The mechanics described reflect how DocketMath’s Settlement Allocator operates as a calculation tool, not an interpretation of any specific settlement wording.

Start with the primary authority for Brazil and confirm the effective date before relying on any output. If the rule has been amended, update the inputs and rerun the calculation.

• Primary authority reference

Next steps

1. Open DocketMath → Settlement Allocator (BR) using the primary CTA:

   • /tools/settlement-allocator
2. Enter the settlement pool (total BRL) exactly as the agreement defines the allocable amount.
3. Add component lines using weights, fixed BRL, or hybrid logic—mark included/excluded deliberately.
4. Map recipients to components and confirm each recipient has a defined share.
5. Review the output tables:

   • Component allocation totals
   • Recipient allocation totals
   • Final “sum check” that equals the settlement pool
6. Cross-check labels against the agreement

   • For audit clarity, align DocketMath component names to your settlement’s terminology where possible.

Related reading

• Settlement Allocator Guide for Alabama
• Settlement Allocator Guide for Arizona
• Settlement Allocator Guide for Colorado