How to interpret Settlement Allocator results in Brazil

What each output means

Run this scenario in DocketMath using the Settlement Allocator calculator.

When you run the DocketMath Settlement Allocator for Brazil (BR), the calculator produces an allocation intended to translate a settlement amount into (1) component-style buckets and (2) payee-facing net totals using jurisdiction-aware rules. The exact label names can vary slightly based on how you configure the run in the UI, but in practice you’ll typically see three groups of outputs.

1. **Allocation by component (economic buckets)

• These buckets split the settlement into portions that represent different “economic shapes” commonly used in settlement structures (e.g., portions attributable to economic value versus amounts tied to other settlement terms).
• Use this section to understand why the total is split the way it is—i.e., which components DocketMath believes the settlement is “modeled” to represent—rather than treating labels as authoritative characterization.

1. **Net-to-payee amounts (what each party effectively receives)

• DocketMath converts the component allocation plus payee logic into approximate net amounts for each payee line item.
• Treat these as estimates for planning and communication based on the assumptions you provide. They are not a substitute for legal or tax analysis of the actual settlement agreement.

1. Rounding and reconciliation figures

• You’ll often see one or more reconciliation lines (for example, “allocated total” vs. “settlement total”) showing how the model’s bucket sums reconcile with your input amount.
• Small differences are commonly due to currency rounding (e.g., rounding to whole reais) and how the UI displays precision.

A practical order for interpreting results:

1. Confirm the settlement total you entered matches the “settlement total” shown in the results.
2. Review allocation by component to understand the internal split and identify which buckets are driving the model output.
3. Review net-to-payee amounts to see how the split flows into what each payee is modeled to receive.

If you’re reconciling against a real settlement document, match buckets to the agreement’s concepts approximately (substance over labels). Use the DocketMath outputs as a consistent way to test and communicate the implications of your modeling assumptions.

What changes the result most

In Brazil runs, the biggest swing usually comes from a small set of inputs. If you want to stress-test your outputs, adjust inputs in descending order of impact and compare the results.

These inputs have the biggest impact on the final number. Adjust them one at a time if you need a sensitivity check.

• date range
• rate changes
• assumption changes

1) Who the payees are (and how many)

Adding/removing payees (or changing their share logic) can change:

• Each payee’s modeled share of the allocation
• Any jurisdiction-aware distribution logic DocketMath applies
• Rounding and reconciliation outcomes

Practical check: ensure each payee line item (party type and share logic) matches how the settlement is actually drafted.

2) Settlement amount and the payment structure

Even if the headline settlement number is the same, different payment-structure inputs can produce notably different allocations, because the model may distribute the total across components differently. Common drivers include:

• Whether the settlement is modeled as a single lump sum or split into multiple portions
• How you represent effective dates or timing inputs (where applicable in the tool)

Quick validation: run two scenarios:

• Your baseline structure, then
• A simplified single-amount setup
  If the component split flips dramatically, the payment-structure inputs are likely dominating the result.

3) Allocation weights / splits you provide

Where DocketMath uses your percentages, shares, or mapping rules, those inputs will dominate the outputs. If you see a counterintuitive component allocation:

• Find the specific input that maps the settlement amount to that component bucket.
• Change in small increments (e.g., 5–10%) and observe which component totals respond most.

4) Currency rounding and display precision

Even when the underlying allocation logic is consistent, you can see small differences due to:

• Rounding to whole reais (or the UI’s rounding method)
• Display precision (some outputs show cents or truncate values)

Reconciliation tip: if “allocated total” and “settlement total” don’t match perfectly, it’s often rounding. Look for whether the results include an explicit reconciliation line.

5) Consistency between run inputs and your settlement narrative

DocketMath outputs reflect the assumptions you provide. If your inputs imply one economic story but the settlement draft reads differently, the results may diverge.

Reminder: Brazil settlement outcomes depend heavily on how the agreement is written (wording, categorization, and documentation). DocketMath helps you interpret modeled outputs consistently with your inputs, but it doesn’t replace reviewing the settlement document.

A fast interpretation workflow:

• Run with your best estimate.
• Re-run after changing only one input category (payees, component splits/weights, or payment structure).
• Compare output deltas and identify which category produces the largest movement.

Next steps

Once you interpret the results, turn them into a practical checklist you can use while reviewing the settlement draft or preparing internal numbers.

1. Reconcile totals

• Verify the results “settlement total” equals the amount you entered.
• Confirm component totals add up to the reconciliation figure, allowing for rounding.

1. Map each component to agreement language

• Create a one-to-one “concept mapping”:

  • DocketMath component bucket → the closest settlement draft descriptor
• If a bucket has no clear analog in the draft, treat that as a modeling gap to resolve (or at least document internally).

1. Validate payee-facing amounts

• Check that each payee’s net amount aligns with your expected distribution logic.
• If you add/remove payees or change their shares, re-run and verify that reconciliation lines still behave as expected.

1. **Stress-test assumptions (one change at a time)

• Change only one major input category per run (payee split, component weights, or structure).
• Record which outputs move most. This identifies where model uncertainty is concentrated.

1. Use DocketMath as a communication tool

• Present component and net-to-payee totals as allocation estimates based on provided assumptions.
• Keep your communication aligned with the settlement narrative you’re using, and avoid presenting calculator output as a definitive legal conclusion.

If you want to run (or re-run) the analysis, start here: /tools/settlement-allocator. You can also sanity-check your broader workflow by reviewing the run settings in the same tool and then comparing outputs using your internal reconciliation process.

Quick reference checklist

Related reading

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