Spreadsheet checks before running Wage Backpay in Maine

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 Wage Backpay in Maine (US-ME) with DocketMath, it’s worth doing a quick spreadsheet check. In this workflow, small date or data issues can quietly change the statute of limitations (SOL) backpay window—and that can affect which pay periods get included.

This spreadsheet checker is designed to catch the kinds of problems that commonly come from inconsistent date handling, blank inputs, and mismatched spreadsheet assumptions. It doesn’t replace legal analysis, but it helps you avoid avoidable calculation errors.

Here are the categories it’s designed to catch:

  • Missing or inconsistent start/end dates

    • Common issue: you enter an “incident date” in one row, but the calculation expects a “work performed through” date in another.
    • Result: the checker flags mismatched or blank dates so your backpay window doesn’t collapse to an incorrect period.
  • Date format problems

    • Examples: dates stored as text ("03/01/2024") vs. actual dates, or mixed formats (MM/DD/YYYY and DD/MM/YYYY).
    • Result: it helps prevent silent failures where Excel/Sheets interprets dates inconsistently.
  • Backpay window that unintentionally exceeds Maine’s general SOL

    • DocketMath’s Maine default uses the general/default SOL period:
      • General SOL period: 0.5 years (6 months)
      • General statute: Title 17-A, § 8
    • Important (as stated in the jurisdiction data provided): no claim-type-specific sub-rule was found. So the checker applies the general/default period rather than any specialized carve-out.
    • Result: if your spreadsheet dates imply a window longer than that default period, the checker highlights the discrepancy before you proceed.
  • Accidentally inverted date ranges

    • Example: start date after end date.
    • Result: the checker flags the ordering so you don’t end up with negative or nonsensical durations.
  • Blank wage fields or duplicated rows

    • Wage Backpay totals are sensitive to whether each pay-period row has the needed numeric inputs.
    • Result: the checker points out empty wage entries, duplicate periods, or rows that don’t line up with your pay-cycle structure.
  • Spreadsheet rounding drift

    • Inputs that are rounded inconsistently (e.g., hourly rates rounded to 2 decimals while hours use whole units).
    • Result: the checker warns you to standardize rounding rules so totals match between your spreadsheet and DocketMath.

Warning: Don’t rely on totals alone. A sheet can “sum correctly” while still using the wrong date columns or the wrong SOL window. That’s exactly what this checker is meant to prevent.

When to run it

Run the checker right before you calculate Wage Backpay in DocketMath—ideally immediately after you paste or import spreadsheet data.

A practical workflow:

  1. Build your pay-period table first

    • Each row should represent a consistent unit (commonly a pay period).
    • Make sure every row includes the date fields your calculation will reference.
  2. Standardize the date columns

    • Keep one canonical from/start column and one canonical through/end column.
    • Avoid mixing derived dates (formulas) and manually entered dates without checking formatting.
  3. Run the spreadsheet checker

    • Validate:
      • date presence and ordering
      • date format consistency
      • the computed backpay window vs. Maine’s general/default SOL framework
        • 0.5 years (6 months) under Title 17-A, § 8
    • Because the jurisdiction data you provided did not identify any claim-type-specific sub-rule, the checker uses the general/default period.
  4. Only after validation, run Wage Backpay

    • If the checker finds issues, correct the spreadsheet inputs and re-run until warnings are resolved.
  5. Record what changed

    • If you adjust any dates, keep a quick note (even “through date updated from X to Y”) so you can compare iterations.

Reusable checklist:

Try the checker

You can test this workflow by using DocketMath → Wage Backpay with Maine (US-ME) jurisdiction rules. The goal of this “try” step is not to finalize legal outcomes—it’s to confirm your spreadsheet inputs won’t produce an incorrect calculation window.

Inputs to prepare in your spreadsheet

For best results, include:

  • A through/end date (the latest “worked” date you want included)
  • A from/start date (the earliest “worked” date you want included)
  • Wage-related numeric columns (e.g., rate, hours, or whatever your Wage Backpay setup expects)
  • Consistent pay period identifiers (optional, but helpful to detect duplicates)

What outputs change when inputs are wrong

When the underlying issue is date-related, the checker typically affects the run in one or more ways:

  • Recomputed or corrected date window

    • The checker may flag that the window exceeds Maine’s default SOL framework and prompts you to adjust dates.
  • Different inclusion/exclusion of pay periods

    • When the window changes, some pay periods may be dropped or re-included.
  • Total backpay changes materially

    • Since wage fields are additive, even one misaligned pay period can shift totals significantly.

Pitfall: If your “through date” is off by even one pay period, the SOL-window check can change the included set—sometimes producing totals that look plausible but are based on the wrong time slice.

Primary CTA

Start here: /tools/wage-backpay

Related reading