Spreadsheet checks before running Damages Allocation in Utah

What the checker catches

Running a Damages Allocation spreadsheet in Utah is usually less about getting the arithmetic right and more about avoiding timing and scope mistakes before you allocate anything. DocketMath’s damages-allocation calculator can produce neat outputs—but those outputs can still be based on claims that may be time-barred under Utah’s general statute of limitations.

This spreadsheet checker is designed to flag four common problems before you run allocations:

• **Statute of limitations (SOL) exposure (Utah general rule)

  • Utah’s general SOL period is 4 years under Utah Code § 76-1-302.
  • No claim-type-specific sub-rule was found for this workflow, so this checker applies the general/default 4-year period as the baseline (it does not swap in different periods by claim category).

• Date field mismatches

  • A frequent spreadsheet failure mode isn’t the wrong statute—it’s inconsistent date inputs, such as using an “incident” date for one line item and a “filing” or “measurement” date for another.
  • The checker looks for patterns like:

    • Allocation start date after allocation end date
    • Missing “trigger” date (blank cell where a date is expected)
    • Accidentally entered text in a date column (e.g., 03/15/24 stored as text instead of a real date)

• Unit and quantity issues that distort allocation

  • If your model allocates by days, hours, units, or similar quantities, the checker verifies that the quantity basis is consistent across rows.
  • Examples it catches:

    • Days = 0 on lines that still have a dollar amount
    • Units populated while rate columns are empty
    • Percent allocations that do not sum as expected (e.g., not totaling 100% when your model assumes full allocation)

• Cross-row copying errors

  • Spreadsheets often replicate formulas down a column; that can silently copy the wrong logic for a row.
  • The checker watches for repetition patterns suggesting copy/paste drift, such as:

    • “Magic numbers” (like the same date) repeating across distinct events where each row should reference a different date

When to run it

Don’t wait until after you’ve allocated—run the checker at three stages:

1. Before the first allocation run

   • Use it right after you enter:

     • the relevant date(s) per row
     • the filing date (or the date you’re measuring from)
     • the damages basis (rates, quantities, or per-period amounts)

2. After any major edit to date logic

   • If you change what your spreadsheet treats as the “trigger” date (for example, switching from “incident date” to “discovery date”), rerun immediately.
   • Date logic changes are one of the fastest ways to create silent errors.

3. Before export or presentation

   • Run the checker again right before you:

     • export a PDF
     • share the worksheet with a team
     • attach numbers to a filing workflow
   • This catches last-mile issues like blank date cells or percent totals that stopped adding up.

Utah timing baseline the checker uses (general rule)

For this Utah workflow, the checker applies the general SOL period of 4 years from Utah Code § 76-1-302.

Source context (Utah courts’ general statute limitation reference):
https://www.utcourts.gov/en/legal-help/legal-help/procedures/statute-limitation.html

Because no claim-type-specific sub-rule was identified, the checker does not apply different SOL periods by category. Instead, it uses the 4-year general/default period as the baseline for exposure screening.

Note: This is an accuracy-checking tool for spreadsheet inputs and general exposure screening—not legal advice.

Try the checker

To try this workflow with DocketMath, start with the Damages Allocation tool and then run the spreadsheet checker that validates inputs and flags potential SOL exposure.

You can launch the primary tool directly here: **/tools/damages-allocation

If you’re building from scratch, a practical sequence is:

1) Confirm your date columns

Use consistent date fields across all rows:

• Event/trigger date: the date associated with each claimed item
• Measurement date: the date you compare against for SOL exposure (commonly your filing/measurement date in a damages workflow)
• Row-level notes (optional): useful if you’re reconciling why one row uses a different trigger concept

2) Confirm your allocation basis

Choose one model and keep it consistent:

• Per-period allocation (e.g., monthly or daily)
• Rate × quantity allocation (e.g., $/unit × units)
• Percent allocation (e.g., split total across categories)

Then verify that for each row your spreadsheet contains:

• quantity (or days/periods) and
• a rate (or a percent basis and the total that the percent applies to)

3) Run the checker and interpret results

After running damages-allocation in DocketMath, the checker will focus on:

• SOL timing flags using the 4-year general rule under Utah Code § 76-1-302
• date consistency across rows
• allocation consistency (units/percent/rate completeness)

A helpful workflow for reviewing results is to sort flagged rows to the top, then address issues in this order:

1. Fix missing or malformed dates
2. Fix trigger vs measurement date directionality
3. Fix units/rate completeness
4. If needed, re-check whether you need to adjust the allocation basis itself

Quick checklist (copy-friendly)

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