Spreadsheet checks before running Wage Backpay in Missouri
6 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 Wage Backpay in Missouri with DocketMath, use a spreadsheet-first checklist to catch the issues that most often break a backpay calculation: incorrect time windows, missing sign/offset logic, and data gaps that can quietly skew totals.
This Missouri-focused spreadsheet checker validates your inputs against the general/default statute of limitations (SOL) rule used for this tool. For Missouri, the governing general/default SOL period is:
- 5 years (general/default) under Mo. Rev. Stat. § 556.037
Note: In the provided jurisdiction data, no claim-type-specific sub-rule was found. That means the checker applies the default 5-year period consistently rather than trying to branch into special SOL rules.
Common spreadsheet problems the checker helps you detect
Use the checklist below to review your wage backpay spreadsheet before you run DocketMath Wage Backpay.
If your spreadsheet totals include periods older than 5 years back from your relevant “start anchor” date, your results can be overstated.
Rows that span multiple pay cycles sometimes carry inconsistent end dates, producing uneven day counts.
If hourly logs roll up into weekly/monthly totals, confirm each row reflects the correct coverage period. Mixing boundaries is a common source of drift.
Backpay calculations often depend on expected hours and actual paid hours. Your spreadsheet should keep these as separate columns and aggregate them consistently.
Offsets, partial settlements, or credits can flip the math if the sign is wrong. DocketMath can only be as accurate as your dataset—if credits are stored as positive when the checker expects negatives (or vice versa), totals can reverse.
Rounding per row can drift totals. Decide whether you round at the row level or only after final aggregation, and keep that choice consistent.
If your spreadsheet separates “regular pay” from “overtime/other,” totals should preserve that separation so effective rates aren’t overwritten or blended incorrectly.
If you leave blank rows for days without work, confirm whether your formulas treat them as zeros or as missing values that break sums.
Duplicate pay periods are a frequent cause of inflated backpay. Use a unique key per pay period (for example: employee ID + pay period end date) and ensure each key appears once.
Quick “inputs → outputs” sensitivity table
This is where the spreadsheet checks make a difference in what DocketMath calculates:
| Spreadsheet field | What it drives in DocketMath | What can go wrong |
|---|---|---|
| Start anchor date for the SOL window | Which rows fall inside the 5-year window | Including older wages inflates totals |
| Pay period end date per row | Alignment of time coverage | Mixed end dates shift day counts |
| Expected hours / expected rate | “Should have been paid” baseline | Omitting expected hours underestimates damages |
| Actual hours / actual earnings | “Was paid” baseline | Using net amounts instead of gross wages can distort offsets |
| Offset/credit column (if used) | Net backpay after credits | Sign errors reverse credits into add-backs |
Gentle note: This is a tooling/data sanity check, not legal advice. If your situation has complexities (for example, unusual pay structures), consider verifying your approach with a qualified professional.
When to run it
Run the spreadsheet checker at the moments when errors are most likely—and easiest to fix.
Recommended sequence (Missouri)
Before you assemble the dataset
- Confirm the spreadsheet structure: columns for pay period, expected wages, actual wages, and (if applicable) credits/offsets.
After you import payroll/time records
- Use the checker to validate date coverage and detect duplicates or missing pay periods.
Right before you run DocketMath Wage Backpay
- At this point, you want to avoid “recalculating” after discovering that your SOL window is wrong or your sign logic is inconsistent.
What the 5-year rule means for your dates
Missouri’s general/default SOL period for this analysis is 5 years under Mo. Rev. Stat. § 556.037. Practically, that means:
- You should set a start anchor date and ensure your spreadsheet only feeds the portion that falls within the 5-year lookback window.
- If your dataset includes earlier periods, remove them or clearly segregate them so the calculation isn’t accidentally mixing outside-window rows.
Warning: If you apply the 5-year lookback inconsistently—filtering some columns/rows but not others—you can end up with totals that “look reasonable” but don’t match the intended window.
Try the checker
You can run DocketMath Wage Backpay with Missouri jurisdiction-aware rules here: /tools/wage-backpay.
Before you press calculate, use this tight pre-flight checklist:
If you want, paste a summary of your column names and the date fields you’re using, and you can use that to align your spreadsheet so the checker logic can validate it cleanly.
Related reading
What the checker catches
- Date ordering problems (end date before start date).
- Rates entered as whole numbers instead of percentages.
- Missing caps or discounts in the spreadsheet.
- Inconsistent rounding or day-count conventions.
If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.
When to run it
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.
If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.
Try the checker
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
When rules change, rerun the calculation with updated inputs and store the revision in the matter record.
If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.