Spreadsheet checks before running Damages Allocation in Brazil
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Running a “damages allocation” step in Brazil typically starts with a spreadsheet that represents: (1) the parties and their claims, (2) the damage categories, and (3) the allocation weights that decide how totals flow to individual line items. DocketMath’s spreadsheet checker helps you catch problems before you run the actual damages allocation calculator—so spreadsheet errors don’t quietly contaminate downstream outputs.
In Brazil (BR) workflows, the checker focuses on issues that commonly lead to “quiet mismatches”: results that look close at a glance, but are wrong because of identifier problems, sign conventions, weight normalization, or structural spreadsheet pitfalls.
Here are the most common spreadsheet problems the checker is designed to surface for Brazil-specific allocation use cases in DocketMath:
| Checker category | What it looks for | Why it matters for allocation |
|---|---|---|
| Totals consistency | Line items don’t sum to category totals, or category totals don’t sum to grand totals | Allocation outputs can look “reasonable” while violating your own arithmetic assumptions |
| Missing or duplicate keys | Blank claim IDs, party names that don’t match across tabs, duplicated identifiers | Allocation may route amounts to the wrong entity or drop amounts entirely |
| Negative values & sign errors | Credits recorded as negatives, costs recorded as positives, or mixed sign conventions | A sign flip can invert allocations—especially when weights distribute values |
| Weight validity | Weights missing, weights that don’t normalize (e.g., sum ≠ 1.00), or weights outside allowable bounds | The calculator can amplify errors when weights don’t reflect your intended allocation basis |
| Date alignment | Mismatched effective dates, inconsistent “as of” dates, or dates stored as text | Brazil models often rely on consistent “when” logic; date misalignment can misapply time-based rules |
| Currency and rounding | Mixed currency columns, inconsistent rounding precision (e.g., 2 vs 6 decimals) | Allocation can drift by cents into larger total discrepancies |
| Spreadsheet structural issues | Empty rows/columns, hidden formulas, merged cells that break references | Formula references can shift during edits, producing outputs that look plausible but are wrong |
| Rule coverage gaps | Categories used in the allocation sheet aren’t mapped to the rule set for BR | You may get partial allocations that silently omit damage categories |
Practical note: The biggest risk in spreadsheet-driven allocation is often not a crash—it’s a small integrity failure (keys, signs, weight normalization, dates, or rounding) that compounds across many rows.
Because DocketMath is jurisdiction-aware (BR), the checker also emphasizes patterns that tend to disrupt allocation logic where your sheet implies a time basis (dates) and where weights determine how totals distribute across parties and damage categories.
If your spreadsheet passes the checker, you should generally see a clean run through the damages allocation calculator with fewer “mystery differences” between input totals and computed allocation outputs.
When to run it
Treat the spreadsheet checker as a pre-flight step. In a Brazil damages allocation workflow, it provides the most value when run:
Run the checker before importing a spreadsheet into the Damages Allocation workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
1) After initial spreadsheet ingestion
Run it immediately after you:
- import or copy claim data into the working allocation workbook,
- create or refresh your damages categories and totals,
- add the party/claim mapping used by the allocation step.
This helps catch structural issues (missing IDs, broken references, date formatting) before any arithmetic is applied.
2) After any edits to weights or allocation rules
Whenever you change:
- weight columns (e.g., allocation percentages),
- normalization assumptions (sum-to-1 vs sum-to-100),
- category mapping (which damage types belong to which bucket).
Weight validity errors are especially high-impact because they affect how every downstream row is computed.
3) Before exporting results for review or filing workflows
Use the checker as a final verification pass right before you:
- export the allocation report,
- share results with stakeholders,
- generate an audit trail (for example, screenshots or exported CSVs).
This reduces the chance that late-stage formatting or rounding edits introduce discrepancies.
4) After copy/paste or tab reordering
Spreadsheet changes that commonly break references:
- copy/paste from a different workbook,
- inserting or deleting columns,
- moving tabs around,
- converting an Excel range to “values only.”
Run the checker after these operations—particularly if your formulas depend on consistent row order and cell references.
Try the checker
Start the workflow from the DocketMath damages allocation tool here: /tools/damages-allocation.
For a smoother run, use this practical checklist before you run the calculator:
If you want to understand the effect of bad inputs on outputs, here are two high-signal examples:
Example A: Weight normalization mismatch
- Input weights sum to 100 (instead of 1.00) while the allocation engine assumes sum-to-1
- Output allocations may look inflated or uneven across rows
- The checker flags the weight validity condition so you can correct the convention before running
Example B: Identifier mismatch across tabs
- Claim IDs in the allocation sheet differ from the IDs in the mapping sheet by even one character
- The calculator may omit matches or allocate to the wrong mapping row
- The checker highlights missing or duplicate keys so you can fix the “join” before results are computed
Warning: Don’t wait for the final allocation output to “look right.” A spreadsheet can produce numbers that pass a casual visual scan while still failing integrity constraints (totals, keys, signs, dates).