Spreadsheet checks before running Settlement Allocator in Brazil

What the checker catches

Before you run DocketMath’s Settlement Allocator for a Brazil (BR) matter, use a spreadsheet-focused preflight checklist to prevent allocation errors that are hard to unwind later. The goal is simple: catch data problems that would cause the allocator to produce the wrong winners, the wrong amounts, or both.

A jurisdiction-aware checker for BR (Brazil) typically validates that your spreadsheet inputs align with how the allocator will compute distributions. Common issues it catches include:

• Missing or mismatched identifiers

  • Blank claimant/payee IDs (rows that should receive allocation but can’t be uniquely identified)
  • Duplicate IDs across different rows
  • Payee names that don’t match your allocator mapping table (or don’t map to the same party consistently)

• Amount fields that won’t compute cleanly

  • Non-numeric values in monetary columns (e.g., “R$ 1.200,00” stored as text rather than a number)
  • Negative values in columns that are intended to represent gross claims or receivables
  • Mixed precision (e.g., cents provided on some lines but not others)

• Totals that don’t reconcile

  • “Line items sum” not matching “case totals”
  • Allocator subtotal not matching the settlement amount you intend to distribute
  • Rounding drift that exceeds your selected tolerance (for example, if you expect totals correct to 2 decimal places)

• Allocation drivers that conflict

  • Percentages provided alongside fixed amounts without a consistent basis
  • Both “weight” and “cap” columns present, but only one is expected by the allocator configuration
  • Eligibility flags that exclude parties unintentionally (for example, “eligible” marked as “no” for everyone)

• **Jurisdiction-aware rule mismatches (Brazil-specific checks)

  • Currency assumptions: making sure the spreadsheet is consistent with BRL and that any required conversions (if applicable) are already completed
  • Brazilian numeric conventions: ensuring decimal separator and thousands separator usage matches how the allocator reads numbers, so values like 1.234,56 aren’t misread as 1.234.56
  • Distribution basis alignment: ensuring your sheet’s implied basis matches the allocator’s expected inputs (e.g., allocating on net-of-fees amounts when the allocator is configured to allocate on gross figures)

Use the checker to confirm that:

• Every row that should participate can be identified unambiguously
• Every monetary input is parseable as a number
• Every total ties back to your intended settlement distribution base
• Your allocator configuration matches the columns you provide

Quick mental model

Think of the checker as validating four layers before computation:

1. Identity layer (who gets allocated)
2. Math layer (how amounts are interpreted)
3. Reconciliation layer (whether totals match)
4. Configuration layer (whether the allocator’s expected inputs match your sheet)

When to run it

Run the spreadsheet checker before each allocation run, and also after any spreadsheet change that could affect calculations. A practical rule set:

• Before the first run

  • When you import or paste the spreadsheet for a new Brazil matter
  • When you switch to a new claimant/payee roster

• After any edit that changes numbers

  • Updating claim amounts
  • Changing percentage splits
  • Modifying fee lines or deductions (even if you believe the allocator configuration already “handles it”)

• After any edit that changes formatting

  • Copy/pasting from PDFs
  • Changing column formats in Excel/Google Sheets
  • Converting between locales (for example, changing decimal/thousands separators)

• Before re-running after corrections

  • If you fix one row, re-run the checker to ensure the fixes didn’t introduce new reconciliation drift

If you want a low-friction workflow:

1. Run checker
2. Review the issues list
3. Fix the sheet
4. Run checker again
5. Only then run the Settlement Allocator

Try the checker

To see the preflight flow using DocketMath:

1. Open the tool here: **Settlement Allocator
2. Prepare your spreadsheet with columns that match what the allocator expects, such as:

   • party identifiers (IDs)
   • participant eligibility
   • amount/percentage inputs
   • your intended settlement total / allocation base
3. Run the spreadsheet checker first to surface issues in a list you can act on.
4. Fix flagged rows and re-check until you have:

   • numeric fields that parse correctly
   • totals that reconcile within a reasonable tolerance
   • no duplicates or blanks in key identifiers

If you want to sanity-check inputs even before the checker flags everything, try these “fast checks”:

• Numeric parse test

  • Pick 3 rows and confirm the allocator will treat monetary entries as numbers (not text).
• Reconciliation test

  • Confirm: sum(line amounts) = settlement base (within cents).
• Eligibility test

  • Confirm: only intended parties are marked eligible.

When the checker passes, the Settlement Allocator’s outputs should change predictably:

• Changing a single claim amount should affect only that party’s allocation (and relevant totals/rationales, if your model uses weights or proportional shares).
• Fixing a formatting issue (such as decimal separators) should correct multiple allocations at once—sometimes by a large factor—because parsing changes how values are interpreted.
• Resolving duplicate IDs should consolidate allocation into the canonical entry instead of splitting/duplicating outcomes.

You can iterate quickly starting from the allocator page and looping “checker → fix → checker → allocate” until the report is clean.

• Primary CTA: Run Settlement Allocator

Related reading

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