Spreadsheet checks before running Damages Allocation in Indiana

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Before you run a Damages Allocation in Indiana with DocketMath, do a quick spreadsheet validation pass. The purpose isn’t to decide liability—it’s to prevent allocation outputs from being based on preventable spreadsheet issues (wrong time window, missing rows, inconsistent totals, or misapplied time periods).

This checker is built around Indiana’s general statute of limitations (SOL) framework:

• General SOL Period: 5 years
• General Statute: Indiana Code § 35-41-4-2
  (This is the general/default period for this workflow; no claim-type-specific sub-rule was found for this checker.)

Spreadsheet failure modes the checker flags

Use this checklist style to catch common problems before damages allocation:

• Example: Your spreadsheet assumes a 6-year window, but the general period is 5 years.
• Example: Some rows use MM/DD/YYYY while others use YYYY-MM-DD, causing silent sorting errors.
• Example: Accidentally duplicated a damages category row, inflating totals.
• Example: Category subtotals add up correctly, but the “grand total” differs due to a stale cell range.
• Example: Two rows both cover “January 1–March 31,” resulting in double-counted amounts.
• Example: An end date precedes a start date, producing a negative allocation multiplier (or a zero multiplier that hides a data issue).
• Example: Dollar signs or commas stored as strings, which break multiplication and allocation logic.
• Example: One column is monthly amounts while another is annual amounts, but the checker treats them as the same unit.

Indiana-specific impact: SOL window alignment

Because Indiana’s general default SOL is 5 years, the checker is designed to help your spreadsheet’s “allocation horizon” align with that general period referenced in Indiana Code § 35-41-4-2.

In practice, that usually means:

• If your spreadsheet allocates damages across multiple years, the checker helps ensure you’re not silently including amounts outside the intended 5-year window.
• If your spreadsheet already filters to a smaller window, the checker confirms the dates and bucket boundaries match the filtering logic—so the allocation doesn’t re-introduce out-of-window amounts through overlapping ranges or mis-parsed dates.

Quick grounding in the statute (general/default)

Indiana Code § 35-41-4-2 is the general/default SOL framework used here. Since no claim-type-specific sub-rule was identified for this checker, treat 5 years as the default window unless your specific case analysis indicates a different rule.

Source: https://law.justia.com/codes/indiana/2022/title-35/article-41/chapter-4/section-35-41-4-2/?utm_source=openai

When to run it

Run DocketMath’s spreadsheet checker at the moment it catches the most risk: right before you launch the Damages Allocation calculation (via /tools/damages-allocation).

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.

Best timing in a typical workflow

1. After you finalize the spreadsheet structure

   • Columns exist, date fields are filled, category rows are complete.
2. Before you lock formulas and run allocation

   • This prevents recalculating outputs after discovering a date parsing issue or a totals mismatch.
3. After any bulk edits or imports

   • Copy/paste operations and external imports are common causes of:

     • “amounts as text”
     • inconsistent date formats
     • duplicate rows
     • drifting totals

What changes between runs

Use the checker to ensure these elements are stable before output:

• Time horizon (5 years, general default): aligned to the general rule under Indiana Code § 35-41-4-2
• Bucket boundaries: start/end dates and non-overlap behavior
• Row integrity: no missing categories and no duplicates
• Arithmetic integrity: totals reconcile; amounts are numeric and consistent

Try the checker

You can run the spreadsheet validation process directly in DocketMath through the Damages Allocation workflow.

• Primary CTA: /tools/damages-allocation

If you’re building or auditing a spreadsheet, here’s how to think about inputs and how your outputs should change once the checker finds (and you correct) issues.

Inputs to prepare (spreadsheet-side)

Make sure each row or time bucket has:

• Start date and end date for each damages row/bucket
• Amount per row (numeric, not text)
• Category/grouping fields so totals roll up correctly
• A case timing anchor your spreadsheet uses to decide what’s inside the allocation window (commonly the relevant pleading/incident date you’re modeling)

Output behavior to validate (allocation-side)

After you run the checker and then execute allocation, validate that:

• Amounts aggregate by category without unexplained drift.
• Allocation multipliers reflect:

  • correct duration math (days/months)
  • no overlap between buckets (so the same time period isn’t double-counted)
• The overall allocated totals are consistent with:

  • the spreadsheet’s 5-year default window under Indiana Code § 35-41-4-2
  • the date boundaries you actually entered

If you want additional cross-checking for your broader workbook calculations, you can also explore DocketMath utilities such as:

• /tools/docket-math
• /tools/spreadsheet-checker

Then come back to /tools/damages-allocation for the allocation step.

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