Spreadsheet checks before running Structured Settlement in Idaho

What the checker catches

Running a structured settlement in Idaho starts long before the first payment schedule is drafted. In practice, the “risk” often hides in paperwork mechanics: date math, stale claims, missing assumptions, and inconsistent inputs across your spreadsheet and your structured settlement inputs.

DocketMath’s structured-settlement spreadsheet checker (jurisdiction-aware for Idaho — US-ID) helps you catch the issues that most often cause delays or post-draft disputes.

Here are the common spreadsheet problems the checker is designed to flag before you commit to a structure:

• Statute of limitations (SOL) countdown errors

  • The checker applies Idaho’s general limitations period: 2 years under Idaho Code § 19-403.
  • It models whether your claim timeline is aligned with that SOL framework based on the dates you enter.

• Missing or mismatched key dates

  • Uploading or entering fewer than the checker’s required dates (for example, incident/occurrence date, notice/filing date if your worksheet uses it, and the proposed settlement date) can create misleading results.
  • The checker prompts you to make sure your “source of truth” dates are consistently used across tabs or worksheets, not duplicated with slightly different values or formats.

• Incorrect start date logic

  • Idaho’s general rule under Idaho Code § 19-403 is applied as a default when you’re not using a claim-type-specific limitations sub-rule.
  • Per the jurisdiction note for this checker, no claim-type-specific sub-rule was found, so it uses the general/default SOL period rather than attempting category-specific tailoring.

• Scenario drift across spreadsheet versions

  • When you revise settlement timing (for example, moving the execution date or changing payment commencement), spreadsheets sometimes update one tab but not the calculation tab.
  • The checker helps ensure that scenarios (like “Scenario A” vs. “Scenario B”) are not accidentally calculating from the wrong date inputs.

• Conflicting jurisdiction assumptions

  • If your spreadsheet was built for another state and you switch to Idaho, it’s easy to leave non-Idaho SOL parameters in place.
  • The US-ID rules help prevent “carryover” errors—especially around time limits.

To anchor the rules the checker uses:

• General SOL Period: 2 years
• General Statute: Idaho Code § 19-403

You can find the statute in this code section:
https://law.justia.com/codes/idaho/title-36/chapter-14/section-36-1406/?utm_source=openai

When to run it

Timing matters. Run the checker before you lock the settlement narrative and payment timeline into final drafts.

A practical workflow that works well with DocketMath:

• Before drafting the structure terms

  • Check that your “proposed settlement date” and relevant timeline inputs won’t produce a SOL conflict under Idaho’s general/default framework.

• After you set initial assumptions, but before you circulate

  • Treat the first pass as a validation step. Once the spreadsheet matches the story your team will explain to stakeholders, you reduce downstream friction.

• Whenever you change any of these inputs

  • Incident/occurrence date
  • Notice date / filing date (if your worksheet model uses it)
  • Proposed settlement execution date
  • Payment commencement date (if your spreadsheet ties it to the same timeline framework)

Use a quick checklist to decide if you should rerun the checker:

For Idaho (US-ID), the checker’s SOL component is driven by the 2-year general limitations period under Idaho Code § 19-403. Since no claim-type-specific sub-rule was found, the checker will keep applying the general/default approach unless you revise the spreadsheet assumptions and/or inputs to reflect a different governing rule.

Try the checker

If you want the fastest path to fewer spreadsheet surprises, run DocketMath’s Idaho-aware checker directly here:

• Primary CTA: /tools/structured-settlement

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

What to feed it (so outputs are meaningful)

You’ll typically want to ensure your spreadsheet includes (or your inputs provide) dates that let the checker model the timeline. In a clean workflow:

1. Choose your “source of truth” date cells

   • Don’t let multiple tabs define the incident date in slightly different formats.

2. Add one “proposed settlement date” field

   • This is the date you intend to align with your structured settlement agreement timeline.

3. Keep the jurisdiction constant

   • Confirm the jurisdiction setting is Idaho (US-ID) so the 2-year general SOL under Idaho Code § 19-403 is applied.

How outputs change when you adjust inputs

Use these “what-if” levers to see why the checker matters:

• If you move the proposed settlement date later

  • The modeled timeline toward the 2-year window tightens, increasing the likelihood of an unfavorable SOL alignment result (under the general/default framework).

• If you move the incident date earlier

  • The time elapsed increases, again affecting the SOL alignment output.

• If you previously calculated using another state’s rules

  • Re-running under US-ID will often change SOL-related results because Idaho’s default is 2 years under Idaho Code § 19-403.

If your first run shows a potential SOL mismatch, treat that as a signal to fix the spreadsheet model before you revise substantive settlement terms. Most issues come from date inconsistencies, not from the structured settlement concept itself.

Related reading

• Structured Settlement Calculator Guide for Alabama
• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado