Spreadsheet checks before running Structured Settlement in Kansas

What the checker catches

Run this scenario in DocketMath using the Structured Settlement calculator.

Before you run a Structured Settlement workflow in Kansas with DocketMath, run a quick spreadsheet sanity check. In Kansas, this is especially valuable because small spreadsheet input mistakes can quietly shift timing calculations—creating schedule errors even if the settlement amounts themselves are correct.

DocketMath’s spreadsheet checker (structured-settlement, US-KS) is designed to catch common spreadsheet issues that affect structured settlement modeling. In this Kansas setup, the key timing lever many structured settlement spreadsheets use is the general statute of limitations (SOL) period, governed by K.S.A. § 21-6701.

Here’s what the checker looks for:

• **Wrong SOL assumption (missing Kansas default)

  • Kansas uses a general SOL period of 0.5 years under K.S.A. § 21-6701 (this is the general/default period).
  • Your model should not swap in a claim-type-specific SOL rule unless your claim analysis explicitly supports that rule.
  • For this checker configuration, no claim-type-specific sub-rule was found, so the model uses the general/default period clearly tied to K.S.A. § 21-6701.

• Date-field formatting errors

  • Cells that look like dates but are stored as text (e.g., 01/02/2026 entered as a string).
  • Mismatched date bases (for example, Excel serial dates vs. real calendar dates being compared directly).
  • Blank or missing settlement dates that can cascade into defaults like “0 days” or “today.”

• Off-by-one timing drift

  • Systems that count from the wrong “start” day (e.g., using funding date when the sheet intends agreement date, or using event date vs. reference date).
  • Rounding conversions that change results by a few weeks:

    • weeks/months → days conversions
    • days → years calculations using different day-count conventions
      These small differences can be enough to flip a gate like “within SOL” vs. “outside SOL.”

• Spreadsheet link/reference problems

  • Broken formulas referencing deleted rows, renamed columns, or moved sheets.
  • Currency formatting mixed with numeric values (e.g., $250,000 stored as text instead of a number).
  • SUM or range errors that accidentally include headers/totals twice.

• Unit inconsistencies

  • Interest rate entered as 5 instead of 0.05.
  • Payment frequency mismatch to the payment-step logic (monthly vs. quarterly can materially change timing outputs).

Kansas timing rule used by the checker (general/default)

Kansas general SOL period (default in this checker):

• 0.5 years under K.S.A. § 21-6701

Source: https://www.kslegislature.gov/li/s/statute/021_000_0000_chapter/021_067_0000_article/021_067_0001_section/021_067_0001_k.pdf?utm_source=openai

Note: No claim-type-specific sub-rule was found, so this content and the checker default to the general/default period above.

When to run it

Run the checker twice: (1) before you finalize inputs and (2) after you update the schedule. This order catches the most common “late-stage recalculation” surprises.

Use this sequence:

1. Pre-run: before modeling structured payments

   • Confirm which spreadsheet columns represent:

     • the trigger/reference date (the sheet’s “start” for timing)
     • agreement date and/or funding date(s) (whichever your sheet uses downstream)
     • any helper columns that compute days/weeks/elapsed years
   • Verify that the checker is using Kansas default SOL = 0.5 years from K.S.A. § 21-6701 (general/default, not claim-type-specific).

2. Post-run: immediately after you update assumptions Re-check after any of these changes:

   • payment frequency changes (e.g., monthly ↔ quarterly)
   • first payment date changes
   • term length or end date changes
   • any settlement date or “event/reference date” revisions

3. Before exporting or sharing

   • Copying values into a “presentation” tab, exporting to PDF/CSV, or re-importing data can convert dates to text or numbers to strings.
   • The checker can flag these conversion problems before they propagate.

Quick rule of thumb:

• If you changed a date, rerun the checker.
• If you changed a timing window assumption, rerun the checker.
• If you changed frequency or step size, rerun the checker.

Try the checker

You can access DocketMath’s structured settlement spreadsheet checker here:

• /tools/structured-settlement

Before you run it, prepare (or validate) these spreadsheet inputs so the checker can evaluate them accurately:

• Kansas jurisdiction selection

  • Use US-KS so the checker applies K.S.A. § 21-6701 general/default SOL of 0.5 years.

• Dates

  • Ensure date fields are true dates (not text).
  • Confirm the same date format behavior across the sheet (especially if you have multiple date columns).

• Timing math helpers

  • If your sheet computes “days since event” or “elapsed years,” verify those formulas reference the intended date columns.

• Payment schedule parameters

  • payment frequency (monthly/quarterly/etc.)
  • first payment date
  • total number of payments or end date

A simple test checklist:

Warning (non-legal advice): This tool and checklist are for spreadsheet validation and workflow checks, not for legal determinations. The checker applies the general/default SOL for Kansas unless a different, claim-specific rule is explicitly and properly supported by your analysis. In this configuration, no claim-type-specific sub-rule was found, so the default remains 0.5 years under K.S.A. § 21-6701.

Related reading

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