Common Damages Allocation mistakes in Wisconsin

The top mistakes

Run this scenario in DocketMath using the Damages Allocation calculator.

In Wisconsin, damages-allocation errors often happen when people treat “time to sue” and “which damages belong in which category” as simple bookkeeping—rather than as jurisdiction-aware inputs that affect the outcome of a DocketMath workflow.

Below are common Wisconsin mistakes and practical ways to correct them. (This is general information, not legal advice.)

1) Using the wrong SOL length by default

A frequent error is assuming a shorter (or longer) limitations period without anchoring to Wisconsin’s default rule.

For Wisconsin, the general/default SOL for the relevant action type in your jurisdiction data is 6 years, governed by:

• Wis. Stat. § 939.74(1) (general rule)
  https://codes.findlaw.com/wi/crimes-ch-938-to-951/wi-st-939-74/

Key takeaway: Based on the provided jurisdiction data, no claim-type-specific sub-rule was found. So you should apply the 6-year general/default period consistently unless you have a clearly identified, claim-specific limitations provision.

2) Miscomputing the 6-year lookback window

Even when the 6-year rule is correct, the math can go wrong. Common computation errors include:

• using a “filing date” instead of the timeline anchor/trigger date your workflow uses
• counting partial years inconsistently
• handling boundary dates incorrectly (off-by-one day / off-by-one year issues)

In DocketMath terms, the effective lookback start date is an input that determines which damages line items fall inside or outside the recoverable window. If that start date is wrong, your allocation will be wrong even if every dollar amount is entered correctly.

3) Allocating damages to categories before filtering by time

Another frequent workflow error: splitting damages into categories first (e.g., medical vs. lost income vs. other) and only later applying the SOL filter.

That order often leads to confusion and rework. If your allocation requires excluding time-barred amounts, you’ll usually get cleaner results by:

• first filtering damages by date into in-window vs. out-of-window
• then allocating the in-window amounts into categories

This prevents category “cleanup,” where you later remove money from categories that should not have been included in the first place.

4) Treating all damage amounts as equally “dateable”

Some damages are naturally tied to dates (monthly expenses, pay periods, invoices). Others are less granular (lump-sum invoices, settlement-like totals, or aggregated estimates).

If you force every lump-sum number into a single date bucket, you can distort the allocation. DocketMath outputs depend on how you map those amounts to a timeline.

A practical fix is to convert aggregated figures into a date spread when the evidence supports it—for example, allocating an invoice across the service period it covers—so the SOL filter can work correctly.

5) Forgetting that DocketMath is only as reliable as your inputs

DocketMath can help organize and calculate, but it won’t automatically infer missing dates, categories, or assumptions.

Common input omissions that create downstream allocation errors include:

• missing transaction dates for each expense line item
• using the wrong incident/start date as the timeline anchor
• mixing one-time damages and recurring damages without tagging them separately (even simple tagging helps keep the date logic consistent)

6) Overrelying on totals while ignoring line-item recoverability

Totals hide problems. Two allocations can show the same grand total while having different legal recoverability once time windows are applied.

Instead of checking only the final total, sanity-check:

• how much of each line item falls within the 6-year SOL window
• how allocation percentages change after SOL filtering (not before)

If category shares barely move when you adjust the timeline anchor, it may be a sign that dates aren’t actually being used as intended.

How to avoid them

To reduce damages-allocation mistakes in Wisconsin using DocketMath, use a repeatable checklist and verify the “time filter” early.

Use a written checklist for inputs, document each source, and run a quick sensitivity check before finalizing the result. When two runs differ, compare inputs line by line and re-run with one variable changed at a time.

Step 1: Lock the Wisconsin default SOL window (6 years)

Start from Wisconsin’s general/default period. Use:

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

Then confirm you are not using a claim-specific rule. Your jurisdiction data states no claim-type-specific sub-rule was found, so the default 6-year period should be the baseline.

Step 2: Compute the lookback window once, consistently

In DocketMath, treat the computed window as a “single source of truth”:

• decide the timeline anchor your workflow uses (e.g., the date you treat as starting the relevant period)
• subtract the 6 years
• apply that window the same way to every damages line item

To avoid off-by-one errors, standardize date handling (for example, use the same day-level format for all line items and anchors).

Step 3: Apply SOL filtering before category allocation

Use a workflow order that reduces rework:

1. mark each damages line item as in-window or out-of-window based on its date
2. allocate only the in-window amounts into categories

This makes it easier to see what changed when you adjust the timeline input, because the filtering step happens before any category math.

Step 4: Date your numbers—especially lumpsums

For amounts not naturally tied to a single date, break them into dateable components where the underlying records support it.

In DocketMath, that generally means ensuring each line item includes:

• a defensible date (or a date range mapped to a date)
• a category label (so the output isn’t forced to guess)
• a consistent unit (for example, invoice total vs. monthly expense)

If you can’t assign a supportable date, it’s harder for any tool to filter correctly.

Step 5: Review outputs using two checks (not one)

After running DocketMath, validate using both:

• Window totals: total dollar amount in-window vs. out-of-window
• Category distributions: category percentages after the SOL filter

If a category percentage barely changes when you tighten or loosen the timeline input, you may have used totals without actually applying the dates as intended.

Step 6: Document assumptions used in the timeline

Even without legal advice, you can reduce confusion by recording:

• the date anchor you used
• how you computed the 6-year window under **Wis. Stat. § 939.74(1)
• how you mapped lump-sum amounts to dates or periods

Those notes make it faster to correct allocation mistakes if the timeline anchor or supporting dates later change.

To run this type of workflow, start at: /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