Spreadsheet checks before running Damages Allocation in Kansas

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

When you run Damages Allocation for Kansas, the spreadsheet math can look perfect while the underlying legal time assumptions quietly drift—especially around the statute of limitations (SOL) window your sheet is filtering for. DocketMath’s spreadsheet-checker for Kansas is built to catch those “assumptions aren’t consistent” problems before you allocate damages.

This US-KS checker focuses on the most common failure points that can change which damages rows fall inside/outside the SOL window.

• **Wrong SOL basis (general vs. claim-specific)

  • For Kansas, your jurisdiction data provides a general SOL period of 0.5 years under K.S.A. § 21-6701.
  • DocketMath treats this as the default because no claim-type-specific sub-rule was found for your setup. In practical terms: if your spreadsheet is not set up to apply a different, claim-type-specific limitations rule, the checker expects the sheet to use the general/default 0.5-year parameter.
  • If the calculator output or time filtering implies a different limitations basis than the default you intended, the checker helps you spot that mismatch early.

• **Date alignment mistakes (the silent spreadsheet killer)

  • The checker verifies that the “event date” you’re using (for example, accrual/occurrence date) and the “filing date” are being fed into the calculator consistently.
  • A very common spreadsheet issue: one date field is entered as text while another is stored as a true date (e.g., a date serial). That can shift elapsed time by days—or more dramatically by weeks or months—depending on how the sheet interprets the inputs.

• Negative or nonsensical time windows

  • If your sheet produces a negative elapsed time (for example, the filing date is earlier than the event/accrual date), the checker flags the problem before you reach the allocation step.
  • This matters because damages allocation often relies on whether amounts fall within a calculated SOL period.

• Allocation logic drift across time bands

  • Many damages spreadsheets split damages into multiple time bands (e.g., inside SOL vs. outside SOL, or multiple sub-periods).
  • The checker checks whether the band boundaries in your sheet match the SOL window you intend to use. For example, if one part of the workbook says “6 months” while another uses “0.5 years,” the checker helps you detect that the time-band definitions aren’t actually aligned.

Note (important): The checker is grounded in Kansas’s general/default SOL period of 0.5 years under K.S.A. § 21-6701. If your matter requires a different limitations rule for a specific claim type, you’ll need to reflect that in your spreadsheet inputs—this checker won’t create or assume claim-specific rules that aren’t present in your sheet.

When to run it

Run the spreadsheet-checker at the point where fixes are still cheap:

• Right before you run the damages-allocation calculator, and
• After you finish entering or importing the relevant dates and amounts.

A practical workflow:

1. Populate your spreadsheet inputs

   • Enter the event/accrual date(s) (or the earliest/latest dates your sheet is using).
   • Enter the filing date.
   • Confirm your numeric units are consistent (e.g., dollars vs. thousands; months vs. years).

2. Run the DocketMath spreadsheet-checker

   • Confirm your spreadsheet is set up to use the general/default Kansas SOL basis: 0.5 years under K.S.A. § 21-6701.
   • Fix any flagged issues, especially around date parsing and time-band boundaries.

3. Only then run Damages Allocation

   • After the checker confirms internal consistency, run /tools/damages-allocation and review the allocation outputs.
   • If you change the SOL window or date logic after allocation, you may need to re-audit totals and any SOL-filtered or time-weighted columns, because allocation results often depend directly on the SOL-filtered bands.

Quick checklist you can use in seconds:

Try the checker

If you want to validate your Kansas spreadsheet assumptions before allocating damages, start at:

• /tools/damages-allocation

Even though you’ll run the allocation tool from there, use the checker as a preflight step. Here’s what you’ll typically adjust in your worksheet before running allocation.

What you’ll change in the sheet (inputs)

Focus on:

• **Event/accrual date(s)
• Filing date
• Rows tied to dates (especially any “inside SOL” / “outside SOL” flags)
• Time-band settings (if your spreadsheet splits damages into multiple periods)

What the checker outputs (what you should look for)

After you run the checker, look for:

• Confirmation that the time logic matches the default 0.5-year SOL basis (K.S.A. § 21-6701)
• Date parsing warnings (e.g., text dates where real dates are expected)
• Time-band boundary mismatches
• Nonsensical computed values (like negative elapsed time)

A quick “sanity pass” before allocation:

• If the checker flags anything about dates or bands, fix those first and re-run.
• If it confirms everything is consistent, proceed to Damages Allocation with more confidence that your SOL window logic and spreadsheet structure agree.

Gentle reminder: This is guidance for spreadsheet hygiene and calculator alignment—not legal advice. SOL rules and their applicability can be fact- and claim-specific.

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