How to Track Hours Worked and Calculate Pay Accurately

Most pay disputes do not come from disagreements about the hourly rate. They come from small errors in how hours were added up in the first place. A shift that started at 8:47 and ended at 5:12 gets rounded the wrong way. A lunch break gets counted twice, or not at all. A contractor working across three time zones logs hours in the wrong day entirely. None of these mistakes are dramatic on their own, but they compound over a pay period, and they are the kind of thing that erodes trust between an employer and an employee, or between a freelancer and a client.

This guide walks through the math behind an accurate timesheet: converting raw clock times into total hours, applying overtime and rounding rules consistently, handling shifts and meetings that span time zones, calculating the length of a pay period correctly, and formatting the final numbers so an invoice or pay stub is easy to read and hard to dispute. None of this requires specialized payroll software. It just requires doing the arithmetic the same way every time.

From Clock Times to Total Hours

The first source of error is the most basic one: turning a start time and an end time into a number of hours. It sounds trivial until the times do not fall on a clean hour. A shift from 8:47 AM to 5:12 PM is not "about 8 hours." It is 8 hours and 25 minutes, which as a decimal is 8.4167 hours. If you are paying by the hour, that 0.4167 matters, especially once you multiply it by an hourly rate and then by every shift in a pay period.

The second source of error is breaks. Some workplaces require unpaid breaks to be subtracted from the total. Others only subtract breaks over a certain length, or treat short breaks as paid time. If a worker clocks in at 9:00, takes a 38-minute lunch, and clocks out at 5:30, the difference between "subtract the full break" and "round the break to 30 minutes" changes the paid total by 8 minutes. Across a five-day week, that is 40 minutes. Across a year, it is real money in either direction.

Overtime, Breaks, and Rounding Rules

Once you can convert a single shift into an accurate decimal number, the next question is what happens once the total crosses certain thresholds. Overtime rules vary by location and by employer policy, but the most common structure is a standard threshold, often 40 hours per week, beyond which additional hours are paid at a higher rate, such as 1.5 times the regular rate. The arithmetic itself is simple: hours up to the threshold get the regular rate, hours beyond it get the overtime rate, and the two totals are added together. The part that causes problems is deciding which hours count toward the threshold in the first place. Paid holidays, sick days, and vacation time are sometimes excluded from the overtime calculation even though they appear on the same timesheet as worked hours.

Rounding policy is the other piece that needs to be decided once and then applied consistently. Some employers round each clock punch to the nearest 15 minutes. Others round only the final daily or weekly total. A small rounding rule applied inconsistently, rounding some days up and others down depending on who is doing the math, is one of the most common sources of "my paycheck doesn't match my hours" complaints. Write the rule down, apply it the same way every time, and recalculate a past pay period using the rule to confirm it produces numbers everyone agrees with before relying on it going forward.

For anyone tracking their own time as a freelancer or contractor, the same discipline applies even without a formal overtime policy. If you bill at a higher rate after a certain number of hours on a project, or if a client's contract specifies a cap on billable hours per week, the same threshold-based math determines whether you are inside or outside the agreed scope. Knowing your exact decimal total, rather than a rounded estimate, is what keeps that conversation factual instead of a guessing game.

Scheduling and Logging Hours Across Time Zones

Remote work adds a layer that a single-office timesheet never has to deal with: which day did the work actually happen on? A contractor in one time zone who works from 9 PM to midnight local time has, from their client's perspective in a different time zone, worked during the following morning. If both sides log the hours against their own local date, the totals for "Monday" and "Tuesday" will not match, even though everyone agrees on the actual hours worked.

The fix is to agree on a single reference time zone for logging purposes, usually the client's time zone or a neutral choice like UTC, and convert every logged shift into that reference before adding it to the timesheet. This is especially useful for teams that hold recurring meetings across regions, where "our weekly sync" can quietly drift by an hour twice a year as different countries shift in and out of daylight saving time on different schedules. A Time Zone Converter makes this conversion immediate rather than something everyone has to recalculate in their head, and it removes the ambiguity of phrases like "end of day," which means something different depending on which side of the globe you are on.

The same tool is useful for a smaller but common problem: figuring out whether a shift that starts before midnight and ends after it should be logged as one day or split across two. Converting both the start and end times into the agreed reference zone first, then doing the hours calculation, avoids the off-by-one-day errors that happen when each person logs time against their own local clock.

Calculating Pay Periods and Date Ranges

Pay periods sound straightforward until you have to count them. A biweekly pay period is not "two weeks" in the sense of a fixed 14-day block that lines up neatly with the calendar every time, especially when a pay period starts mid-week, or when a holiday shifts a payment date. Knowing the exact number of days, and specifically the number of working days, between two dates is the basis for prorating a salary, calculating how much of a pay period a new hire actually worked, or figuring out how many billing days fall into a given invoice.

Say an employee starts on a Wednesday, and the pay period runs Monday through Sunday. Their first paycheck covers five days, not a full week, and if their salary is calculated as an annual figure divided into 26 biweekly payments, that first check needs to be prorated based on the actual number of days worked relative to the full period. The same logic applies at the end of employment: the final paycheck usually needs to reflect the exact number of days worked in the final, partial period, not a rounded estimate.

This also matters for anyone tracking deadlines tied to a pay period, such as the window to submit expenses or dispute a timesheet entry. If that window is "10 business days after the pay period ends," getting the actual end date right, especially around holidays or when a pay period boundary falls on a weekend, determines whether a legitimate correction request arrives on time or gets rejected for being a day late.

Formatting Invoices and Large Numbers

Once the hours and pay period are correct, the last step is presenting the numbers in a way that is easy to read and verify. This matters more than it might seem. A total of 1825000 on an invoice is technically correct, but it takes a second look to confirm whether that is one million eight hundred twenty-five thousand or something else entirely. The same number written as 1,825,000 is unambiguous at a glance, and that small difference matters when someone is scanning a long invoice or a year-end summary for errors.

This applies to more than just final totals. Annual salary figures, total hours logged across a year, reimbursement amounts, and even raw minute counts used in internal calculations all become easier to sanity-check once they are formatted consistently. A quick pass with the Add Commas to Numbers tool before sending a report or invoice out the door turns a wall of digits into something a client or manager can actually skim, which reduces the number of "can you double-check this number" follow-up emails.

Building a System That Holds Up Over Time

None of the individual calculations above are complicated. The reason timesheets still go wrong is that the calculations are done inconsistently, by different people, on different days, with slightly different rounding habits. The fix is not a more complicated system, it is a more consistent one.

Pick one rounding rule and write it down. Agree on one reference time zone for any work that crosses regions, and convert everything into it before logging. Calculate pay period boundaries from the calendar, not from memory, especially around holidays. And format the final numbers so that anyone reviewing them, including you, three months later, can read them without having to recount digits. Each of these is a small habit, but together they remove almost every common source of pay disputes, and they turn a timesheet from something people argue about into something people simply trust.

Summary

Accurate pay starts with accurate hours, and accurate hours come from converting clock times correctly, applying overtime and rounding rules the same way every time, agreeing on a shared time zone for remote work, calculating pay periods from real dates rather than estimates, and formatting the final numbers clearly. None of these steps require new software or a complicated process. They require doing the same simple math the same way, every time, so the numbers on a timesheet and the numbers on a paycheck always agree.