Spreadsheet checks before running Wage Backpay in Michigan

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 Michigan with DocketMath, use a spreadsheet-first sanity check to prevent the most common “garbage in, garbage out” problems. This checker is designed for jurisdiction-aware review using Michigan’s general statute of limitations (SOL) period.

  • General SOL period: 6 years
  • Governing statute (Michigan): MCL § 767.24(1)
  • Important clarification: For this workflow, the 6-year period is treated as the default/general rule. No claim-type-specific sub-rule was found, so you should not assume a different SOL applies here until you confirm the specifics for your situation.

Here’s what the checker catches in your spreadsheet before you calculate backpay:

1) Missing or inconsistent “lookback” dates

Your spreadsheet should include (at minimum):

  • Work period start date (earliest time employees claim is owed)
  • Work period end date (latest time claimed)
  • Filing date (or the date you’re using as the SOL anchor for your workflow)

The checker verifies that your dates create a consistent timeline and that you’re applying the 6-year general lookback under MCL § 767.24(1).

Note: This checker uses the general/default 6-year period under MCL § 767.24(1). If you later determine a claim-specific rule overrides the default, update your worksheet logic accordingly.

2) Accidental time-zone/format drift

Date columns are a frequent source of spreadsheet errors—especially when data is imported from payroll systems.

The checker flags issues like:

  • Text-formatted dates (e.g., dates stored as strings instead of real date values)
  • Empty date cells in critical rows
  • Mixed date formats across tabs (for example, one sheet uses MM/DD/YYYY while another uses YYYY-MM-DD)

These problems can make a period look “inside” or “outside” the SOL window when it isn’t—without triggering an obvious calculation error.

3) Hour and rate mismatches

Backpay math typically depends on clean, consistent base inputs. The checker detects common mismatches such as:

  • Totals that don’t reconcile with underlying line items
  • Negative hours (often caused by sign conventions or duplicated corrections)
  • Rates that don’t align with your pay-period structure (for example, combining weekly hours with a non-weekly rate assumption)

To get stable results, ensure the units your sheet uses (hours, pay frequency, wage rate) are internally consistent before you run /tools/wage-backpay.

4) Duplicate or overlapping periods

If your spreadsheet imports from payroll exports, it’s easy to double-count time.

The checker highlights:

  • Overlapping work periods
  • Duplicate rows created by copy/paste or repeated imports
  • Gaps that break “continuous coverage” assumptions (when your later logic assumes continuity)

This is especially important when later you subtotal “included” vs. “excluded” periods—overlaps can inflate totals even if each individual row looks reasonable.

5) SOL-truncated line items (the biggest “spreadsheet gotcha”)

Once your dates are consistent, the checker estimates which portions fall outside the 6-year general SOL window.

That typically impacts whether you:

  • Exclude certain pay periods entirely, or
  • Keep them for audit trail but mark them as “not included for SOL purposes.”

Even if you later adjust your inclusion rule, this step helps prevent silent inclusion of time that your timeline indicates may be SOL-barred under the general rule in MCL § 767.24(1).

Gentle disclaimer: This tool and walkthrough are for spreadsheet quality control, not legal advice. SOL application can depend on facts and procedural posture that vary by case.

When to run it

Run the checker early, before you finalize inputs and before you trust computed totals.

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.

Best timing in a typical workflow

A practical order of operations:

  1. Populate dates and pay-period rows
  2. Run the spreadsheet checks for structure and reconciliation
  3. Run DocketMath Wage Backpay only after your date logic and totals look clean
    • Use the tool here: /tools/wage-backpay
  4. Re-check after imports/edits
    • Payroll exports
    • Corrected wage tables
    • Updated filing dates (or anchor dates)

Practical trigger checklist (run it when you…)

  • Imported data from a CSV and date formats might have changed
  • Updated the filing date or the anchor date for calculations
  • Edited hours, rates, or pay frequency assumptions
  • Changed how you group work periods (weekly vs. pay cycle)

What the output should tell you

You want the checker to produce a short list of:

  • Rows/periods to review
  • Date inconsistencies
  • Reconciliation warnings (totals don’t match subtotals)
  • SOL inclusion/exclusion flags based on the 6-year general rule under **MCL § 767.24(1)

Warning: If you run /tools/wage-backpay before resolving date-format issues, the output may look confident while being driven by a malformed timeline.

Try the checker

Start with DocketMath’s Wage Backpay tool: /tools/wage-backpay. The goal is not only to compute totals, but to ensure your spreadsheet inputs align with Michigan’s general 6-year SOL framework under MCL § 767.24(1).

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Suggested spreadsheet setup (minimal but reliable)

Use columns like:

ColumnExample entryUsed for
Employee / record IDEMP-1042Traceability
Work period start2021-03-01Timeline boundaries
Work period end2021-03-15Timeline boundaries
Hours worked80.00Backpay base
Wage rate15.50Backpay base
Filing date (anchor)2024-06-10SOL lookback
Included for SOL reviewYes/NoInclusion flags
NotesPayroll export importAudit trail

How inputs change the output

When you run /tools/wage-backpay, small input changes often cause big downstream effects. The checker helps you understand those relationships:

  • Change filing date → SOL lookback window shifts → different periods get flagged as included/excluded
  • Change work period start/end → borderline inclusion switches → total backpay changes
  • Fix hour/rate mismatches → underpayment amounts change, even if dates stay the same
  • Resolve duplicates/overlaps → totals become less inflated and more stable across recalculations

Use DocketMath as the “second set of eyes”

Once your sheet passes basic date and reconciliation checks:

  • Run /tools/wage-backpay
  • Compare its totals to your sheet’s subtotal logic
  • Investigate large deltas using the checker’s flagged rows/periods

That sequence makes troubleshooting faster: first validate structure, then validate computations.

Related reading