A timesheet can look orderly and still produce the wrong total. The most useful review checks the meaning of the inputs before checking the arithmetic: are the entries clock times or durations, do they include dates, are breaks represented consistently, and does each row belong to the correct person and period? Once those questions are settled, totals become much easier to reconcile.
This guide covers seven practical data errors using illustrative examples. It does not decide which time must be paid or which rounding policies are permitted. Those questions depend on the applicable rules and the employer's policy. For the underlying calculation, start with the work hours guide and use the work hours calculator to check an ordinary shift independently.
1. Treating minutes as decimal digits
An entry of 7:45 means seven hours and 45 minutes when it is a duration. Its decimal equivalent is 7.75 hours, not 7.45. Forty-five minutes represents three quarters of an hour. Replacing the colon with a decimal point understates this example by 0.30 hours, which is 18 minutes.
Catch the error by labeling every duration column with its unit and format. A heading such as “worked hours, decimal” is clearer than “time.” Include a known test value such as 1:30, which should convert to 1.5 hours. If it becomes 1.30, the conversion process is probably changing the display without converting the quantity.
Review imported values before applying rates or calculating capacity. Decimal errors can look plausible because both 7.45 and 7.75 resemble an ordinary workday. The decimal hours conversion chart provides reference values that make these mistakes easier to spot without recalculating every row from scratch.
2. Losing the date on an overnight shift
A shift starting at 22:00 and ending at 06:00 the next day spans eight hours under an ordinary fixed-offset clock. If you subtract the clock readings without their dates, the raw result may be negative. If you reverse the subtraction to remove the negative sign, you may produce 16 hours instead of eight.
The correction is to record complete start and finish dates as well as times. This also distinguishes an eight-hour overnight shift from a much longer multi-day interval. A simple “add 24 hours whenever the result is negative” rule can conceal an accidentally reversed entry and cannot describe every multi-day case.
Flag negative or unexpectedly long durations for review rather than automatically accepting them. For daylight saving transitions, preserve time zone offsets so elapsed time is not inferred solely from local clock readings. The overnight shift guide explains the basic midnight case and the information needed to interpret it.
3. Subtracting a break twice
Suppose an employee is present from 09:00 to 17:30, with a recorded 30-minute unpaid break. The elapsed span is 8.5 hours and the illustrative net duration is eight hours. If the source already supplies eight net hours and an import subtracts the break again, the result falls to 7.5 hours.
Check whether each source field represents elapsed presence, recorded work, paid time or a net duration after deductions. Do not assume that a field called “total” contains the same quantity in two different systems. Record the definition next to your mapping, especially if a new export format replaces an older one.
A reconciliation should show the elapsed span, the break deduction and the resulting net duration in separate fields. That makes a duplicate deduction visible. The timecard break guide discusses the calculation; any decision about whether a particular break is paid belongs to the applicable policy and rules, not to the conversion formula.
4. Importing the same row more than once
Duplicate rows can enter a timesheet when overlapping exports are combined, an upload is retried, or corrected records are appended without replacing their earlier versions. Two identical durations are not necessarily duplicates, however. An employee can legitimately work the same hours on different dates or on two separate assignments.
Use a stable source record identifier where one exists. Otherwise, compare a combination of employee identifier, date, start time, end time and assignment. Treat a match as a review signal, not automatic proof that a row should be deleted. Split shifts, corrections and separately coded activities can share some of those fields.
For example, importing a weekly file twice changes five eight-hour rows into ten rows and doubles the total from 40 to 80 hours. A row-count check would catch the problem before a rate calculation. Keep the original imports and a record of any removed duplicate so another reviewer can reconstruct the final file.
5. Rounding each row before checking the total
Three durations of 20 minutes total exactly one hour. Converted individually and displayed to two decimals, each becomes 0.33 hours. Adding those rounded values produces 0.99 hours. The missing 0.01 hours is 36 seconds, caused by the sequence of rounding rather than by a missing source record.
Preserve original minutes or seconds and use unrounded conversions for a control total. If the destination requires rounded line values, calculate a second total using those actual exported values. Document the difference so reviewers understand why a displayed total might not match the sum of another system's rounded rows.
Do not solve an unexplained discrepancy by inserting an arbitrary adjustment. First identify whether the difference comes from rounding, an omitted row, a break deduction or a changed unit. The rounding differences guide gives worked examples of the first cause, while the other checks in this article help isolate the rest.
6. Mixing people, projects or reporting periods
A correct duration attached to the wrong employee is still an incorrect record. Names alone can be unreliable matching keys because two people may share a name or one person's name may appear in several formats. Use the intended stable employee identifier and keep it separate from display names.
Period boundaries need equal care. A shift that crosses midnight or a reporting cutoff may need allocation according to the reporting method. Preserve the underlying start and finish record even if the report splits it into two rows. Otherwise, the split can be mistaken for two independent shifts during a later import.
Check totals by person and by period, not only for the complete file. An overall total of 400 hours could remain unchanged while 20 hours are assigned to the wrong team. Reconcile a few individual records against the source, especially where employees changed departments or projects during the period.
7. Treating missing information as zero
A blank finish time is not the same as a confirmed zero-hour shift. A blank break field may mean “no break,” “not collected,” or “unknown,” depending on the source. If every blank is silently converted to zero, the file may appear complete while important information remains unresolved.
Define which fields are required and which blanks have an agreed meaning. Keep incomplete rows in an exception list with a clear reason, such as “finish timestamp missing.” Give each exception an owner and a resolution status so the review does not depend on someone remembering a conversation outside the record.
When a missing value is corrected, retain the original value and the correction reason where your process allows it. An audit trail helps distinguish a genuine correction from an unexplained manual change. This is particularly useful when a report has already been shared and a later version produces a different total.
A practical review sequence
Begin with file identity: source, export time, reporting period and row count. Next validate required fields and formats. Then calculate raw durations, review exceptions, apply the documented break treatment and compare totals by employee. Only after those checks should you prepare the destination-specific export.
Use a small known example as a control when the process changes. Include a normal shift, an overnight shift, a break, a short duration and a deliberate missing value. Record the expected result for each. A process that passes those checks can still encounter unusual data, but the controls quickly reveal common mapping mistakes.
Before sending the file onward, read the decimal-time import checklist. It connects row-level checks with the final export review. The goal is a result that another person can trace back to the source, not merely a total that looks reasonable on the screen.
Frequently asked questions
Should I automatically delete duplicate-looking entries?
No. Flag them and compare their identifiers and context. Repeated hours may be legitimate. Remove a row only after establishing that it repeats the same underlying record rather than representing a separate shift or adjustment.
Is a negative duration always an error?
Not necessarily. It may represent a deliberate adjustment, but it may also come from reversed timestamps or missing dates. The record type and source convention should explain the sign before it enters a total.
What is the fastest useful final check?
Compare row counts, total original duration and totals by employee against the source. These checks catch different problems. A matching grand total alone does not establish that every record belongs to the right person, period or activity.