Spreadsheet checks before running Wage Backpay in Utah
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Wage Backpay calculator.
DocketMath’s wage-backpay calculator is designed to help you catch spreadsheet issues before you calculate Utah wage backpay. For Utah (US-UT), the most common failure mode isn’t arithmetic—it’s that the spreadsheet’s date logic (and any inputs derived from those dates) quietly causes the statute-of-limitations filter to include too much or too little.
Before you run the calculator, this checker validates the items that most directly affect the final “recoverable” amount:
Statute-of-limitations date window
- Utah has a general statute of limitations of 4 years for many civil actions, governed by Utah Code § 76-1-302.
- Important: In the jurisdiction data provided, no wage-backpay-specific sub-rule was found. So this checker applies the general/default 4-year period as the baseline filter (and does not assume a shorter or special carve-out).
Accurate start/end dates
- Confirms your spreadsheet is using valid date values (not text).
- Ensures the earliest and latest dates you intend to include are actually being read correctly by the sheet logic.
Off-by-one coverage
- Looks for boundary logic problems (for example, accidentally using “greater than” when “greater than or equal to” is what you meant).
- This matters because a one-day boundary error can change the recoverable amount for periods that partially fall within the window.
Negative or inconsistent day counts
- Flags situations where:
- an “end date” is earlier than a “start date”
- your derived “days owed” (or similar) column doesn’t match the date difference implied by your start/end dates
Rate/amount mismatches
- Checks whether your inputs are aligned in the way the calculation expects, such as:
- hourly vs. daily rate
- gross vs. net amounts (or other wage bases you intend to treat as “wages”)
- Even if the math runs, the output can look reasonable while being anchored to the wrong unit basis.
Overlapping line items
- Helps spot duplicate or overlapping date ranges across rows (e.g., multiple entries covering the same dates) that can inflate totals by counting the same coverage twice.
Gentle note: This checker focuses on spreadsheet hygiene and jurisdiction-aware date filtering. It is not legal advice, and it can’t replace reviewing Utah Code § 76-1-302 and any case-specific details that may affect how your facts should be treated.
Utah limits the time window to 4 years (general/default)
For US-UT, the checker uses Utah’s general SOL of 4 years under Utah Code § 76-1-302.
Because no wage-backpay-specific exception was found in the provided jurisdiction data, the checker treats the 4-year general/default period as the practical baseline.
Source for Utah’s statute limitation overview:
https://www.utcourts.gov/en/legal-help/legal-help/procedures/statute-limitation.html
When to run it
Run the checker immediately before you run the wage-backpay calculation in DocketMath. In a spreadsheet workflow, that typically means:
- After you finalize your spreadsheet’s date columns
- Before you calculate totals you’ll treat as final recoverable amounts
- Right after you update the “as of” / cutoff date that determines which wages fall inside the recoverable window
A practical workflow that reduces rework
- Prepare inputs (start/end dates, pay rates, wage amounts, and any pre-calculated “days owed”/hours columns).
- Run the spreadsheet checker.
- Fix anything the checker flags (especially anything involving date parsing, boundary logic, or negative day counts).
- Run DocketMath wage-backpay.
- Re-check totals only after corrected inputs produce a stable window.
What to review in your sheet (quick pre-flight)
Use this as a short checklist while the calculator is ready:
Try the checker
To run DocketMath’s wage-backpay workflow for Utah, open: /tools/wage-backpay.
If you’re building or cleaning a spreadsheet, keep these inputs in mind—your outputs can change significantly based on them:
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
Key inputs the checker cares about (Utah-aware)
- Cutoff / analysis end date
- Used to determine which wages fall inside the 4-year general window under Utah Code § 76-1-302
- **Work periods (start/end dates)
- Each work period is filtered against the 4-year window
- Compensation basis
- How hourly (or other derived) wage calculations are interpreted
- Whether your entered amounts are consistent with the wage basis you intend to backpay
How output changes when inputs are fixed
After correcting issues the checker catches, you’ll typically see one of these outcomes:
| Spreadsheet issue caught | Example symptom | Likely output effect |
|---|---|---|
| Dates stored as text | Checker flags invalid date parsing | Fewer rows qualify—or filtering fails more broadly |
| Boundary off-by-one | Period that should partially qualify gets excluded | Recoverable amount shifts by about one day of wages |
| End date earlier than start date | Negative day count or weird zeros | Totals show unexpected negatives, zeros, or undercounting |
| Overlapping date ranges | Duplicate coverage across rows | Backpay inflates due to double-counting |
| Wrong unit basis | Hourly entered where daily is expected (or vice versa) | Result scales incorrectly even if totals “seem” consistent |
Warning: If you rely on pre-calculated “days owed” or “hours owed,” a date error can propagate. Even if the checker only flags date formatting issues, downstream totals can still be wrong in ways that are difficult to spot manually.
Minimal setup tip
If your spreadsheet has multiple tabs or merges data from separate sources:
- Consolidate the final run sheet first (the sheet you’ll actually calculate from).
- Then run the checker on that single tab, so you fix the underlying date issue in one place.