Why Damages Allocation results differ in Indiana

The top 5 reasons results differ

Run this scenario in DocketMath using the Damages Allocation calculator.

When you run DocketMath’s damages-allocation calculator for Indiana (US-IN), you may see outputs that don’t match another workflow’s results. In practice, most differences come down to one of these five variables—each can change which portions of damages fall inside the calculation window or how they’re split across categories.

1) The Indiana time window (statute of limitations) is a first-order input

For Indiana, the general/default statute of limitations period used in many workflows is 5 years, based on Indiana Code § 35-41-4-2.

Your provided jurisdiction data did not identify a claim-type-specific sub-rule, so the default 5-year period is the common baseline—rather than a specialized period that varies by claim type.

How it changes outputs: If one workflow effectively looks back exactly 5 years from the same start point, while another uses a different effective start date (or a different default window), the included damages months/periods can shift, which changes the allocation totals.

2) “Accrual/start date” assumptions change what falls inside the 5-year window

Even with the same 5-year limitation period, the output depends heavily on how the workflow defines the start of the window. Common approaches include:

• date of injury/occurrence,
• date of discovery (if used),
• date of demand/notice (if used).

How it changes outputs: DocketMath can only allocate from the dates you provide. If another workflow uses a different accrual/date rule, different damage periods land inside vs. outside the 5-year span—shifting totals and category allocations.

3) Allocation method differences (pro-rata vs. categorical buckets)

Tools often allocate using different mechanics, such as:

• Pro-rata allocation based on time overlap with the limitation window,
• Categorical/bucketed allocation (e.g., wages vs. medical vs. other),
• Weighted allocation driven by specified shares.

How it changes outputs: Even if both workflows use the same date window, differing category structures, weighting, or pro-rata logic can cause category-level totals to diverge.

4) Rounding, month-to-day conversions, and boundary inclusions

Small implementation details can create noticeable deltas, for example:

• inclusive vs. exclusive handling of boundary days,
• rounding partial months to whole months,
• day-level math vs. month-level math.

How it changes outputs: Two workflows can both be “right” under their own conventions, yet produce different totals due solely to conversion/rounding rules around boundary dates.

5) Input mismatches: payments, offsets, and compensation streams

Allocation results can change when one run includes or excludes items such as:

• partial payments,
• settlement credits modeled as inputs,
• offsets,
• other compensation streams that are treated as reducing (or not reducing) allocated damages.

How it changes outputs: A single missing or duplicated input (like “prior payments/offsets”) can move totals and reshape the split across categories.

How to isolate the variable

Use DocketMath to “freeze” everything except one assumption at a time. The goal is to find the specific setting that produces the largest swing.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step-by-step checklist

Because no claim-type-specific sub-rule was identified in the provided data, treat this as the default unless you have a specific reason to use otherwise.

• Run once with the exact start date used in the other output.
• Then run again changing only the start date by about ±30 days and compare.
• If DocketMath offers a selection for pro-rata vs. bucketed/weighted, match the other workflow.
• If the other output looks month-based, confirm DocketMath is using the same month/day conversion assumptions.
• Ensure wage/medical/other (and any weights) match exactly.
• If the other workflow includes prior payments/offsets, mirror that input. If you suspect mismatch, remove/disable it and re-run to see the effect.

A simple “delta” test

1. Run A with baseline inputs.
2. Run B change only one variable (e.g., accrual/start date).
3. Compare:

   • Total allocation change: B_total - A_total
   • Category allocation change: B_category - A_category

If changing the accrual/start date causes the biggest swing, the time-window driver is likely. If category totals shift most, the allocation method/weighting or category inputs are likely.

Next steps

Once you identify the driver, document the run assumptions so you can reconcile across parties or workflows:

• Create a short run log including:

  • Indiana default limitation period reference (5 years, Ind. Code § 35-41-4-2),
  • the exact accrual/start date used,
  • the allocation method (pro-rata vs. buckets/weights),
  • the date conversion/rounding convention (day-level vs month-level),
  • category totals and any offsets/prior payments inputs.

Then rerun DocketMath using the reconciled inputs. In most Indiana damages-allocation discrepancies, alignment on the date window/accrual assumption resolves the majority of differences.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules