Why Damages Allocation results differ in Idaho

The top 5 reasons results differ

If you run DocketMath’s Damages Allocation calculator for Idaho (US-ID) and get different allocations than a colleague (or even than your own earlier run), the cause is usually one of these five “diagnostic” variables. None of these are legal advice—think of them as common data-and-logic mismatch points that drive different outputs.

1) The statute-of-limitations gate (Idaho default: 2 years)

Idaho’s general statute of limitations for many civil actions is 2 years under Idaho Code § 19-403. DocketMath may apply this as a timing constraint that affects whether certain damages fall “inside” or “outside” the recoverable window.

• If one run includes damages occurring after the cutoff and another excludes them, totals will diverge.
• Even a one-month (or one-time-window) shift can matter when the calculator buckets damages by time segments.

Reference: Idaho Code § 19-403 (general/default period)
https://law.justia.com/codes/idaho/title-36/chapter-14/section-36-1406/?utm_source=openai

2) Different date boundaries (incident date vs. accrual date vs. notice/knowledge date)

Allocation outputs can change when the input dates differ, even if everyone agrees on the event “roughly happened around the same time.”

Common mismatches:

• Using the incident/event date as a proxy for accrual
• Using a discovery/knowledge date in one run but not the other
• Setting the end date for the damages calculation to different days

Because the general SOL baseline is 2 years (Idaho Code § 19-403), an input boundary that shifts the window changes which damages are time-eligible.

3) Treatment of partial periods (monthly/segment rounding)

When DocketMath allocates damages across time segments, rounding and segmentation can shift the result.

Examples that commonly cause mismatches:

• Prorating by days in a month vs. using whole month buckets
• Segmenting by calendar months vs. segmenting by an exact-day range

Two runs can use the same raw numbers but still produce different allocations if their segmentation/proration logic differs.

4) Category mapping differences (what gets allocated vs. what is excluded)

Damages allocation often depends on how items are categorized—i.e., which lines are treated as time-based for allocation and which are excluded.

Typical issues:

• Different tagging of “compensatory” vs. “consequential” vs. “other” buckets
• One run treating certain line items as eligible for time-window allocation, while another run excludes them
• Different classification labels for the same underlying damages item

If your inputs are categorized differently, the allocation math will change even with identical date boundaries.

5) Input normalization (frequency, totals, and number formatting)

Even “small” differences can cascade, especially if DocketMath derives totals or converts frequency.

Common normalization mismatches:

• Weekly vs. monthly amounts entered as if they match
• Total damages typed directly in one run, but derived from component lines in another
• Number formatting differences (e.g., entering “12,000” vs. “12000” or including currency symbols)

If the base amounts change, the downstream allocation—especially the time-filtering tied to the Idaho Code § 19-403 general 2-year framework—will change too.

How to isolate the variable

Use a controlled approach: change one input at a time, then compare the pattern of the output (not just the grand totals). This is the fastest way to determine whether the mismatch is driven by timing (SOL/date boundaries) versus data mapping (categories/normalization).

Step-by-step checklist

• incident/event date

  • accrual/knowledge date (and/or the date you used to define “start”)
  • end date for the damages calculation
  • change the accrual/knowledge date by ~30 days, or
  • change the damages end date by ~30 days, or
  • adjust proration/segmentation settings (only if your Damages Allocation setup exposes that option)

What to look for in the output

• Big jump in eligible time buckets → likely an SOL cutoff/date boundary issue
• Eligible window stays the same, but line totals shift → likely category mapping or input normalization
• Gradual shifts that track month/day boundaries → likely segmentation/proration/rounding behavior

Tip: If you change multiple inputs between runs, you’ll lose the ability to attribute the difference. Keep changes surgical.

Next steps

1. Re-run with the exact same dates across both versions of the dataset—especially accrual/knowledge and the damages end date.
2. Verify your SOL assumption in your workflow: for Idaho, the baseline reference here is the general 2-year period under Idaho Code § 19-403 (not a claim-type-specific rule).
3. Standardize damages entry format:

   • Use consistent frequency (all weekly or all monthly), or ensure DocketMath is deriving totals in the same way for both runs.
   • Use the same category tags for each damages line item.
4. Document your inputs (even a short checklist of the dates, categories, and frequency) so the two runs are truly comparable.

If you share the two runs’ date inputs (accrual/knowledge and end date) and identify which damages lines differ (category + frequency), you can usually pinpoint the driver quickly—without guessing.

Primary CTA: /tools/damages-allocation

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