The top 5 reasons results differ

Run this scenario in DocketMath using the Overtime calculator.

When you run the DocketMath overtime calculator for Brazil (BR) and the results don’t match what you expect, the gap is usually caused by how Brazil-specific inputs are mapped into the calculation. Below are the most common causes—each one changes the math, not just the wording.

1. Wrong base wage used for the hourly rate

   • In Brazil, overtime is typically computed from the employee’s ordinary hourly pay (i.e., the wage base your system treats as the conversion basis to an hourly rate).
   • If the input you feed DocketMath is missing components that your payroll includes in the hourly conversion, the overtime premium will shift.
   • Result pattern: totals look consistently too high or too low across all pay periods.

2. Different assumptions about working time

   • Your overtime output can change depending on how you model working time, for example:

     • weekly schedule assumptions,
     • daily cap logic,
     • and how boundary minutes are treated.
   • If you provide “total overtime minutes per week” while your comparison set is based on daily breakdowns, DocketMath may interpret when overtime starts differently than your payroll does.
   • Result pattern: discrepancies concentrate around days near thresholds.

3. Overtime category rules not aligned to your scenario

   • Even when everyone calls it “overtime,” employers often record it in different payroll categories with distinct premium logic.
   • If your payroll treats some hours under special premium rules but DocketMath is simulating a different overtime “type,” the effective rate will differ.
   • Result pattern: you see mismatches that correlate with specific days, roles, or pay codes.

4. Rounding and minute-to-hour conversion

   • Minute rounding can create drift, especially with many days of data:

     • 1-minute vs. 5-minute increments,
     • rounding per day vs. rounding only after summing.
   • Result pattern: the difference grows with the number of worked days.

5. Not accounting for the month/week aggregation window

   • Payroll summaries are often cut on a calendar/month boundary (or another payroll cycle), not “whichever window you used in your time export.”
   • If you calculate using a “week ending” mindset but compare to a “monthly payroll” statement (or vice versa), cutoff effects can change which minutes are credited.
   • Result pattern: mismatches cluster around period boundaries or partial weeks.

How to isolate the variable

To debug systematically, treat this like a diagnostic checklist. Use /tools/overtime and change only one input at a time.

Start with: one employee, one payroll period, and a short range (e.g., 2 weeks). Then:

1) Lock your time inputs

Confirm what your source data actually represents:

• daily timestamps,
• daily minutes,
• or already-converted overtime minutes.

In DocketMath, match the same grain of data you’re comparing against.

✅ Checklist:

2) Validate the wage base used for the hourly rate

Identify which wage inputs are driving the hourly conversion in the calculator:

• fixed monthly salary only, or
• salary plus payroll components that your payroll effectively treats as part of the hourly conversion.

Run a controlled comparison by adjusting only the wage base.

✅ Checklist:

3) Test rate multipliers and overtime categorization

Ensure the overtime “type” you’re simulating in DocketMath matches the payroll category logic you’re trying to replicate.

✅ Checklist:

4) Compare outputs by component

Instead of checking only the grand total, compare component-by-component:

• overtime hours/minutes,
• overtime premium rate,
• resulting overtime amount.

This tells you whether the mismatch is coming from time volume, rate, or aggregation/rounding:

• If minutes match but amount doesn’t, focus on wage base/rate rules/rounding.
• If minutes don’t match, focus on time grain, thresholds, and aggregation windows.

Note: This is not legal advice—use it to reconcile calculations and data mapping with your internal payroll configuration.

Next steps

Fastest path to a fix:

1. Run DocketMath overtime for BR using /tools/overtime.
2. Pick one payroll period and record:

   • total overtime minutes/hours,
   • the calculated hourly rate (if shown),
   • the computed overtime premium amount.
3. Change one variable and rerun, in this order:

   • wage base,
   • then time aggregation/window,
   • then rounding,
   • then overtime categorization/premium assumptions.
4. Stop when the first component aligns (minutes → hourly rate → premium amount).

When comparing to payroll statements, match the payroll cycle first, then verify your time data uses the same cutoff rules.

Related reading

• Browse the blog

The top 5 reasons results differ

• Different trigger dates or event definitions were used.
• Inputs were entered with different day-count or compounding assumptions.
• Payments, credits, or tolling periods were handled differently.
• Jurisdiction or court settings did not match the matter.
• Rounding or cutoff-time rules were applied inconsistently.

How to isolate the variable

• 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.

Next steps

Use the Overtime tool to produce a first pass, then share the output with the team for review. You can start directly in DocketMath: Open the calculator.

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

Related reading

• Why Overtime results differ in Philippines — Troubleshooting when results differ
• Worked example: Overtime in Philippines — Worked example with real statute citations
• How to run Overtime in DocketMath for Philippines — Step-by-step platform walkthrough