Why Damages Allocation results differ in Utah

5 min read

Published April 15, 2026 • By DocketMath Team

The top 5 reasons results differ

Run this scenario in DocketMath using the Damages Allocation calculator.

In Utah (US-UT), DocketMath’s Damages Allocation can produce different output ranges for the same “headline” losses because allocation is driven by timing, coverage/time boundaries, and how jurisdiction-aware rules interact with your inputs. Below are the top five practical causes.

  1. Statute of limitations (SOL) filtering changes what dollars count

    • Utah’s general SOL period is 4 years under Utah Code § 76-1-302.
    • DocketMath can only allocate amounts that fall within the applicable window you provide (for example, based on your entered dates, accrual logic, or the date-of-filing assumption you’re using).
    • Because you’re using the general/default period (and no claim-type-specific sub-rule was found), the baseline is still 4 years—but results can shift when your inputs move amounts in or out of that window.
  2. **You entered different date types (notice vs. accrual vs. filing)

    • Allocation outcomes can change depending on the timeline anchor used in the run, such as:
      • incident date
      • discovery/knowledge date
      • demand/notice date
      • filing date
    • Even if the total claimed amount is the same, changing the anchor date can cause more (or less) of the claimed losses to be treated as within the 4-year window for allocation purposes.
  3. Amounts fall into different buckets across the allocation model

    • Damages allocation typically separates losses into components that respond differently to timing (e.g., past vs. future portions, or other time-responsive categories).
    • If one input set effectively treats a portion as “already accrued” while another treats it as “ongoing,” DocketMath may allocate different proportions across its time-filtered buckets.
  4. **Data granularity (lump sum vs. itemized chronology)

    • A single lump sum may be allocated proportionally across the model’s time buckets.
    • Itemized entries (for example, discrete dated expenses or recurring monthly amounts) let DocketMath place dollars into specific periods—making it more likely that SOL cutoff effects show up clearly.
  5. Jurisdiction-aware rules validate or override your assumptions

    • When you run with US-UT settings, DocketMath applies Utah’s time/SOL logic (including the general 4-year SOL baseline).
    • If your input dataset was created using a different jurisdiction’s timing assumptions, the Utah run can diverge—sometimes enough to look like a “different answer,” even when your headline figures match.

Pitfall: People often compare two runs without confirming that both runs use the same timeline anchor. A relatively small date shift can move dollars across the 4-year boundary and change allocated totals.

For Utah’s SOL baseline, the controlling starting point is:

  • Utah Code § 76-1-302 (General SOL Period: 4 years)
    You’re using the general/default period because no claim-type-specific sub-rule was found in the materials provided.

For general statute limitation timing guidance, see the Utah Courts legal help page: https://www.utcourts.gov/en/legal-help/legal-help/procedures/statute-limitation.html

How to isolate the variable

Use a controlled comparison workflow with DocketMath. The goal is to change one input variable at a time and observe how outputs shift.

  1. Lock the jurisdiction

    • Make sure every run uses US-UT.
  2. Standardize the timeline anchor

    • Choose one anchor definition and keep it identical across runs:
      • incident date, or
      • discovery date, or
      • filing date (or whatever you used originally).
    • If you’re using DocketMath via /tools/damages-allocation, mirror the same date fields between runs.
  3. Freeze the amounts

    • Keep the total dollar amount(s) constant.
    • Only adjust date inputs or the way dates are entered (e.g., lump sum vs. itemized).
  4. Compare outputs category-by-category

    • When the tool outputs multiple allocated components, check which component changes first.
    • If the difference is concentrated in the time-filtered portion, it’s a strong indicator that the SOL boundary interaction is driving the result.
  5. Confirm you’re truly using the general/default SOL

    • Your setup uses Utah’s general 4-year period under Utah Code § 76-1-302 (no claim-type-specific sub-rule found).
    • In practice, that means differences likely trace back to what portion of the claimed losses lands inside vs. outside the 4-year window.

To rerun and verify, start at: /tools/damages-allocation

Gentle note: This is a diagnostic walkthrough of tool math and timing inputs—not legal advice.

Next steps

  1. Create a side-by-side run log

    • Record:
      • the timeline anchor you used,
      • the earliest and latest dates entered,
      • and the total amounts by category (especially if your inputs are itemized).
  2. Do a “boundary test”

    • If the discrepancy is meaningful, test dates around the cutoff:
      • move the start date forward/back by 30–90 days
      • and rerun each time.
    • This helps confirm whether SOL filtering is the dominant driver.
  3. Itemize only the high-impact portions

    • If you have a lump sum and the discrepancy is large, itemize portions near the 4-year boundary.
    • That usually stabilizes interpretation and reveals which losses are actually driving the allocation.
  4. Report results using Utah’s general SOL baseline

Related reading