How to run Settlement Allocator in DocketMath for Brazil
6 min read
Published April 15, 2026 • By DocketMath Team
Step-by-step
Run this scenario in DocketMath using the Settlement Allocator calculator.
This guide walks you through running Settlement Allocator in DocketMath for Brazil (BR). The workflow is designed to be jurisdiction-aware, so the allocator applies Brazil-specific handling for common settlement allocation inputs.
Note: This article explains how to use DocketMath’s allocator and what to expect from its outputs. It’s not legal advice and can’t replace review by qualified counsel for a specific dispute.
1) Open the Settlement Allocator tool
- Go to the primary CTA: /tools/settlement-allocator
- Select Brazil (BR) if the interface asks for jurisdiction.
- Confirm the calculator mode is set to Settlement Allocator.
If you don’t see a jurisdiction selector, you can still confirm the jurisdiction is BR by checking the tool header or settings panel in the allocator UI.
2) Gather the settlement components you want to allocate
DocketMath needs a clear breakdown of what the overall settlement amount covers. In practice, that usually includes items like:
- Principal / base claim (e.g., the core amount claimed)
- Interest (if applicable)
- Monetary correction (often treated distinctly in Brazil settlements)
- Fees (including attorney fees if contractually or procedurally included)
- Costs / expenses
- Other agreed items (e.g., tax-related adjustments if you track them separately)
Create a simple checklist before entering values:
3) Enter the settlement total and validate currency/rounding
In Brazil workflows, the allocator typically benefits from consistent currency formatting. Use the tool’s numeric inputs as follows:
- Enter the total settlement figure you are distributing.
- Enter each component amount you want reflected in allocations.
- If the UI offers rounding controls, choose a consistent method (e.g., round to 2 decimals).
Sanity-check:
- Sum of components ≈ total settlement
- If the tool allows “difference handling,” enable it and let DocketMath allocate any remainder using its configured rule.
- If it doesn’t, adjust the component numbers so they add up exactly.
4) Add Brazil-specific allocation rules (jurisdiction-aware settings)
Depending on the DocketMath UI version, you may see a “jurisdiction rules” panel. For BR, use it to align allocations with how your case documents treat each component.
Common settings you may encounter:
- Allocation basis per line item (e.g., principal-weighted vs. equal-weighted)
- Whether interest/correction is included in certain shares
- Treatment of fees and costs (separate buckets vs. rolled into overall allocation)
If there’s a selector for “allocation strategy,” pick one that matches your agreement structure:
- Document-driven allocation: aligns to line items you supply
- Weights-based allocation: aligns to ratios you set (for example, % of principal)
Warning: If you mix strategies—like using weights for some components but also entering explicit component totals—outputs can look internally consistent while still diverging from your agreement. Pick one strategy per settlement run and stick with it.
5) Define the recipients (payees) and shares
For multi-party settlements, you typically need:
- Recipient names/entities
- Recipient type (if the tool asks—e.g., claimant, counterparty, fee recipient)
- Allocation shares or allocation mapping rules
You may have options such as:
- Fixed percentages per recipient
- Proportional shares based on a component (for example, “principal”)
- Manual overrides per recipient for each bucket
Practical approach:
- Enter each recipient.
- For each recipient, supply either:
6) Run the allocation and review the output buckets
After input completion, run the calculation. DocketMath returns an allocation report that usually includes:
- Allocated amount per recipient
- Allocated amount per component bucket (principal, interest, correction, fees, costs, other)
- Totals check (does allocation equal your settlement total?)
- Optional breakdowns or export-ready tables
Use the totals check as your first diagnostic:
- If totals match: proceed to recipient verification.
- If totals don’t match: revisit rounding, component sums, and any “difference handling” option.
7) Confirm consistency across scenarios (before you finalize)
If you expect future revisions (e.g., updated interest or a different fee arrangement), run quick scenarios:
- Scenario A: components sum exactly to total
- Scenario B: slightly different fee amount with remainder distributed automatically
Compare outputs:
- Which recipients change?
- Which buckets swing the most?
- Does DocketMath keep totals aligned?
This is where you avoid “quiet drift” from changing one line item while leaving allocation shares unchanged.
8) Export or copy results for case use
When you’re satisfied:
- Export the output (CSV/PDF if available) or copy the allocation table.
- Keep the tool run parameters (jurisdiction BR, strategy, rounding) so the same run can be replicated later.
Tip: If DocketMath provides a “run summary” or parameter view, capture it alongside exports so you can explain how the output was generated.
Common pitfalls
Below are the most frequent issues when running Settlement Allocator for Brazil in DocketMath. Use this checklist to catch problems early.
Even small differences (e.g., a rounding mismatch of 0.01–0.50) can cause the allocator to redistribute remainder in a way that doesn’t match your expectations.
If the tool’s configuration treats fees as a separate bucket, fee recipients may not mirror principal proportions.
Many Brazilian settlement documents track correction and interest differently. If you enter them together, the output bucketization may be less aligned with the documentation you’ll rely on later.
A run with 2-decimal rounding can differ from a run with 0-decimal rounding (especially after remainder allocation).
If a recipient participates only in certain components, make sure the tool’s UI reflects that. Otherwise, recipients can receive amounts in buckets they shouldn’t.
Pitfall: A totals mismatch that still “looks plausible” is usually caused by either (1) component sum not equaling the total or (2) remainder allocation being enabled without you realizing which bucket absorbs the difference. Always check the allocation totals and bucket subtotals.
Try it
If you want a fast start, open DocketMath’s Settlement Allocator and run a minimal BR example:
- Go to /tools/settlement-allocator
- Set jurisdiction to **Brazil (BR)
- Enter:
- Total settlement (example: 100,000.00)
- At least two components (example: principal + fees)
- Add at least two recipients
- Run the allocation
- Verify:
- Total allocated equals total settlement
- Each recipient receives amounts consistent with your intended buckets
Then iterate with one change at a time (for example, adjust fees from 10,000.00 to 12,000.00) and observe how DocketMath shifts allocations.
