Worked example: Damages Allocation in Indiana

6 min read

Published April 15, 2026 • By DocketMath Team

Example inputs

Below is a worked example showing how DocketMath allocates damages using Indiana’s default statute of limitations (SOL) framework for claims in US-IN.

This example uses Indiana’s general/default limitations period because no claim-type-specific sub-rule was found in the provided jurisdiction data. In other words, we apply Indiana’s default SOL rather than switching to a special clock for a specific cause of action.

Scenario (invented numbers for demonstration)

Assume a plaintiff claims that a contract dispute and related harms occurred over multiple dates, and damages need to be allocated across time.

Time anchors used in this example:

  • Incident start date: 2020-03-01
  • Last incident date: 2021-10-15
  • Filing date: 2024-06-10
  • Total claimed damages: $120,000
  • Damages distribution by event date (how much arose each year):
    • 2020: $35,000
    • 2021: $50,000
    • 2022: $25,000
    • 2023: $10,000

Indiana SOL rule used (default)

Indiana’s general SOL period is 5 years under:

Note: Because the jurisdiction data did not identify any claim-type-specific SOL sub-rule, this example applies the general 5-year default rather than a specialized limitations period. (This is not legal advice; it’s a demonstration of how to run the allocation logic with the information provided.)

DocketMath calculator: damages-allocation inputs

You can map the scenario to DocketMath’s damages-allocation tool by providing:

  • Jurisdiction: US-IN
  • Filing date: 2024-06-10
  • Damages by year (or by event window):
    • 2020: 35,000
    • 2021: 50,000
    • 2022: 25,000
    • 2023: 10,000
  • SOL period (driven by jurisdiction rules): 5 years (default)
  • Allocation method: keep only the portions that fall within the SOL “lookback” window

To give the tool a clean time window, DocketMath effectively needs a rule like:

  • Lookback window starts: Filing date minus 5 years
  • Include damages arising during that window
  • Exclude damages arising before the window start

For this example:

  • Filing date = 2024-06-10
  • Lookback start (5 years prior) ≈ 2019-06-10

Because the damages begin in 2020, all provided damages fall after the lookback start. That means this particular fact pattern may not show any exclusions—however, the input structure is the same even when exclusions occur.

Primary CTA: **Use DocketMath: Damages Allocation

Example run

Here’s a step-by-step allocation result using the Indiana default 5-year SOL under Indiana Code § 35-41-4-2.

Run the Damages Allocation calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

Step 1: Compute the SOL lookback window (default)

  • Filing date: 2024-06-10
  • SOL period: 5 years (default)
  • Lookback start: ~2019-06-10

DocketMath compares each damages bucket (year/event) to whether it falls after the lookback start.

Step 2: Filter damages to the SOL window

Your provided damages are tied to these years:

Damages yearClaimed damagesFalls after ~2019-06-10?Included?
2020$35,000Yes✅ Yes
2021$50,000Yes✅ Yes
2022$25,000Yes✅ Yes
2023$10,000Yes✅ Yes

Result: All claimed damages in 2020–2023 fall inside the default SOL window.

Step 3: Allocate SOL-eligible vs. excluded

  • SOL-eligible damages: $35,000 + $50,000 + $25,000 + $10,000 = $120,000
  • SOL-excluded damages: $0

Step 4: Output summary you’d expect from DocketMath

In practical terms, DocketMath’s damages-allocation output for this input set would align with:

  • Total claimed: $120,000
  • Allocated (default SOL eligible): $120,000
  • Allocated (default SOL excluded): $0
  • Exclusion reason: none triggered because all event years are within the 5-year lookback

Pitfall to watch: If you later add a damages component from (for example) 2018, the same default SOL logic would likely exclude it because it falls before ~2019-06-10. This example assumes the default applies because no specialized SOL sub-rule was provided.

Sensitivity check

Now stress-test the allocation to show how results change when damages shift relative to the 5-year lookback boundary.

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Sensitivity scenario A: Add pre-lookback damages (2018)

Modify the damages breakdown:

  • 2018: $60,000 (new)
  • 2020: $35,000
  • 2021: $50,000
  • 2022: $25,000
  • 2023: $10,000
  • New total claimed: $180,000

Using the same filing date (2024-06-10) and default window (~2019-06-10):

  • Damages in 2018 fall before the lookback start → likely excluded
  • Damages in 2020–2023 remain included

Expected allocation:

Damages yearClaimedIncluded under default SOL?
2018$60,000❌ Excluded (outside ~2019-06-10)
2020$35,000✅ Included
2021$50,000✅ Included
2022$25,000✅ Included
2023$10,000✅ Included
  • SOL-eligible: $120,000
  • SOL-excluded: $60,000

Sensitivity scenario B: Push filing date earlier (narrower lookback)

Keep the original damages (2020–2023 totals), but change the filing date:

  • New filing date: 2023-05-15
  • Lookback start ≈ 2018-05-15 (5 years prior)

Now the boundary moves earlier. If (in your real dataset) some damages fall around 2018, those may shift from excluded to included depending on the exact dates.

Sensitivity scenario C: Identify the “allocation hinge”

The hinge is the boundary date:

  • ~2019-06-10 (for the original filing date 2024-06-10)

  • Items mapped to dates before the boundary are candidates for exclusion.

  • Items mapped to dates on/after the boundary are candidates for inclusion.

Accuracy tip: If you can allocate by month/day (rather than only by year buckets), the tool can apply the window more precisely. If you only have year buckets, the tool will necessarily approximate around the boundary and you may see over- or under-inclusion for a bucket that spans the cutoff.

Practical checklist for running your own DocketMath input set

Related reading