Spreadsheet checks before running Damages Allocation in Wisconsin

What the checker catches

Run this scenario in DocketMath using the Damages Allocation calculator.

Running a damages allocation spreadsheet in Wisconsin is more reliable when you validate the inputs before you compute. DocketMath’s damages-allocation calculator helps with the allocation math, but the spreadsheet checks are there to prevent common “garbage in, garbage out” problems—especially issues tied to time windows.

The checker is designed to catch these categories of problems before you rely on the allocation results:

• Wrong or missing “trigger” date

  • Many damages workflows depend on when something occurred (for example: breach, accrual, notice, completion). If your spreadsheet uses the wrong date column—or leaves the date blank—the downstream allocation can be materially wrong.
  • The checker flags:

    • blank trigger dates
    • reversed date ranges
    • inconsistent “start/end” ordering (e.g., end date earlier than start date)

• **Suspicious date window length (Wisconsin default)

  • Wisconsin includes a general/default 6-year statute of limitations period under the criminal limitations framework.
  • The checker uses Wis. Stat. § 939.74(1) as the baseline because no claim-type-specific sub-rule was provided in the brief:

    • General SOL Period (default): 6 years
    • Source: Wis. Stat. § 939.74(1) (“Except as otherwise provided in this section, the period of limitation is 6 years…”)
      https://codes.findlaw.com/wi/crimes-ch-938-to-951/wi-st-939-74/
  • If your spreadsheet allocates damages across a span that exceeds 6 years from the selected trigger date, the checker highlights it so you can confirm whether:

    • the trigger date is correct, and/or
    • the allocation period should be narrower under the default window.

• Inconsistent accounting periods

  • Allocation sheets often use quarterly, monthly, or annual “buckets.”
  • The checker verifies:

    • bucket boundaries align with the intended date range
    • totals roll up correctly across buckets
    • there are no “orphan” rows (damages entries that don’t land in any bucket)

• Mismatch between transactional dates and amounts

  • Even when dates are present, errors can hide in the data rows. The checker looks for:

    • duplicate entries (same description and amount posted on the same date)
    • rows with amounts but missing dates (or dates with zero/blank amounts)
    • negative numbers in fields where non-negative values are typically expected

• Allocation distribution sanity

  • Allocation can fail even if dates and buckets appear correct—especially when weights/ratios are off.
  • The checker ensures weights/ratios:

    • sum to expected totals (or are clearly normalized)
    • don’t produce obvious “impossible” outcomes (for example, allocations that imply more than 100% without an explanation)

Pitfall to watch: A spreadsheet can be neatly formatted and still be wrong if the “start date” is actually the filing date (or vice versa). The checker’s date-consistency checks are meant to catch those issues before you rely on the allocation.

Wisconsin time rule the checker uses (default)

Because no claim-type-specific sub-rule was identified in the brief, the checker applies the general/default 6-year limitations period as the baseline:

• General SOL Period (default): 6 years
• Wis. Stat. § 939.74(1)
  https://codes.findlaw.com/wi/crimes-ch-938-to-951/wi-st-939-74/

In practical terms: if your worksheet allocates damages over more than 6 years from the trigger date you select, the checker will flag the mismatch for review.

When to run it

Run the checker early, before you commit to allocation outputs or share results. The goal is to confirm that your timeline and mapping logic are consistent before formulas and totals start propagating errors.

A simple, practical sequence:

• Before you set allocation buckets

  • Confirm the trigger date and the bucket start/end dates.
  • Check that the bucket coverage aligns with the 6-year default window derived from Wis. Stat. § 939.74(1) (unless you intentionally structured the spreadsheet to go beyond it).

• Immediately after you import or paste data

  • If your data comes from a ledger, invoicing system, another spreadsheet, or an export from elsewhere, run checks right away.
  • This helps catch:

    • missing dates
    • inconsistent date formats (e.g., MM/DD/YYYY vs DD/MM/YYYY)
    • stray rows created during copy/paste

• After you adjust weights or allocation formulas

  • Any change to denominators, normalization logic, or percentage inputs can shift totals.
  • Re-run the checker right after formula or weight edits.

• Before exporting final reports

  • Treat “export” as a release step: run checks again so corrections (like a fixed date format) actually propagate to all buckets.

Quick checklist for each run:

Try the checker

Use DocketMath’s damages-allocation workflow here:

• Primary calculator: /tools/damages-allocation

Suggested test steps:

1. Open /tools/damages-allocation
2. Enter your core timeline inputs:

   • Trigger date (the baseline for the checker’s default SOL alignment)
   • Bucket range (the period you are allocating across)
3. Add damages entries (or paste/upload them, depending on how your DocketMath session is set up).
4. Run the spreadsheet checks first.
5. If the checks pass, proceed to the allocation computation.

If you change any of the following, rerun the checker:

• trigger date (changes the default 6-year alignment)
• allocation period start/end (changes which buckets receive entries)
• weights/ratios (changes how amounts distribute)
• date format or column mapping (prevents silent misreads)

How outputs change when checks flag issues

The checker doesn’t just “note” problems—it helps you decide what to trust. Common patterns:

• If dates exceed the 6-year default window

  • Expect allocation outputs to reflect damages allocated outside your intended eligibility window.
  • Correcting the trigger date or bucket range typically changes which buckets include entries and shifts totals.

• If buckets don’t align

  • Entries can land in the wrong bucket or fail to roll up.
  • Fixing bucket boundaries changes per-bucket totals and the final distribution.

• If weights don’t sum or normalize

  • Percent-based allocations can inflate or undercount damages.
  • Correcting weights changes the distribution even if dates are correct.

Gentle note: This is not legal advice. DocketMath’s spreadsheet checks focus on internal consistency and jurisdiction-aware defaults (including Wisconsin’s 6-year baseline under Wis. Stat. § 939.74(1)). You should still review results for accuracy and suitability to your specific situation.

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