Total Biweekly Hours Without an Off-by-a-Day Error

You run the numbers for a 14-day pay period, hand the total to whoever cuts checks, and a week later someone says their hours are short by a shift. Or long by one. The math itself is rarely wrong. The error is almost always at an edge: which day starts the period, which day ends it, and what time of day the cutoff falls. Get the boundaries right and the addition is just addition.

Here is the full process for totaling a two-week pay period, in the order you actually do it, with the specific spots where a full day sneaks in or falls out.

Fix the exact start and end before you add anything

A biweekly pay period is 14 calendar days, not two named weeks. Write down the first date and the last date as real dates, like "Monday June 2 through Sunday June 15." That is 14 days inclusive. The classic off-by-a-day error is treating the end date as exclusive in one tool and inclusive in another. If your period runs the 2nd through the 15th, the 15th is in. The 16th is out, even if someone worked a morning shift on the 16th.

Decide the cutoff time too, not just the date. Most teams use midnight. So the period covers from 00:00 on the 2nd up to, but not including, 00:00 on the 16th. A shift that starts at 11:30 PM on the 15th and ends at 1:00 AM on the 16th belongs partly to each period unless you have a rule. Pick one: count the entry where it starts, or split it at midnight. Write the rule down once and apply it the same way every period.

Pull the raw entries and check the timezone

Export or list every clock entry that falls inside your dates. Each row should have a worker name, a start, an end, and a duration. Before you trust any of it, confirm what timezone those timestamps are in. This is where remote or traveling staff create phantom days.

If your timestamps are stored in UTC but you read them as local time without converting, an 8:00 PM Pacific clock-in shows as the next calendar day. A shift you think landed on the 15th now reads as the 16th and drops out of the period. Kangaroo Clock stores every entry in UTC and shows it in the viewer's local time, so what you see on screen already matches your wall clock. If you are working from a spreadsheet someone else built, ask which timezone the column is in before you filter by date.

Close out forgotten clock-outs before totaling

An open entry with no clock-out will wreck a biweekly total faster than any boundary mistake. Someone forgot to tap out on day three. If your system fills the missing end with the current time, that single entry can read as 280 hours and swallow the whole period.

Scan for any entry where the duration is blank or absurd. A 14-hour shift at a tutoring center is suspect. A 90-hour one is broken. Kangaroo Clock handles this with auto-close: a stale open entry gets closed at its start time plus your cutoff, never at the current time, so a forgotten clock-out never inflates the reported hours. If you are correcting by hand, replace the missing end with a reasonable shift length based on the schedule, not with right now.

Convert to one format, then add

Mixing 7:45 (hours and minutes) with 7.75 (decimal) in the same column is how you end up 12 minutes off per row. Pick one and convert everything. For totaling and for anything that feeds pay, decimal hours are easier because you can just sum the column. 7 hours 45 minutes is 7.75. 7 hours 20 minutes is 7.33, not 7.20. If you have a stack of HH:MM values, a decimal and HH:MM converter will save you the rounding mistakes.

Once every row is in the same unit, sum the column. Then sum it a second way as a check: total each of the 14 days separately and add those 14 daily totals. If the two totals disagree, a row is sitting outside your date filter or got counted twice. To do all of this at once, drop your entries into the biweekly hours calculator and let it handle the date window and the addition together.

Verify against headcount and days worked

A total of 612.5 hours means nothing on its own. Sanity-check it. If you have 9 staff who each work roughly 30 hours a week, two weeks should land near 540, so 612 is high and worth a look. Count distinct workers and compare to who you expected. A clean CSV export that includes a distinct-worker count gives you that number without manual tallying, which is the fastest way to catch a name that was double-entered or a worker who never clocked in at all.

Then spot-check the two boundary days specifically. Look at every entry on the first day and the last day of the period. These are the only days where a date or timezone slip can hide. The middle 12 days are almost never the problem.

A quick boundary checklist

Run that list every period and the off-by-a-day error stops happening. If you would rather not chase forgotten clock-outs and timezone drift by hand each time, start a free workspace and let the entries land already cleaned. Your next pay period total will reconcile on the first try.