Spreadsheet checks before running Damages Allocation in Minnesota

What the checker catches

DocketMath’s damages-allocation calculator is built to help you allocate damages consistently. But before you run the numbers, you want to sanity-check your spreadsheet against Minnesota’s basic limitation rules—because even a small date logic error can change which periods of damages are treated as included vs. excluded.

For Minnesota, this checker is keyed to the general/default statute of limitations (SOL) rather than a claim-type-specific carve-out. There wasn’t a claim-type-specific sub-rule identified for this brief, so the checker uses the default 3-year SOL under Minnesota Statutes § 628.26 as the starting point. (This is not legal advice; it’s a practical modeling baseline.)

Here’s what DocketMath’s spreadsheet checks for before allocation math:

• **Wrong “trigger date” (event vs. filing vs. demand)

  • Many allocation models accidentally use the filing date as the SOL start.
  • For SOL modeling, you typically want the date the claim accrued (often tied to the underlying event).
  • The checker looks for clarity and consistency around your “SOL start date” input—so the spreadsheet’s timeline matches the intended SOL concept.

• Missing or misformatted dates

  • The difference between “3 years” and “3 years plus/minus a day” often comes down to date handling.
  • Common issues the checker flags:

    • dates entered as text instead of real spreadsheet dates
    • blank or incomplete trigger/SOL start inputs
    • inconsistent formatting across tabs (e.g., one sheet using a different date convention)

• Off-by-one errors around the 3-year window

  • If your spreadsheet uses rounding (or integer-day conversion) for boundaries, you can accidentally shift a row that should be inside the window to outside it.
  • The checker highlights boundary risk when your computed SOL end date falls close to your damages cutoff logic.

• Using a non-default SOL assumption without spreadsheet support

  • A frequent modeling error is switching to a claim-specific limitations period without documenting it in the sheet’s logic.
  • Because this brief does not identify a claim-type-specific sub-rule, the checker treats the model as using the default 3-year period from Minn. Stat. § 628.26—unless your spreadsheet clearly indicates otherwise.

• Allocations that ignore SOL consequences

  • Some sheets compute totals for the entire damages period and only later apply SOL concepts (or not at all).
  • The checker encourages an explicit “included vs. excluded” structure by verifying whether your allocation actually applies the SOL window to time-bounded components—especially when your spreadsheet has multiple “from/to” slices.

• Inconsistent unit basis and time slicing

  • Weekly vs. monthly vs. daily figures can subtly distort totals when the model mixes time bases.
  • The checker looks for:

    • inconsistent time-unit conversions
    • mismatched period boundaries across categories
    • formulas that reference different “period start” / “period end” cells than the rest of the model

Pitfall to watch: Your damages math can be internally consistent and still be misaligned with the default Minnesota 3-year SOL model under Minn. Stat. § 628.26, if the spreadsheet’s date logic includes periods that fall outside the intended SOL window.

When to run it

Run the spreadsheet checks before you calculate allocations, and again anytime changes could affect the SOL window or how dates roll up into included/excluded periods.

A practical sequence:

1. Confirm your SOL inputs

   • Verify you have (and that the sheet uses):

     • SOL start date (the spreadsheet’s assumed accrual/trigger date)
     • SOL end date computed from the default 3-year period
   • For this brief, the baseline is 3 years under Minn. Stat. § 628.26.

2. Validate date consistency

   • Ensure every date field the model uses is a real date (not text).
   • Confirm the same date format works across all related tabs and lookups.

3. Freeze your allocation periods

   • Make sure your damages “from/to” ranges match the same timeline your SOL calculations reference.
   • If you allocate by month, your boundaries should be month-aligned (and not partially overlapping in ways that can create accidental inclusion/exclusion).

4. Only then run DocketMath

   • After the dates and boundaries are coherent, run the damages-allocation calculator.
   • Review whether the output’s “included vs. excluded” logic is consistent with your SOL window definition.

When to rerun the checker:

• You change the SOL start date (trigger/accrual)
• You update damages period boundaries (“from/to” dates)
• You adjust any time slicing (weekly/monthly/daily)
• Someone edits referenced cells that affect date math, lookups, or boundary checks

Try the checker

You can use DocketMath to standardize the workflow: validate spreadsheet assumptions first, then run the damages-allocation calculator.

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

What to prepare in your spreadsheet

Aim to have inputs in a clear, consistent structure, including:

• SOL start date (the date the spreadsheet uses to begin the 3-year clock)
• Allocation start date / end date (the period(s) your damages model covers)
• Damages breakdown columns

  • amounts by time slice (e.g., monthly/weekly)
  • optional category labels if you split damages components across types

How outputs typically change after validation

Once the checker finds and corrects date/boundary issues, you may see changes like:

• Adjusted included-period totals

  • If the sheet previously pulled in pre-SOL rows, the output may exclude them or flag inconsistencies.

• Recalculated totals driven by correct date math

  • Fixing date formats and boundary formulas can change the computed SOL end date, which can shift which rows fall inside vs. outside the SOL window.

• Formula corrections that realign period references

  • Totals can change when a subset of rows points to the wrong “period start/end” cells.

To get started, open DocketMath’s damages allocation tool here:
/tools/damages-allocation

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