Spreadsheet checks before running Damages Allocation in Idaho

What the checker catches

Before you run Damages Allocation in Idaho with DocketMath, a spreadsheet can quietly drift out of compliance—especially around the Idaho statute of limitations (SOL). The purpose of the spreadsheet-checker is to flag problems before your damages timeline becomes “baked into” your allocation results.

This jurisdiction-aware checker is built around Idaho’s general SOL for civil actions:

• General SOL period: 2 years
• General statute: Idaho Code § 19-403
• Default rule (important): No claim-type-specific sub-rule was found in the provided jurisdiction data. That means the checker uses the general/default 2-year period rather than a different period by cause of action.

Here are the most common spreadsheet issues it catches for Idaho damages allocation workflows:

• Date window errors

  • Missing or misformatted event dates (for example, “01/5/24” vs “2024-01-05”).
  • A filing date earlier than the last relevant event date your sheet uses as the trigger.
  • Damages start/end dates that extend beyond the 2-year lookback window implied by the general SOL rule.

• Inconsistent timeline columns

  • One tab uses “Loss Month,” while another uses “Loss Date.”
  • Allocation buckets that overlap or leave gaps (for example, Bucket 1 covers 2/1–3/15, but Bucket 2 starts 3/10).
  • Summary totals that don’t reconcile to the sum of bucket rows.

• Wrong sign or unit mistakes

  • Amounts entered with the wrong sign (e.g., negatives in some buckets and positives in others).
  • Using “annual” numbers while the allocation model expects “monthly,” which can systematically over-allocate or under-allocate across the entire timeline.

• Hidden non-damages inputs

  • Cells containing text like “N/A” in numeric allocation fields (which can quietly break calculations).
  • Damages rows including items meant for separate accounting categories (like penalties, interest, or costs) when your allocation model expects only compensable damages.

Pitfall to avoid: Even if your spreadsheet “adds up,” a damages timeline that runs past Idaho’s 2-year general SOL under Idaho Code § 19-403 may be incompatible with a limitations-restricted recovery approach. The checker helps you catch that mismatch early, but it’s not a substitute for legal analysis.

Idaho rule the checker applies (default)

When to run it

Run the spreadsheet-checker immediately before you start Damages Allocation in DocketMath. The best time is after you’ve entered or updated your dates and amounts, but before you commit to allocation buckets and totals.

A practical sequence:

1. Finalize the date inputs

   • Confirm your “last relevant event date” (or the equivalent date your model uses).
   • Confirm your “filing date” (or the trigger date your sheet uses).

2. Validate each damages row

   • Every damages bucket should have:

     • a start date
     • an end date
     • a numeric amount
   • Ensure all rows use consistent units (monthly vs daily vs lump-sum, etc.).

3. Run the checker

   • If it reports SOL-window or timeline issues, fix the spreadsheet first.
   • If it reports reconciliation problems, validate formulas, bucket boundaries, and whether totals are computed from the same source rows the allocator reads.

4. Only then run Damages Allocation With a corrected timeline, your allocation output becomes more dependable because the checker reduces the risk of misaligned time coverage.

If you maintain a repeatable workflow, use a quick preflight list per update:

How the outputs change when the checker flags issues

When the checker flags a timeline problem, it typically affects what date range the allocation model includes. Depending on how your spreadsheet feeds DocketMath, that can change:

• the number of buckets that should receive damages
• the portion of a larger damages entry that should be redistributed into buckets that fall within the applicable window
• the final totals used in your damages allocation output

Try the checker

You can run Damages Allocation with jurisdiction-aware checks directly from DocketMath here:

Open Damages Allocation

Before you click through, make sure your spreadsheet is wired so the checker can validate:

• Filing date (the model’s trigger date)
• Last relevant event date (or the sheet’s equivalent “end of conduct” date)
• Damages bucket start/end dates
• Damages amounts (consistent units across rows)

Then use the spreadsheet-checker as your preflight step to catch:

• SOL-window drift against Idaho Code § 19-403 (general/default 2-year rule)
• timeline overlaps/gaps and date-format inconsistencies
• arithmetic/reconciliation issues that can distort bucket totals

If you want fewer false alarms and more reliable results, keep your spreadsheet date logic deterministic:

• Avoid hard-coded month lengths in some rows while using date arithmetic in others.
• Ensure each bucket’s duration is computed the same way across the sheet.
• Use one date format consistently, and be careful with timestamps/time zones if your inputs include them.

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