Skip to content

Why Timesheet Period Boundaries Must Be Explicit

A pay period stated as "the 1st through the 15th" is ambiguous about whether hours worked at the exact boundary belong to this period or the next one.

A recurring timesheet or pay period defined by calendar dates ("the 1st through the 15th," "every other Monday") needs an explicit rule for exactly where one period ends and the next begins, especially for a shift or timestamp that falls right at the boundary. Without that rule stated, hours worked in the last minutes of one period can be miscounted into the next, or vice versa, which compounds the same inclusivity ambiguity covered in the date-range resource above, applied specifically to recurring pay periods.

Period A (1st-15th) Period B (16th-end of month) A shift spanning midnight on the 15th/16th boundary needs an explicit rule for which period its hours belong to, the same overnight-attribution question covered in its own resource above.
A shift or timestamp landing exactly on a pay-period boundary needs an explicit attribution rule, not an assumed one.

Why period boundaries compound two separate ambiguities

A recurring pay period boundary combines the date-range inclusivity question (does the boundary date itself belong to the ending period or the starting one) with the overnight-shift attribution question (which period does a shift crossing midnight on that exact boundary night belong to) covered in their own resources above. Getting either one wrong at a period boundary, even occasionally, produces a small but real discrepancy between two independently computed timesheet totals for the same underlying hours.

Why this matters more at a pay-period boundary than mid-period

A rounding or attribution ambiguity in the middle of a pay period has no real consequence, since the hours land in the same period either way. The same ambiguity exactly on a period boundary can shift hours (and therefore pay) from one pay period to the next, which is the specific case worth checking explicitly rather than assuming any convention "washes out" over time.

What the Timesheet Period Calculator checks

The Timesheet Period Calculator takes an explicit period-boundary rule alongside the pay period definition and flags any entered shift or timestamp that falls exactly on a boundary, so a period-crossing case is surfaced directly instead of silently resolved by whichever rule happens to be the default.

Key takeaway. A recurring pay period's boundary needs an explicit attribution rule, especially for a shift crossing midnight exactly on that boundary night. Check both the date-range inclusivity and the overnight-shift attribution rule together at that specific point.

Frequently asked

Does comp time accrual use the same period boundaries as regular pay?
Not necessarily. A comp time policy can define its own accrual period independent of the regular pay period, which is why the Comp Time Calculator treats its period boundary as a separate explicit setting rather than assuming it matches the timesheet period.
Is this the same issue as the overtime-threshold calculation?
It is related but distinct. Overtime thresholds are usually evaluated within a period once that period's hours are correctly totaled, so a period-boundary misattribution can indirectly shift which period a given overtime threshold is checked against.
What is the most common period-boundary convention?
There is no universal default. Semi-monthly (1st-15th, 16th-end), biweekly, and weekly periods are all common, and each requires its own explicit boundary and attribution rule rather than a single assumed standard.

Related engines

Last updated 2026-09-04

Back to Resources