Spreadsheet checks before running Wrongful Death Damages in Brazil
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Wrongful Death Damages calculator.
Running wrongful death damages calculations in Brazil often fails less because of “math” and more because of data hygiene. DocketMath’s Wrongful Death Damages checker is built to validate the spreadsheet assumptions before you run the calculator—especially when your sheet combines medical, employment, dependents, and timeline inputs.
For Brazil (BR) runs, the checker focuses on issues that commonly change results by steering the model into the wrong branch of logic. Here are the most frequent spreadsheet problems it flags:
| Spreadsheet element | Typical error | What the checker does |
|---|---|---|
| Dates (DOB, death date, incident date) | Using a text date, leaving blanks, or mixing dd/mm/yyyy with mm/dd/yyyy | Validates date parsing and ordering rules (for example, ensuring death date is not earlier than birth date, where that relationship applies in your workflow) |
| Age-derived fields | Entering age directly when formulas expect DOB (or having both, but they conflict) | Detects conflicts between “age” and “date of birth” fields and prevents downstream miscalculation caused by mismatched sources |
| Income inputs | Entering net pay where gross earnings are expected, or mixing pay frequency (monthly vs annual) | Checks unit consistency (monthly vs yearly) and warns on irreconcilable combinations; it also helps you avoid double-counting by catching inconsistent frequency indicators |
| Dependents | Empty rows, duplicated dependent entries, or missing dependent start/end details | Ensures each dependent row has the minimum required fields and that dependent totals aren’t inflated by duplicates |
| Claims scope fields | Omitting “type of claimant” or mixing categories in a way the spreadsheet doesn’t support | Verifies required columns/fields for claimant-category logic used in BR workflows, so the calculator doesn’t assume the wrong claimant scope |
| Scenario toggles | Switching between “with survivor income” and “without survivor income” but leaving related cells populated | Highlights inconsistent scenario flags vs populated data blocks, reducing the chance you’re blending two scenarios unintentionally |
| Currency and scaling | Entering “R$” amounts with incorrect scaling (e.g., cents vs full currency units) | Flags unusually small/large magnitudes using sanity thresholds so you can correct entry scale before results propagate |
| Output alignment | Copy/pasting so summary totals don’t match component line items | Checks reconciliation between totals and line items within an acceptable tolerance to catch range misalignment |
Gentle warning: A spreadsheet can look “fully calculated” while still being wrong because it’s quietly using the wrong unit, the wrong date format, or the wrong scenario branch. The checker exists to stop those problems early, when they’re easier to fix.
A practical mental model: the checker targets inputs that drive branching logic—dates, dependency structure, income frequency/units, and claimant categorization—because those determine which Brazil-specific pathways the calculator applies.
When to run it
Treat the checker as a pre-flight step. You’ll get the best outcomes when you run it:
- Right after you assemble or edit the spreadsheet, not just at the end.
- After importing or copy/pasting data, especially when data comes from PDFs or payroll exports (date formats and blank fields are common culprits).
- After changing any scenario options, such as toggles related to survivor income or claimant/dependent structures.
- Before you lock in “final” figures for review, sharing, or export.
- After any manual edits to income lines, dependent rows, or date fields.
A practical workflow that reduces rework:
- ✅ Confirm core identifiers (DOB, death date, and claimant type/category used in your BR sheet)
- ✅ Populate dependents (ideally one row per dependent, with start/end where applicable)
- ✅ Enter earnings (and confirm the pay frequency/unit is consistent)
- ✅ Run DocketMath spreadsheet checks
- ✅ Fix any flagged issues at the source
- ✅ Only then run the Wrongful Death Damages calculator
Common pitfall: Editing only final totals often hides the cause. If the checker reports a date-ordering problem, the fix belongs in the date fields—not in computed age or timeline cells.
Try the checker
You can test the end-to-end experience inside DocketMath. Start from the primary tool entry point below, then use the checker to validate your spreadsheet structure before running the calculator:
- Open: /tools/wrongful-death-damages
As you test, focus on how the checker influences correctness and confidence—not just whether it runs.
Inputs to prepare
Use your spreadsheet to supply (at minimum) these Brazil-ready categories:
- Key dates
- DOB and death date (and any incident date fields your sheet uses)
- Claimant structure
- Claimant type/category used by your BR workflow
- Dependents list (each dependent row must be complete)
- Income
- Earnings amount(s)
- Income frequency/unit (for example, monthly vs annual—consistent across rows)
- Scenario flags
- Any toggles your sheet uses to include/exclude income assumptions
Output behavior to watch
When the checker is working properly, you’ll typically see:
- Cells/sections marked or flagged when:
- date ordering is impossible
- dependent rows are incomplete or duplicated
- income units/frequency conflict
- scenario toggles don’t match the data blocks you filled
- Recalculation blocks or warnings when:
- the sheet can’t safely infer time windows or units from the entries you provided
Minimal “green path” checklist
Before running the calculator, aim for:
If you want an extra sanity check, compare one computed figure to a rough baseline (for example, whether annualized income looks consistent with monthly input × 12). The checker helps with structure; this baseline helps catch magnitude mistakes.