Spreadsheet checks before running Closing Cost in Utah

6 min read

Published April 15, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

What the checker catches

Run this scenario in DocketMath using the Closing Cost calculator.

Before you run a Closing Cost calculation for a Utah matter in DocketMath, you can reduce spreadsheet errors by validating key inputs and assumptions first. This is especially helpful when you’re working from partial facts (for example, missing dates or unclear ownership status), because DocketMath’s closing-cost calculator will produce an output based on whatever is currently in your sheet.

The goal of this Utah-focused spreadsheet checker is to catch the kinds of issues that don’t always throw a spreadsheet error—they can produce results that look plausible but are internally inconsistent.

Here’s what the checker should validate before you proceed to /tools/closing-cost:

Date gaps that break Utah’s statute limitations analysis
- Utah uses a general/default statute of limitations (SOL) period of 4 years under Utah Code § 76-1-302 (and, importantly, no claim-type-specific sub-rule was found in the provided jurisdiction data).
- If your spreadsheet includes a “start date” and “end date” that are reversed, blank, or inconsistent, timing logic can quietly fail.
- The checker should confirm:
  
  you have a populated event date (or the closest equivalent date your sheet uses)
  
  you have an as-of date
  
  the event date is not after the as-of date
Non-boolean flags entered as text
- Many workflows rely on yes/no inputs. Common spreadsheet mistakes include writing TRUE/FALSE as Yes/No, or mixing casing like true, True, FALSE, etc.
- The checker should confirm these flags are boolean (true/false) and that your sheet maps them consistently to the calculator’s expected meaning.
Currency/amount fields accidentally stored as strings
- Values like $1,250.00 can become text in Excel/Sheets depending on how they were entered or imported.
- When amounts are stored as strings, some formulas may treat them as zero, fail silently, or behave unpredictably.
- The checker should confirm:
  
  fee/amount inputs are numeric
  
  currency formatting doesn’t break computation
  
  decimals follow the convention your model expects (for example, two decimal places—if that’s how your sheet is designed)
**Unit mismatches (percent vs decimal, or frequency mismatches)
- Closing-cost models often mix values such as:
  
  percentages (0.03) vs percent-style entries (3)
  
  per-day vs per-month rates
  
  amounts that may or may not include tax (depending on how your inputs are defined)
- The checker should look for “unit smell” patterns, such as:
  
  a percentage column containing 25 when your sheet expects 0.25
  
  a rate column with values that are orders of magnitude larger/smaller than expected given your scenario
- A practical rule: if any rate/percentage input appears “too large” relative to the expected scale, flag it for review.
**Missing row alignment (the quietest failure mode)
- Sometimes spreadsheets don’t break—they just calculate from the wrong row.
- For example, fee categories might be in one row while their numeric inputs or referenced amounts are in another row, leading the model to compute using mis-matched data.
- The checker should confirm that each fee category is paired with the correct amount/rate inputs on the same logical record.

Warning (Utah timing matters): Timing errors are often harder to notice than arithmetic errors. Because the Utah general/default SOL period is 4 years under Utah Code § 76-1-302, a spreadsheet that omits or misorders dates can quietly invalidate the scenario logic even if the math “looks right.” This checker is meant to prevent that class of silent error.

For the statute-limitation reference Utah courts provide, see:
https://www.utcourts.gov/en/legal-help/legal-help/procedures/statute-limitation.html

(Gentle note: this is a workflow check to reduce spreadsheet mistakes; it isn’t legal advice.)

When to run it

Run the checker at two decision points: (1) before you compute, and (2) after you update your sheet. That gives you the best chance to fix input problems early—before they affect the output.

Run the checker before importing a spreadsheet into the Closing Cost workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.

1) Before running DocketMath’s calculator

Use the checker immediately after you finish entering or importing values and before you go to /tools/closing-cost.

Recommended checklist order:

Confirm required fields are present (especially event date and as-of date).
Normalize boolean flags into true/false.
Confirm numeric formats for amounts and rates.
Validate unit conventions (percent scale, rate frequency).
Confirm row alignment for fee categories and their inputs.

2) After you refresh dates or recalculate formulas

Rerun the checker anytime you:

update any dates
copy/paste rows
import a CSV
adjust formulas or cell references

Spreadsheet recalculation can reintroduce errors through:

broken references
stale ranges
unintended overwrites

Utah-specific SOL rule your sheet should treat as the baseline

Encode this directly in your workbook logic (and in your checker expectations):

Utah’s general/default SOL period is 4 years under Utah Code § 76-1-302.
The jurisdiction data indicates no claim-type-specific sub-rule was found, so your checker should not attempt to swap in different SOL windows by scenario type.
In other words, treat the 4-year default as the baseline assumption unless your sheet has an explicitly supported alternative.

(Again: this is an implementation guidance point for your spreadsheet logic, not legal advice.)

Try the checker

You can test the workflow end-to-end using DocketMath’s Closing Cost tool at:

/tools/closing-cost

A practical way to validate the value of the checker:

Open /tools/closing-cost.
Paste or map your spreadsheet values into DocketMath’s required inputs.
Run your spreadsheet checker routine first, focusing on:
- missing dates
- reversed date order
- text amounts
- percentage/decimal scale mismatch
- incorrect boolean formatting

If you want a quick “fast path,” validate these 5 categories first:

Event date (or closest proxy date)
As-of date
All fee amounts (numeric only)
Any rates/percentages (confirm the expected scale)
Any scenario flags (boolean true/false)

Once those pass, run the closing-cost calculation and then re-check:

whether the output changed after edits
whether the output changed by the same delta you expect from your edits

Minimal sanity test (highly effective):

Increase a fee input by $100.
- Does the closing cost increase by roughly $100 (or by the exact modeled multiplier your sheet implies)?
Change the as-of date by +1 year.
- Does any time-based component shift in the direction your model expects?

If behavior doesn’t match your expectations, rerun the checker before assuming the calculator is wrong. This is where date ordering problems, unit mismatches, and text-vs-number issues typically surface.

(Gentle disclaimer: a checker helps catch spreadsheet inconsistencies, but it can’t guarantee correctness in every legal scenario.)