Why Damages Allocation results differ in Wisconsin
4 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
When DocketMath’s Damages Allocation calculator produces different outputs for the same underlying claim in Wisconsin (US-WI), it’s usually not the math—it’s the inputs and how Wisconsin applies timing rules.
In Wisconsin, the general/default statute of limitations (SOL) period is 6 years under Wis. Stat. § 939.74(1). No claim-type-specific sub-rule was found for this brief, so treat this 6-year period as the baseline/default framework for SOL timing in your runs (unless you have a specific, additional reason to apply a different rule).
Here are the top reasons results diverge, even when you believe you selected the same settings:
Different “start date” interpretation
- A small change in what you treat as the trigger date (e.g., violation date vs. discovery date vs. filing-related reference date) can shift which damage periods fall inside vs. outside the 6-year SOL window.
Inconsistent SOL window cutoffs
- Because Wisconsin’s 6-year general SOL creates a firm boundary, switching the cutoff rule (or the date you anchor it to) can move amounts across the “in SOL” vs. “out of SOL” buckets—changing your allocation totals.
Rounding and proration method
- Allocation typically requires splitting damages across periods. Differences in proration approach (for example, monthly vs. daily, and inclusive vs. exclusive day handling) can create noticeable differences—especially when the underlying damages span many months or years.
Unmapped or missing damage components
- If one dataset includes categories the other omits (or labels them differently), DocketMath can only allocate what it receives. Common examples include penalties/fees or interest-like components—if they’re missing or not mapped consistently, totals will differ.
Data normalization differences
- Practical causes include:
- entering amounts in different formats (dollars vs. cents, commas, stray symbols),
- mixing gross vs. net values,
- inconsistent identifiers that change how line items roll up into categories.
Pitfall: The biggest driver is often not the formula—it’s the date. If two runs use different trigger/cutoff dates, the “inside the 6-year window” bucket changes, and the allocation follows.
How to isolate the variable
Use this diagnostic checklist to pinpoint what’s driving the discrepancy. The core idea: change one input at a time, then compare the “in SOL” vs. “out of SOL” output buckets.
- Freeze the jurisdiction and tool settings so both runs use the same rule set.
- Compare one input at a time (dates, rates, amounts) and re-run after each change.
- Review the breakdown to see which segment or assumption drives the difference.
Step-by-step isolation workflow
Compare these outputs side-by-side
Create a quick comparison table from Run A vs. Run B:
| What you compare | Run A | Run B | Why it matters |
|---|---|---|---|
| SOL cutoff date used | Drives which periods count | ||
| Total allocated “in SOL” damages | Usually the biggest swing | ||
| Total allocated “out of SOL” damages | Often the remainder bucket | ||
| Number of periods/days allocated | Helps detect proration differences | ||
| Any missing categories | Yes/No | Yes/No | Unmapped items can’t be allocated |
Minimal-change test
Try this sequence:
- Run 1: your baseline settings.
- Run 2: change only the trigger/start date by a single day.
- Run 3: change only the date convention (e.g., inclusive vs. exclusive window logic, if available as an input).
- Run 4: change only proration frequency (monthly vs. daily), if DocketMath offers that option.
If the “in SOL” number jumps between runs, the variable is likely your date cutoff/trigger logic, not your allocation mechanics.
(Gentle note: this is a workflow to help you debug your inputs—this content isn’t legal advice.)
Next steps
Use DocketMath with a controlled scenario
- Keep jurisdiction fixed (US-WI), keep dollar inputs fixed, and test date-related inputs first.
Document the SOL boundary you’re applying
- Record the exact cutoff date used in your DocketMath run and confirm it aligns with the 6-year general SOL baseline under Wis. Stat. § 939.74(1).
Validate category completeness and mapping
- Confirm every damage component you expect is present and labeled consistently across runs. If a category is missing or mapped differently, the allocation totals will change.
Re-run from the primary tool entry
- Start a clean run using the calculator to compare a known baseline to your prior configuration: /tools/damages-allocation .
If you can still reproduce the discrepancy, reduce the dataset to the smallest subset that triggers the difference, then add complexity back only after your date and mapping tests stabilize.