Spreadsheet checks before running Wage Backpay in Delaware

What the checker catches

Before you run a Delaware wage backpay calculation in DocketMath, you want your spreadsheet to be “structurally sound.” The Spreadsheet checker helps by validating the inputs that most commonly drive backpay totals—especially where a wrong date or mismatched earnings line can quietly distort the result.

For Delaware, the most common downstream issue is the lookback window. Delaware uses a general/default statute of limitations (SOL) period of 2 years, which comes from Title 11, §205(b)(3) (source: https://delcode.delaware.gov/title11/c002/index.html?utm_source=openai). Wage backpay spreadsheets typically restrict which unpaid wages are recoverable based on when the claim is filed, so the spreadsheet must gate rows against that timing correctly.

Because the brief did not identify any claim-type-specific sub-rule, this checker treats the 2-year period as the default for spreadsheet gating. In other words, you should assume 2 years unless you have separate, clearly applicable guidance that overrides the default.

The checker focuses on issues that affect two big areas:

• Date anchoring errors

  • Missing the claim filed date or missing work period start/end dates
  • Mixed date formats (e.g., 01/02/2025 vs 2025-01-02)
  • “End date” earlier than “start date”
  • Time zone or import offsets that can create off-by-one-day shifts when payroll exports are converted

• Lookback-window mismatches

  • Backpay rows that fall entirely outside the 2-year general period
  • Partial overlap rows where the spreadsheet doesn’t correctly handle cutoffs/pro-rating behavior (if your sheet models pro-rating to the cutoff)
  • A cutoff date derived from the wrong rule—this checker ensures you are using the general/default 2-year period, not an accidental alternate assumption

Note (important): Delaware here is handled using the general/default SOL period of 2 years under Title 11, §205(b)(3). Your provided jurisdiction data does not identify a claim-type-specific sub-rule, so the checker uses 2 years as the default for spreadsheet gating.

• Earnings line integrity

  • Units that don’t match your assumptions (e.g., “hours” entered as “days”)
  • Blank cells where DocketMath expects numbers
  • Currency inconsistencies (e.g., some rows in dollars while others are effectively in cents)
  • Negative values in wage components where they don’t make sense for your modeled scenario

• Aggregation issues

  • Double-counted pay periods (duplicate date ranges)
  • Subtotals/totals that don’t reconcile with the underlying filtered rows (e.g., sums that change after a filter step)

To make this practical, here’s what the checker is effectively guarding against in a typical wage backpay spreadsheet:

When to run it

Run the spreadsheet checker every time you change inputs that affect dates or wage math, not only right before producing a final number.

A good cadence for Delaware backpay work is:

• Before your first DocketMath wage backpay run

  • When you import payroll data or build the sheet from scratch

• After any date change

  • Updating the claim filed date
  • Adjusting work period start/end dates
  • Editing the pay-period schedule (even a small shift can move rows across the 2-year cutoff)

• After any wage-rate or hours adjustment

  • Correcting hourly rates
  • Adding missed shifts or pay items
  • Recalculating hours from timekeeping exports

• After filtering or deduping

  • When you exclude certain rows or remove duplicates
  • When you regenerate the sheet from a different payroll export format

Use this trigger list as a checklist:

If any box is checked, rerun the checker before relying on the wage backpay output.

Try the checker

You can run the Delaware wage backpay workflow in DocketMath here: /tools/wage-backpay.

Then, apply these “input sanity checks” to your spreadsheet before you submit it to the wage backpay calculator:

1. Confirm the anchor date

   • Verify the claim filed date is present and correctly formatted

2. Verify each pay period row

   • Ensure start date ≤ end date
   • Ensure hours and rates are numeric with no blanks

3. **Check the 2-year lookback logic (Delaware default)

   • The checker should gate rows using the general/default 2-year SOL period (not a claim-type-specific variant, because none was identified in the provided jurisdiction data)

4. Reconcile totals

   • If totals change after checker flags rows, inspect the flagged lines first—don’t just accept the new total blindly

5. Re-check after edits

   • If you fix date formats, rerun to ensure your spreadsheet is now interpreting dates the way you think it is

Friendly reminder (not legal advice): This is process guidance to reduce spreadsheet errors. Wage eligibility and SOL application can depend on case-specific facts. Consider confirming assumptions with a qualified professional if needed.

What output changes when the spreadsheet is fixed?

Fixing date and numeric integrity typically changes results in three ways:

• Rows previously outside the SOL window may become correctly included (or vice versa)
• Pro-rated amounts adjust if your spreadsheet models partial overlap with the cutoff
• Totals stabilize because duplicates and missing/incorrect values are removed or corrected

That’s why the checker is most valuable before you trust the final backpay number.

Related reading

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