Common Wrongful Death Damages mistakes in Brazil

The top mistakes

Run this scenario in DocketMath using the Wrongful Death Damages calculator.

When people use DocketMath to estimate wrongful death damages in Brazil (BR), most errors come from mismatched assumptions—especially around who can claim, what component you’re calculating, and which evidence supports each component. Below are the most common mistakes we see when working through the wrongful-death-damages calculator.

Gentle note: this is general guidance for using a calculator and interpreting results. It’s not legal advice, and it can’t account for every case-specific fact.

1) Mixing “direct compensation” with inheritance-like framing

A frequent misunderstanding is treating a wrongful death claim like an inheritance substitution. In BR, the damages analysis is typically focused on civil reparation concepts (such as material losses and, where applicable, moral damages), rather than distributing shares in the way probate might distribute an estate.

DocketMath impact: If you encode beneficiary expectations as if they were inheritance percentages, you can distort the material-loss portion—leading to a confidently presented but conceptually incorrect result.

2) Forgetting to separate material damages vs. moral damages

Wrongful death compensation often involves multiple heads of damages, typically:

• Material damages (economic loss)
• Moral damages (non-economic harm, such as emotional suffering)

A practical error is running only one category (e.g., material loss) or averaging them together inside a single estimate rather than keeping them conceptually separated.

DocketMath is designed for structured inputs. If you “bundle” categories into one number, you reduce internal consistency and make the output harder to interpret.

3) Using the wrong time horizon for economic loss

Another common error is choosing a period that doesn’t match the economic-loss logic used by the model. For example:

• estimating only 12 months of lost support when the calculation implicitly assumes a longer support period
• projecting losses to an “end age” without aligning to the calculator’s intended method

DocketMath impact: Output often increases as the covered period lengthens (and as any growth/adjustment assumptions apply). A mismatched horizon can therefore produce a result that doesn’t reflect what the input set is actually modeling.

4) Overstating or understating income without normalizing

Income inputs are where estimates tend to drift. Typical mistakes include:

• using a figure that’s not in the calculator’s expected form (e.g., gross vs. net/spendable, depending on how the tool is set up)
• failing to normalize irregular income (bonuses, commissions, variable earnings) into a stable annual baseline
• mixing inconsistent periods (e.g., using a monthly number derived from a partial year, or inconsistent month counts)

DocketMath impact: Because economic loss typically scales with income assumptions, even “small” normalization errors can compound over the full calculation horizon.

5) Incorrect beneficiary counts or roles

In BR, the relationship to the deceased and the type of harm matter. Practical mistakes include:

• modeling the wrong number of beneficiaries
• treating non-dependent relatives the same as financial dependents
• attributing support-related loss to beneficiaries who, based on available facts, weren’t realistically part of the victim’s support dynamics

DocketMath impact: Beneficiary-related parameters can directly affect allocation logic. Your output may look precise, but it can be anchored to the wrong population.

6) Treating future adjustments inconsistently (inflation/earnings growth)

Some calculators use adjustment assumptions (inflation and/or growth). A common error is entering income inconsistently with those assumptions, such as:

• providing nominal income while also applying an inflation adjustment (or vice versa)
• applying growth twice—once implicitly via a higher baseline and again via a growth parameter

DocketMath impact: Inconsistent adjustment logic can create unrealistic escalation in projected loss.

7) Relying on a single “lost support” number without a reasonableness check

Instead of grounding lost support by thinking through how it’s supported (spending patterns, contribution levels, household economics), some people input a single number (e.g., “$X per month”) without checking whether it represents what the calculator is expecting (such as a share of net income available for dependents).

DocketMath impact: Even if the number is “close,” the mismatch between your concept and the tool’s concept can cause a gap between computed damages and evidence-backed damages.

How to avoid them

Use DocketMath as a structured workflow: confirm what each input represents, choose consistent time horizons, and keep damage components separated. Use this checklist before you finalize outputs.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Decide which heads of damages you’re estimating

Before starting, separate your planning into two tracks:

If you need a combined view later, generate them separately in DocketMath and consolidate after—this preserves transparency and reduces input confusion.

Step 2: Align income inputs to what the calculator expects

A reliable approach:

• Use the most defensible annual income base from available records (e.g., pay records, tax-like documentation where applicable)
• Normalize irregular income into an annual average
• Ensure the figure matches the calculator’s concept (gross vs. net/spendable—whatever the tool expects)

DocketMath tip: If results appear “too high” relative to the household’s known spending/income reality, re-check income normalization first. In many models, income acts as a major multiplier.

Step 3: Lock the time horizon to the calculator’s logic

Pick an end date/period that matches the method the calculator is applying—not just what seems intuitive. Then:

• keep the same start/end logic across scenario comparisons
• compare outcomes only by changing one assumption at a time (when feasible) to learn sensitivity

Step 4: Verify beneficiary configuration

Before running, build a beneficiary table that mirrors your intended model:

Even if you’re estimating, this structure helps prevent accidental over-inclusion.

Step 5: Handle future adjustments once (and only once)

When using inflation/growth assumptions:

Step 6: Cross-check outputs using a reasonableness lens

Quick sanity checks:

• If the projection implies economic loss far exceeding the victim’s known capacity to generate support, it may indicate a beneficiary/share or horizon mismatch.
• If your output barely changes when you modify the income inputs, verify that you’re updating the fields connected to the head of damages you think you’re modeling.

Practical workflow: run 2–3 constrained scenarios and observe whether results behave as expected.

Step 7: Track assumptions so your results are reproducible

DocketMath works best when your runs can be explained. Keep a short assumptions list:

• income base (annual average; what it includes/excludes)
• calculation period start/end
• adjustment assumptions (inflation/growth), if any
• beneficiary count and dependency/support basis
• moral damages approach (if included)

That’s often the difference between a number you can defend and one you can’t explain.

For direct access to the calculation workflow, start with DocketMath’s wrongful death damages tool: /tools/wrongful-death-damages.

Related reading

• Wrongful Death Damages Estimator Guide for Alabama
• Wrongful Death Damages Estimator Guide for Arizona
• Wrongful Death Damages Estimator Guide for Colorado