Spreadsheet checks before running Wage Backpay in Nebraska

What the checker catches

Run this scenario in DocketMath using the Wage Backpay calculator.

Before you run DocketMath’s Wage Backpay calculator for Nebraska (US-NE), use the spreadsheet checker to catch the issues that most often break backpay math—especially around the statute of limitations (SOL) window.

For Nebraska, the checker and calculator are guided by the general/default SOL period:

• General/default SOL period: 0.5 years
• Statute: Neb. Rev. Stat. § 13-919
  Important: This post uses the general/default period because no claim-type-specific sub-rule was found in the provided jurisdiction data.

Common spreadsheet errors the checker flags

Use this list to compare what’s in your sheet versus what the checker expects.

• Wrong date basis

  • Catching whether the sheet uses the wrong start date (e.g., date hired vs. date of last unpaid wages).
  • Ensuring the “lookback” window is anchored correctly to your chosen SOL start point.
• SOL mismatch

  • Preventing a situation where your sheet calculates backpay for, for example, 2–3 years, but Nebraska’s 0.5-year general SOL should constrain the included period.
• Off-by-one day math

  • Spotting formulas that accidentally include one extra day—common when using inclusive date ranges.
• **Unit errors (hourly vs. daily vs. pay-period totals)

  • Checking whether your inputs are consistently in hours (then multiplied by rate) or consistently in pay totals (then no redundant multipliers).
• Rate inconsistencies

  • Detecting rows where the hourly rate changes but the sheet doesn’t update the rate column.
• Overlapping ranges

  • Flagging duplicate entries where two date ranges cover the same pay period and are both counted.
• Missing pay components

  • Catching when your sheet excludes wage components you intended to include, or includes components that don’t match the calculator’s input structure.

Quick “sanity table” (what to verify)

When to run it

Run the spreadsheet checker right before you feed numbers into the Wage Backpay calculator—specifically at two points in your workflow.

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.

1) Before you enter data into DocketMath

If you’re building a new spreadsheet or migrating data from another document, run the checker first.

Why this timing matters:

• SOL-driven lookback windows depend on dates.
• If dates are wrong, every downstream figure (hours included, wage totals, and summarized backpay) becomes unreliable.

2) After you adjust the dates—but before you re-calculate totals

People often tweak one date (like “last unpaid wage date”) and then re-run totals manually.

Treat date edits as a trigger to run the checker again because:

• Inclusive/exclusive boundaries can shift the included days.
• Overlapping ranges can appear after edits.

“Go/no-go” checklist

Use these checkboxes to decide whether the sheet is ready for the Wage Backpay run:

Warning (gentle but important): If the checker reports a SOL mismatch, don’t “assume it’s fine.” In Nebraska, the general/default SOL period referenced here is 0.5 years, so the backpay window (and total) can change substantially.

Try the checker

You can run DocketMath’s Wage Backpay flow here: /tools/wage-backpay.

While you try it, focus on how inputs change the outputs—especially the SOL lookback constraint.

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

Inputs to prepare in your spreadsheet

To keep your sheet aligned with DocketMath’s calculator workflow, make sure it clearly supports:

• Dates

  • The date range(s) you want included in backpay
• Wage math

  • Either hours + hourly rate, or pre-calculated wage totals
• Consistency

  • Same units and same wage basis across rows

Output behaviors to watch

Once you run the calculator (after the checker), look for these patterns:

1. Backpay total shrinks when SOL is applied

   • If your spreadsheet included more than 0.5 years, the corrected output will likely drop.
2. Row-level totals should re-align after date corrections

   • If you adjust the start date, verify that the row sums and grand total update coherently.
3. Large differences often trace to date or unit issues

   • If the total changes dramatically without changing rates, revisit date boundaries and overlapping ranges first.

Practical mini-scenario (how the checker changes results)

• Your sheet covers 12 months of alleged unpaid wages.
• Nebraska general/default SOL period used here is 0.5 years (about 6 months).
• If the sheet doesn’t constrain the range, the checker will flag the SOL mismatch.
• After you correct the dates, the backpay window narrows, and the totals should drop accordingly.

If you want to keep the process tight, run:

1. checker → 2) correction → 3) calculator rerun → 4) review totals

(General note: this is a math and workflow check, not legal advice. If you’re unsure which SOL rule applies to your specific claim, consult a qualified professional.)

Related reading

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