Why Settlement Allocator results differ in Brazil

The top 5 reasons results differ

Run this scenario in DocketMath using the Settlement Allocator calculator.

If you run DocketMath’s Settlement Allocator for Brazil (BR) and get outputs that don’t match what you expected, the cause is usually one of five jurisdiction-aware factors. These differences typically show up as shifted allocations across claim “buckets,” different ordering of payments, or a different treatment of interest/adjustment and other components.

1) Different “Brazil rules” toggles (jurisdiction-aware defaults)

DocketMath’s BR calculator applies Brazil-specific allocation logic based on selected case attributes. Even small changes to those selections can alter the allocation “waterfall.”

• Common symptom: totals match, but the split across components changes.
• What to check in the UI: any jurisdiction-aware options that were auto-selected and then manually changed.

2) Input structure doesn’t match the allocator’s expected components

Settlement Allocator depends on mapping your amounts into the right component categories. In Brazil, the tool is sensitive to distinctions such as:

• **Principal (base amount)

• Monetary correction / adjustment

• Interest (and whether it is treated as part of the allocation logic)

• Fees/cost-like amounts (if included)

• Common symptom: the allocator reallocates amounts because it interprets a number as “ancillary” rather than “principal.”

3) Payment date / timing fields change how components accrue

If the tool uses timing inputs—such as calculation ranges or effective dates—those can change the computed weight of interest/adjustment components even when your overall settlement total stays the same.

• Common symptom: the allocator’s component weights change, leading to a different allocation order.
• Typical cause: using filing date vs. settlement decision date (or mixing date conventions relative to your expectation).

4) Rounding and truncation rules applied at each allocation step

Some calculation pipelines apply rounding during intermediate allocation steps—not only at the end. If your expected results came from a spreadsheet that rounds only once at the final stage, small discrepancies can appear.

• Common symptom: a few cents to a few reais differences, or a small reallocation across buckets.
• Where it happens: after each prorating step, before final reconciliation.

5) Treatment of negative adjustments, caps, or “netting” logic

If you include discounts, offsets, reductions, or you net amounts yourself, the BR rules may apply additional netting behavior (or stop allocating once a cap is reached).

• Common symptom: one bucket is “drained” first, or allocations stop earlier than you expected.
• Typical cause: double-counting an offset (e.g., netting externally and letting the tool net again).

How to isolate the variable

Use a controlled “diagnostic loop.” The goal is to change one input or setting at a time until the output diverges in the same way you see in your results.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

A fast isolation checklist

Minimal-change experiment (recommended)

1. Keep all values the same.
2. Change only one date (for example, the calculation “as of” date).
3. Compare:

   • total allocation per bucket
   • component weights
   • any remaining/unallocated amounts

If the breakdown changes but totals do not, you’ve likely hit timing or rounding. If totals also change, start with categorization (principal vs. ancillary) and netting/caps.

Disclaimer: This diagnostic process helps explain calculation-model behavior in DocketMath. It isn’t legal advice and won’t confirm legal correctness for a specific case.

Next steps

1. Verify mapping: confirm each settlement line item is assigned to the allocator’s BR component categories.
2. Confirm dates: especially if your expectation was based on a different “as of” or accrual reference date than what you entered.
3. Align rounding workflows: compare your “round at end only” approach vs. any stepwise rounding the tool applies.
4. Avoid double-counting offsets: if you net amounts externally, try entering gross amounts and letting DocketMath handle offsets—then compare, one variable at a time.
5. Re-run using the single-variable changes above until you identify the driver.

For the fastest convergence, create a “clean-room” input set:

• principal entered as principal
• ancillary entered as ancillary
• dates set consistently across runs
• offsets applied only once

Related reading

• Browse the blog
• Use Settlement Allocator
• Settlement Allocator: troubleshooting guide
• How DocketMath handles jurisdiction-aware rules