Worked example: Settlement Allocator in Brazil

Example inputs

Run this scenario in DocketMath using the Settlement Allocator calculator.

Below is a worked example showing how you can use DocketMath’s Settlement Allocator to distribute a single settlement payment among typical Brazilian case buckets, using jurisdiction-aware rules (Brazil / BR).

Scenario

A business settles a civil lawsuit and agrees to pay R$ 600,000 in one lump sum. The settlement agreement indicates the payment covers multiple components, broadly matching the following items:

• Principal / damages: R$ 420,000
• Monetary adjustment (correction): R$ 120,000
• Interest (juros): R$ 45,000
• Attorney fees (sucumbenciais): R$ 15,000
• Other costs (e.g., custas remanescentes): R$ 0
• Tax treatment: “Use Brazilian defaults” (tool’s BR logic)

Allocation guidance you’ll enter in DocketMath

In DocketMath, you’ll typically provide:

1. Total settlement amount
2. Case component weights or amounts (depending on the tool’s mode)
3. Jurisdiction set to Brazil (BR)
4. How to handle statutory allocation/tax logic (the tool’s Brazil-aware defaults)
5. Rounding behavior (usually “round to 2 decimals”)

Example input table (what you’d type into the tool)

Contract/settlement scope flags (optional but useful)

If your settlement agreement clarifies coverage, you can reflect that in the inputs via “flags.” In this example:

• Includes attorney fees: Yes
• Includes correction and interest: Yes
• Payment is a single lump sum: Yes

These flags mainly affect how the tool breaks down the lump sum and preserves internal consistency across buckets.

Example run

You can run the allocator directly from the primary CTA: /tools/settlement-allocator.

Run the Settlement Allocator calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

Tool configuration

Use these settings for the baseline run:

• Jurisdiction: **Brazil (BR)
• Total: R$ 600,000.00
• Component amounts: as shown above
• Tax/processing: Use Brazilian defaults
• Rounding: 2 decimals

What the tool does (in plain terms)

DocketMath takes your component amounts and allocates the total settlement to each bucket. When the component totals match the provided total, the tool mostly returns the same numbers (still with consistent rounding). If they don’t match, the tool scales proportionally so that the allocated buckets sum exactly to the settlement total.

In our scenario, the component totals add up cleanly:

• R$ 420,000.00 + 120,000.00 + 45,000.00 + 15,000.00 + 0.00 = R$ 600,000.00

That means the run should behave like a “no scaling needed” output (still with consistent formatting and any jurisdiction-aware default rules).

Expected allocator output (Brazil / BR)

Here’s how the Settlement Allocator would typically display the allocation breakdown:

Output artifacts you should look for

Most settlement allocator workflows in practice output more than just the table. After running, check for:

• Bucket-by-bucket totals (must sum to the settlement total)
• Rounding reconciliation line (ensures no “penny mismatch”)
• Exports / summaries (often used for internal accounting or settlement memos)
• Jurisdiction label (confirm you didn’t accidentally run a non-BR template)

Quick interpretation

Because your input components already sum to the settlement amount, the run functions like an allocation “echo,” with Brazilian formatting and downstream default behavior applied.

This is especially useful as a first pass: it helps you confirm your agreement’s decomposition is internally coherent before moving into more complex cases (e.g., missing buckets, a settlement described only as “settlement consideration,” or component totals that don’t add up).

Sensitivity check

A sensitivity check helps you understand how robust your allocation is to input changes. Below are three controlled variations you can test in DocketMath without changing the tool’s jurisdiction setting (BR).

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Sensitivity 1: Component totals don’t match the lump sum

Suppose you mistakenly enter components totaling R$ 650,000 while the settlement is still R$ 600,000. For example:

• Principal/damages: R$ 445,000
• Monetary adjustment: R$ 120,000
• Interest: R$ 65,000
• Attorney fees: R$ 20,000
• Other costs: R$ 0
• Component subtotal: R$ 650,000

In this case, DocketMath should scale each bucket proportionally so the sum equals R$ 600,000.

• Scaling factor = 600,000 / 650,000 = 0.923076923

The scaled output would roughly be:

Use this test to catch data-entry errors. If the scaled results don’t match your expectations, it’s usually a sign the component inputs need correction.

Sensitivity 2: Zeroing a bucket (e.g., attorney fees)

Now set Attorney fees (sucumbenciais) = R$ 0.00 while keeping all other buckets unchanged, but still keep total settlement at R$ 600,000.

What happens depends on the tool’s proportional logic:

• If “Amounts provided” mode treats the listed amounts as the allocation basis, then removing attorney fees forces the tool to redistribute across the remaining components (so the sum still equals R$ 600,000).
• If the tool instead treats attorney fees as explicitly declared and doesn’t rescale, you might see remaining total flagged or reconciled.

In a typical proportional rescale:

• Original non-zero components sum = 420,000 + 120,000 + 45,000 = R$ 585,000
• The missing R$ 15,000 is redistributed across principal/adjustment/interest by their proportions.

Sensitivity 3: Swap the mix while holding total constant

Keep totals consistent with the lump sum (so no scaling is required), but change the mix to see how bucket shares respond.

Example alternative mix (still sums to R$ 600,000):

• Principal / damages: R$ 450,000
• Monetary adjustment: R$ 100,000
• Interest: R$ 30,000
• Attorney fees: R$ 20,000
• Other costs: R$ 0

Now the shares become:

• Principal: 75.00%
• Adjustment: 16.67%
• Interest: 5.00%
• Fees: 3.33%

This check is valuable for settlement narratives: if the settlement agreement attributes more to principal (or more to correction/interest), the allocation output should reflect that quickly—without needing to change any BR-specific settings.

Related reading

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