Spreadsheet checks before running Wage Backpay in Connecticut

6 min read

Published April 15, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

What the checker catches

Run this scenario in DocketMath using the Wage Backpay calculator.

Before you run a Connecticut wage backpay calculation in DocketMath (US-CT), do a quick “spreadsheet checks” pass to prevent the most common reconciliation and limitations-period timing problems. This is especially important because the backpay spreadsheet often becomes its own mini-system: even if the math is internally consistent, the included dates may not match the 3-year lookback that applies in Connecticut.

The key jurisdiction-aware rule (CT)

Connecticut’s general statute of limitations for wage-related claims is 3 years, under Conn. Gen. Stat. § 52-577a. Use this general/default period because no claim-type-specific sub-rule was found for a different limitations window in the information you provided.

Source: Conn. Gen. Stat. § 52-577a (3-year general SOL)
https://law.justia.com/codes/connecticut/title-52/chapter-926/section-52-577a/?utm_source=openai

Spreadsheet issues the checker flags

In practice, the checker helps you catch issues that can silently distort your backpay numbers—especially those related to which dates you included and how they map to pay periods:

Date-range drift
- Start date accidentally placed outside the 3-year lookback window.
- Off-by-one errors when computing the number of days in an “effective period.”
Partial-month or partial-period allocation mistakes
- Using 30-day month assumptions when your spreadsheet intends calendar-day calculations.
- Proration that doesn’t match the pay-cycle cadence you’re modeling.
Pay-rate inconsistency
- Hourly wage changes not reflected on the correct pay periods (or reflected on the wrong rows).
- Overtime vs. straight-time rates applied to the wrong pay-period entries.
Duplicate or missing pay periods
- Overlapping date ranges across tabs (e.g., “2022” and “2023”) that cause the same work/pay to be counted twice.
- Dropped paychecks after filtering (creating gaps that reduce totals).
Incorrect totals and silent rounding
- Rounding at intermediate steps (e.g., rounding per-period values too early) that causes drift in the final total.
- Summing hours stored as text (e.g., "7.5h") instead of numeric hours.

Pitfall to avoid: A backpay total can look “reasonable” while the included work/payment dates do not align with the 3-year window under Conn. Gen. Stat. § 52-577a. Your spreadsheet may be mathematically consistent yet legally misaligned for the Connecticut analysis.

Output expectation: how the checker changes what you run

When the checker finds a limitations-window or date allocation issue, it typically affects one or more inputs you feed into DocketMath’s wage-backpay workflow:

Checker finding	Spreadsheet symptom	How to adjust wage-backpay inputs
Lookback window exceeded	Included dates are earlier than 3 years before your reference event	Set the start date to the earliest permissible day per the 3-year window
Proration mismatch	Totals don’t align with payroll export totals	Recompute each pay period’s payable days/hours using the intended day-count method
Wage-rate mapping issue	Sudden jumps (or drops) in computed wages	Correct effective dates for wage-rate entries so each row uses the correct rate
Duplicates	Totals too high vs. payroll/export totals	Remove overlapping entries so each pay period is represented once
Rounding drift	Final total doesn’t match the sum you’d expect from unrounded calculations	Delay rounding; round only for final display outputs

When to run it

Run the checker early—immediately after you populate the spreadsheet from payroll exports, and before you lock in final numbers in the wage-backpay calculation. This reduces the chance you’ll have to redo downstream outputs after fixing dates or rate mappings.

Best timing in your workflow

After data import / copy-paste
- Once pay periods, hours, and wage rates are in place.
Before final wage-backpay calculation
- So you don’t have to re-run the entire set of outputs after finding a date-window issue.
After any correction pass
- If you change any dates, hours, or rate effective dates, re-run the checks.

Choose a consistent “reference event” date

The wage-backpay process in DocketMath depends on a clear concept of a reference date (for example, the date you treat as the start point for the lookback analysis). Your spreadsheet checker should use the same reference date that you use for the calculation—otherwise the lookback window can shift.

Align these items:

Warning: If your spreadsheet filters rows using one date type (e.g., “payment date”) but the calculation uses another (e.g., “work performed date”), the 3-year window can move by weeks or months.

Try the checker

You can run the workflow in DocketMath here:

Primary CTA: /tools/wage-backpay

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.

Practical input setup for US-CT (what to verify)

Before continuing, confirm your spreadsheet (or prepared inputs) include the equivalent of these fields:

Pay period start date
Pay period end date
Hours worked (numeric)
Wage rate applicable to that pay period
Overtime indicator or overtime hours (if your model separates them)
Adjustment fields (only if your spreadsheet design supports them—e.g., additional components you’ve modeled)

Then run:

**Spreadsheet checks (CT-aware)
- Verify dates fall within the 3-year limitations period under Conn. Gen. Stat. § 52-577a.
- Confirm no duplicates, proration errors, or inconsistent wage-rate mappings.
wage-backpay calculation
- Feed the checker-cleaned date range and period-level wage inputs into the calculation.

What to look for after running

After the checker, you should typically see:

An earliest included date that matches the 3-year SOL window under Conn. Gen. Stat. § 52-577a.
Totals that reconcile more closely to payroll/export totals (with differences that are explainable based on how your model handles categories like overtime).

If the included start date changes after the checker, that’s the signal: the Connecticut 3-year limitations-period alignment is being enforced, and your inputs should be updated accordingly.

Gentle reminder: This is a tooling and workflow guidance checklist, not legal advice. If you’re unsure how your dates map to the calculation rules in your matter, consider validating assumptions with a qualified professional.