Why Wage Backpay results differ in Missouri
5 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
If you run a wage backpay calculation in Missouri with DocketMath, the number you see can diverge for reasons that are usually fixable—especially once you isolate the inputs that govern the Missouri general statute of limitations (SOL) window.
Missouri generally uses a 5-year SOL period for this type of limitation analysis under the provided jurisdiction data. The general statute is Mo. Rev. Stat. § 556.037. Based on the jurisdiction data provided, no claim-type-specific sub-rule was found, so treat 5 years as the default/general rule for determining the backpay “lookback” window unless your fact pattern clearly indicates a different limitations rule.
Here are the top five reasons wage backpay results differ:
Different “lookback” dates
- DocketMath constrains recoverable time by the SOL window you enter/enable.
- If one run effectively uses an “incident date” and another uses a “filing/notice date,” the recoverable period can shift by months—or even years.
Accrual dates vs. pay-period dates
- Backpay is often calculated by pay periods.
- If the start of the calculation is set to the first missed payroll in one run, but the first day of nonpayment in another, the model may include or exclude a different set of pay periods.
Wrong baseline compensation inputs
- Outputs vary when the wage inputs don’t match what your scenario is modeling.
- Examples: hourly vs. salary framing, base pay vs. base + guaranteed hours, and whether overtime is included.
- Even small differences in the “regular wage” assumptions can compound over many pay periods.
**Offsets/mitigation handling differs (or is inconsistent)
- If one calculation nets interim earnings (or other offsets) and another does not—or if the offset timing differs—totals can change materially.
- The mismatch might be per pay period versus annual/lump-sum assumptions.
Calendar math and partial periods
- A 5-year limit interacting with calendar boundaries can create edge-case differences.
- A one-pay-period shift can move a segment inside vs. outside the allowable window, especially near the SOL cutoff date.
Practical note (not legal advice): DocketMath can only calculate what you enter. Two runs can look “about the same story,” yet differ because the SOL start/end dates, pay-period alignment, compensation basis, or offset method are not mapped identically.
How to isolate the variable
To find why results differ, run comparisons that change only one variable at a time, and compare the output components—not just the final total.
- Freeze the jurisdiction and tool settings so both runs use the same rule set.
- Compare one input at a time (dates, rates, amounts) and re-run after each change.
- Review the breakdown to see which segment or assumption drives the difference.
Step-by-step isolation approach
Lock the SOL-limiting dates
- Keep constant across runs:
- The date used to start the SOL lookback window
- The date used to end the unpaid-wage calculation period
- For Missouri, use the 5-year default/general rule tied to Mo. Rev. Stat. § 556.037 (based on the provided jurisdiction data).
Keep compensation inputs identical
- Match exactly:
- Hourly rate vs. salary basis
- Scheduled hours / full-time equivalency assumptions
- Whether overtime is included in the wage-backpay model
Confirm pay-period granularity
- Make sure both runs use the same pay frequency structure (weekly, biweekly, etc.).
- If pay period grouping differs, you can inadvertently include different portions of the same calendar dates.
Hold the offsets approach constant
- Choose one approach per run and keep it consistent:
- No offsets
- Offsets applied per pay period
- Offsets applied as a lump sum
- The goal is diagnostic clarity: identify what changes the output, not just which total “feels right.”
Quick diagnostics table
| Potential variable | What to change between runs | Expected output impact |
|---|---|---|
| SOL lookback start date | Shift by ~30–365 days while keeping everything else fixed | Biggest swing if near the 5-year boundary |
| Accrual vs. payroll date | Switch the start reference to first missed payroll vs. first nonpayment date | Medium-to-large change |
| Baseline wage rate | Change hourly/salary baseline to match the scenario | Linear change; multiplies across pay periods |
| Overtime policy | Toggle overtime included/excluded | Large if overtime-heavy |
| Offsets/mitigation handling | Apply offsets vs. don’t apply; change timing method | Can materially reduce totals |
If you want to reproduce your own comparisons, use DocketMath’s wage-backpay tool: /tools/wage-backpay.
Next steps
**Write down your exact inputs (a checklist helps)
- SOL lookback start date (Missouri default: 5 years under Mo. Rev. Stat. § 556.037 as provided)
- SOL/window end date
- Pay frequency (weekly/biweekly/etc.)
- Wage-rate model (base-only vs. base + overtime, if you’re including it)
- Offsets method (none / per pay period / lump sum)
Run three targeted scenarios
- Scenario A: earliest plausible lookback date
- Scenario B: latest plausible lookback date
- Scenario C: use the same lookback as B, but verify wage-rate and pay-period alignment
Identify the “first divergence”
- Look for the earliest pay period where the included/unincluded status changes between runs.
- That’s typically where the mapping error (date boundary, payroll alignment, or offsets policy) occurred.
Sanity-check with internal logic
- Does the implied number of unpaid pay periods match your timeline?
- If DocketMath shows unexpectedly low/unpaid totals, re-check date alignment and pay-period granularity before adjusting wage rates.
Gentle reminder: this is a calculation diagnostic, not legal advice. If your fact pattern involves a different limitations theory than the provided “general/default” period, you’ll need to adjust the SOL logic accordingly.