Why Wage Backpay results differ in Colorado

The top 5 reasons results differ

If you’re using DocketMath (wage-backpay) in Colorado (US-CO) and your number doesn’t match another calculation you’ve seen, it’s usually caused by a handful of inputs or jurisdiction-aware rule switches that change the math. Most discrepancies come down to timing, how wages are modeled, and how interim earnings are credited.

1) Different “start date” for backpay accrual

Backpay calculations often hinge on two date concepts: when the wage obligation arose and the date range the calculation uses. Even small differences early in the timeline can compound, particularly when overtime hours and variable pay rates are involved.

Common ways start dates differ:

• the alleged work period vs. the claimed pay period
• the date the employee stopped receiving pay
• the date the employer first corrected (or refused to correct) wages

2) Different “end date” (or cutoff assumptions)

Another common mismatch is the end date—the point through which wages are calculated. Different end dates produce different totals, even if everything else is aligned.

Typical cutoff differences include:

• date of reinstatement (if applicable)
• date of discharge (or claim filing date, depending on approach)
• “through” dates used by each calculator or workpaper

3) Pay-rate structure: overtime and irregular schedules

Colorado wage backpay modeling can differ materially when the wage inputs don’t line up, especially for:

• overtime multipliers
• shift differentials or bonuses (included vs. excluded)
• pay frequency and/or schedule changes (for example, from hourly to salary modeling assumptions, or changes in expected hours)

If one calculation assumes a different overtime structure or hour pattern, the wage backpay output will shift—even with identical start/end dates.

4) Which earnings get credited as “offsets” or replacement wages

Even if both calculators use the same overall backpay theory, they may treat interim earnings differently. That treatment can change the net result a lot.

Look for differences such as:

• full offset vs. partial offset
• excluding certain types of compensation from offsetting
• differences in whether amounts are treated net or gross during interim work

If one result offsets interim earnings and another doesn’t (or offsets them differently), the outputs diverge.

5) Missing or mis-specified Colorado-specific wage components

Some disputes involve more than one “wage component” concept. If two calculations define “wages” differently, the totals won’t match.

Examples of mismatches:

• one calculation includes a component your inputs treat as outside the modeled wage base
• one calculation breaks pay into wage vs. non-wage streams differently than the other

Jurisdiction-aware logic can reduce this problem, but inconsistent input categorization still drives differences.

How to isolate the variable

To find the root cause, isolate the single input (or rule switch) that produces the biggest swing. The fastest approach is to make both models match on everything except one variable at a time.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step-by-step isolation workflow

1. Freeze the dates

   • Use the same start date and same end date in both calculations.
   • Confirm pay frequency matches (weekly vs. biweekly, etc.).

2. Match the wage model

   • Align hourly vs. salary assumptions (and any salary-to-hourly conversion).
   • Match overtime modeling: overtime eligibility, hours, and the overtime multiplier.

3. Align earnings offsets

   • Identify whether interim earnings are included.
   • Match how interim earnings are treated (for example, net vs. gross, and which types are included/excluded).

4. Toggle one factor at a time in DocketMath

   • Change only one input (for example: end date, overtime hours/week, or offset treatment).
   • After each change, record how much the output moves.

Quick “delta log” table

How to interpret it:

• If changing dates causes the biggest swing, timing is the culprit.
• If changing overtime structure causes the biggest swing, your wage-rate inputs don’t match.
• If toggling offsets causes the largest delta, the disagreement is about interim earnings crediting.

Next steps

To reach an apples-to-apples number in Colorado using DocketMath:

• Rebuild using your core facts, not the other calculator’s assumptions

  • Use the pay period you can support with records.
  • Enter your actual wage structure: hourly/salary, overtime cadence, and any differentials you’re treating as part of the wage model.

• Validate with a paystub-by-paystub spot check

  • Compare the modeled results for 2–3 representative pay periods to your documents.
  • If those line up, later differences usually narrow to offsets or cutoff logic rather than baseline wage modeling.

• Document every change you make during isolation

  • Keep a short note of the inputs you changed (start date, end date, overtime hours, overtime multiplier, interim earnings treatment).

If you want to run the same diagnostic workflow yourself, start here: Wage Backpay tool.

Related reading

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