Spreadsheet checks before running Wage Backpay in Illinois

What the checker catches

Run this scenario in DocketMath using the Wage Backpay calculator.

Before you run Wage Backpay in Illinois with DocketMath, a spreadsheet-style “sanity check” can prevent the most common causes of incorrect backpay totals—especially when your dataset spans multiple pay rates, date ranges, and employment events.

This Illinois-focused checker is designed around the general/default statute of limitations (SOL) period of 5 years under 720 ILCS 5/3-6. The checker uses this general period because no claim-type-specific sub-rule was identified for this workflow. In practice, that means the tool (and your spreadsheet) should treat the period starting 5 years before the selected “as-of” date as the outer boundary unless you separately confirm a different limitation rule applies.

The categories of spreadsheet errors it catches

• **Date-window breaches (SOL cut-off)

  • Detects whether the work dates you included fall more than 5 years before your selected “as-of” date.
  • Flags the exact rows that exceed the limit so you can either exclude them or reconcile why they’re still needed.

• Broken date formats / mismatched date columns

  • Identifies rows where “start date,” “end date,” or “pay date” aren’t recognized as dates.
  • Helps avoid silent issues like text dates (for example, 01/02/2023 stored as text), which can break filtering and day-count logic.

• Off-by-one day and partial-day mistakes

  • Checks whether your day-count convention is consistent (e.g., whether you treat endpoints as inclusive or exclusive).
  • For backpay calculations, a single off-by-one error can shift totals by more than you’d expect—particularly when hours and shifts span many pay periods.

• Inconsistent wage rate fields

  • Flags rows where hourly rates change but the “effective date” sequencing is missing, out of order, or overlaps.
  • Calls out scenarios where overtime multipliers or shift differentials appear in some rows/columns but aren’t applied consistently across the period.

• Pay-period misalignment

  • Detects when your compensation entries don’t line up with the pay periods you’re aggregating (weekly vs. biweekly vs. irregular pay).
  • Helps avoid totals that look plausible but are built from mismatched rows.

• Missing or duplicated pay entries

  • Finds duplicate records (for example, same employee identifier + same pay period + same amount).
  • Also helps spot missing pay lines where hours exist but wages do not (or where the dataset suggests a line should exist).

When to run it

Run the checker before calculating and again after you reshape your spreadsheet. The key is that the SOL boundary is computed relative to your as-of date, and many spreadsheet edits subtly change which rows are included.

A practical workflow is:

1. After you choose the “as-of” date

   • The checker needs that date to compute the 5-year SOL window from 720 ILCS 5/3-6 (general/default rule).
   • If you later change the as-of date, you should rerun the check because the boundary moves.

2. After you standardize dates and identifiers

   • Ensure every row has:

     • the relevant work/pay dates
     • wage rate fields (and effective dates, if you track them)
     • a consistent employment identifier (employee ID or equivalent)

3. Right before you export or pass data into DocketMath

   • The goal is to prevent formatting and logic problems from propagating into the wage backpay engine.

4. After any manual edits

   • If you remove date ranges, correct overlaps, or re-enter pay lines, rerun the check immediately so the spreadsheet state matches your intent.

To keep it actionable, consider maintaining a “status column” with outputs like:

• ✅ Within 5-year window
• ⚠️ **Outside 5-year window (excluded or reviewed)
• ❌ Invalid date format
• ❌ Overlapping wage-rate effective dates
• ⚠️ Potential off-by-one day issue
• ⚠️ Duplicate or missing pay entry indicators

This makes your final totals traceable to row-level checks, not only to the aggregate number.

Try the checker

You can use DocketMath’s Wage Backpay workflow as the calculation step, but treat this “spreadsheet checks” pass as your quality gate.

Start by opening Wage Backpay here: /tools/wage-backpay.

Then map your spreadsheet columns to the inputs the calculator expects on that /tools/wage-backpay path. At minimum, you’ll typically need:

• As-of date (drives the 5-year boundary)
• Work/pay date range (the rows you want included)
• Wage rate inputs (hourly rate, rate changes, and any multipliers if your sheet uses them)
• Hours and/or wage amounts (depending on how your sheet stores compensation)

Preflight items to verify (Illinois, default SOL = 5 years)

When you see flags

When the checker flags problems, update your spreadsheet and rerun until you see clean, consistent status across the full date range.

If you want the fastest validation loop:

• Filter to the flagged rows only
• Fix date formatting / overlaps / duplicates
• Restore the full dataset
• Re-confirm that the count of included rows matches your intended scope

Note (gentle disclaimer): This workflow helps you reduce spreadsheet and data-quality errors. It does not replace legal advice. For anything beyond the general default SOL approach referenced above, consider confirming the right limitation rule for your specific situation.

Related reading

• Wage & Backpay Calculator Guide for Alabama
• Wage & Backpay Calculator Guide for Arizona
• Wage & Backpay Calculator Guide for Colorado