Spreadsheet checks before running Wage Backpay in Wyoming
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Wage Backpay calculator.
Before you run DocketMath’s Wage Backpay calculation for a Wyoming wage matter, you want your spreadsheet to survive the most common “silent failure” scenarios: missing assumptions, wrong date math, and mis-scoped time windows.
This Wyoming-focused spreadsheet checker helps validate that your inputs align with the general statute of limitations (SOL) window Wyoming uses for these purposes. It’s designed to catch logic problems before you trust the final Wage Backpay number.
Wyoming rule the checker uses (default)
Wyoming’s general SOL period is 4 years, under:
- Wyo. Stat. § 1-3-105(a)(iv)(C)
(General/default period: 4 years)
Note: No claim-type-specific sub-rule was found in the materials available for this checker. That means this tool applies the general/default 4-year period rather than a special, claim-specific timing rule. If you’re dealing with a situation that may have a different timing standard, you should independently confirm that before relying on this “default 4-year” window.
Spreadsheet issues it flags
Use the checklist below to understand what the checker catches before any calculation output is generated.
Start date blank (e.g., employment start or the beginning of the unpaid period)
End date blank (e.g., last day worked, pay period cutoff, filing date)
“Start date” occurring after “end date”
Your sheet looks like it’s calculating backpay for more than 4 years
Your sheet calculates from a date that isn’t clearly tied to a SOL cut-off
Your spreadsheet includes a “SOL date” (or cut-off/as-of) column, but the formula isn’t consistent across rows
The cut-off date is present but not actually used to truncate hours/wages
Hours/wages after the SOL cut-off are still included
Some pay periods are truncated while others are not (often due to inconsistent “inside/outside window” logic)
Hours entered as minutes (or vice versa)
Pay rate stored in the wrong unit (e.g., an hourly rate entered as a percentage like “15” instead of “15.00” dollars/hour)
The sheet has overlapping pay periods that double-count time
Dates stored as text (common when copied from PDF/Excel exports)
Numeric values stored as strings, causing subtraction or multiplication to fail silently
What the output tells you
When you run the checker, it should produce two practical outputs you can act on immediately:
- A SOL compliance summary
- Whether your backpay window appears to stay within 4 years from the relevant reference date you entered (the “lookback anchor”).
- A list of cells/rows that need correction
- For example: “Rows covering pay periods after the SOL cut-off are included—truncate or exclude them.”
The key benefit: you catch spreadsheet logic problems before you rely on the final Wage Backpay output.
When to run it
Run the checker at two decision points—not only once at the end.
Run the checker before importing a spreadsheet into the Wage Backpay workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
1) Immediately before running the Wage Backpay calculation
If you start with a payroll import, a manually typed pay-period table, or a timeline from a document, date issues are almost always present. The checker is built to stop those issues at the source.
Best practice timing
- Run the checker right after you finish your:
- pay-period rows (dates + hours)
- wage/rate column(s)
- any computed totals
2) After every major edit to the date logic
Even small spreadsheet changes can affect SOL truncation.
Examples that should trigger reruns:
- You changed the SOL cut-off date or “as of” date
- You added a new pay period near the boundary of the 4-year lookback
- You restructured columns (e.g., renamed “Pay Period End” to “Period End Date”)
The reference date you enter matters
Wyoming’s general SOL period is 4 years under Wyo. Stat. § 1-3-105(a)(iv)(C). The checker can only confirm compliance relative to the reference date you use in your spreadsheet workflow (commonly the date you choose as the anchor for the modeled “4-year lookback”).
So, before you run the checker:
- Confirm which date in your spreadsheet represents the “lookback anchor”
- Ensure every pay period row is evaluated against the same anchor
(Gentle reminder: this is a spreadsheet logic check using the default 4-year rule. It isn’t a substitute for legal advice or case-specific analysis.)
Try the checker
You can try this workflow directly through DocketMath’s Wage Backpay tools:
- Open DocketMath’s Wage Backpay page:
/tools/wage-backpay - Add your spreadsheet data to the Wage Backpay inputs.
- Run the spreadsheet checks first (the checker step).
- Fix any flagged rows and rerun Wage Backpay to confirm the output changes.
Understand the inputs (and how output changes)
Keeping inputs consistent across runs reduces the chance that the checker and the calculator disagree.
| Input you enter | What the checker expects | What happens if it’s wrong |
|---|---|---|
| Pay period start/end dates | Valid date values (not text) | Rows may be misclassified as inside/outside the 4-year window |
| Hours worked | Numeric hours per period | Totals may be overstated or understated |
| Pay rate (hourly or equivalent) | Numeric rate | Backpay math may fail or compute incorrectly |
| SOL lookback anchor date | One clearly defined “4-year window” anchor | Truncation logic can include the wrong periods |
Quick sanity checks you can do before running
These are small, fast checks that reduce friction:
- If it’s beyond the SOL cut-off, it should be excluded or truncated consistently
If your goal is to see how SOL-related logic is handled in practice, revisit the Wage Backpay workflow here: /tools/wage-backpay.