Spreadsheet checks before running Damages Allocation in South Dakota

What the checker catches

DocketMath’s Damages Allocation workflow is spreadsheet-driven, which makes it fast—until one incorrect cell or mismatched timeline quietly skews every allocation output. DocketMath includes a South Dakota (US-SD) jurisdiction-aware spreadsheet checker designed to help you spot timing problems before you run allocation math.

This checker focuses on South Dakota’s default limitations timing using the 3-year general statute of limitations set by SDCL 22-14-1. In the jurisdiction data provided, no claim-type-specific sub-rule was identified, so the checker clearly treats the SDCL 22-14-1 general 3-year period as the baseline for the spreadsheet.

Common issues the checker can catch include:

• Missing or incorrect accrual-to-filing timeline

  • The checker looks for your spreadsheet’s accrual date (or equivalent trigger date) and your filing date.
  • It then calculates the interval and checks whether it aligns with the 3-year general period under SDCL 22-14-1.
  • If the key timeline fields are blank, mis-entered, or mapped to the wrong columns, the checker will flag the inconsistency.

• Using the wrong default SOL rule

  • For South Dakota, the checker defaults to the general 3-year limitation period in SDCL 22-14-1.
  • Because the jurisdiction data you supplied did not identify any claim-type-specific SOL alternative, the checker does not apply a different sub-rule automatically.
  • If your spreadsheet was built assuming a different limitation period, the checker highlights that mismatch so you can correct the assumption before results are generated.

• Off-by-one / “boundary day” date errors

  • Spreadsheet comparisons can flip outcomes when dates are near the edge of the limitation period.
  • Examples include:

    • date values stored in a different format than you expect (e.g., YYYY-MM-DD vs MM/DD/YYYY),
    • manually adjusted dates,
    • or inconsistent handling of the “boundary” day when checking whether something is “within 3 years.”
  • The checker flags near-boundary issues so you can confirm the correct interpretation of the dates you entered.

• **Inconsistent date formatting across tabs (text vs. true dates)

  • A frequent failure mode: one tab uses proper spreadsheet date formatting, while another stores dates as text.
  • When that happens, date-based comparisons can silently misbehave.
  • The checker detects cells that appear date-like but act like text, helping prevent incorrect SOL gating and downstream period calculations.

• Allocation logic that depends on SOL-gated timelines

  • Many damages allocation models distribute amounts across time windows (monthly/quarterly periods, incident windows, discovery-to-incident spans, etc.).
  • If the checker determines your SOL window is inconsistent, that can cascade into multiple downstream allocation rows—because your spreadsheet may “include or exclude” whole periods based on the limitations result.
  • The checker aims to stop the domino effect before damages allocation totals are computed.

Important: A spreadsheet can still “work” mathematically even if the timing inputs are legally mis-timed. This checker is focused on catching timing/spreadsheet issues that change what gets included in the allocation based on the SDCL 22-14-1 general 3-year baseline.

When to run it

Run the checker at a point that prevents rework—typically after you finalize relevant dates but right before you execute the Damages Allocation calculation.

A practical sequence:

1. Enter or import core timeline fields

   • Accrual date(s) (or whatever your model treats as the start of the limitations clock)
   • Filing date
   • Any per-incident/per-period dates used to build the allocation windows

2. Run DocketMath’s Damages Allocation flow

   • Before you rely on the output allocation results, run the spreadsheet checker as part of the Damages Allocation workflow.

3. Review and fix flagged items

   • Correct date formatting and mappings
   • Confirm you are using the correct SOL baseline for South Dakota (3 years under SDCL 22-14-1)
   • Address any near-boundary warnings by verifying the intended “trigger” date and the accuracy of the filing date

4. Re-run the checker

   • Confirm the same issues don’t persist and that corrected dates now produce consistent SOL timing determinations.

Rule of thumb: if you change any date field (accrual trigger, incident date, discovery-related trigger, filing date, or period boundaries), rerun the checker immediately—don’t wait until after allocation totals are calculated.

South Dakota baseline used by the checker

• General statute of limitations: 3 years
• Authority: SDCL 22-14-1

Because the provided jurisdiction data did not identify any claim-type-specific sub-rule, the checker applies the SDCL 22-14-1 general 3-year period as the default across the spreadsheet unless you have a separate, validated override already built into your workflow.

Try the checker

You can test the workflow without changing your existing spreadsheet setup by going directly to DocketMath’s calculator:

**Go to Damages Allocation

Then use this quick checklist:

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

How outputs change when the checker finds an issue

Use this table as a “what to expect” guide:

Pitfall to watch: If your spreadsheet allocates by period (e.g., monthly/quarterly windows), a single incorrect accrual date can shift multiple period rows. The checker helps prevent that cascade.

Jurisdiction-aware rule applied (US-SD)

For South Dakota, the checker uses:

• 3-year general limitations period
• SDCL 22-14-1

No claim-type-specific sub-rules were included in the provided jurisdiction data, so the checker treats SDCL 22-14-1’s general 3-year period as the applicable baseline.

Gentle note: This content supports spreadsheet validation and the default period you provided. It does not replace legal analysis of any claim-specific limitations rules that may exist beyond what your spreadsheet captures.

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