Make sense of the decimals on your paycheck
Paycheck stubs, job-costing reports and billing exports all speak in decimal hours, but humans think in hours and minutes. When a report says you worked 38.42 hours this week, how long is that really? This decimal to time converter answers in one keystroke: 38.42 decimal hours is 38 hours 25 minutes. Type any decimal and the clock-time equivalent appears beside it.
The converter works in both directions, so it is equally useful before and after payroll runs. Enter time to decimalize a timesheet, or enter a decimal to decode a report. Both fields stay in sync as you type, which makes comparing two numbers in different formats a two-second job instead of a spreadsheet exercise.
Where the multiplication can trick you
The subtle part of converting decimal to time is that the fractional part multiplies by 60, not by 100. Reading 6.30 as 6 hours 30 minutes is the classic mistake — 6.30 is actually 6 hours 18 minutes, while 6:30 is 6.5 in decimal. Whenever a decimal and a clock time disagree, run both through this converter and see which one the numbers actually support.
That 60-vs-100 confusion is also why hand-written timecards go wrong. A supervisor totaling a column of minutes who writes 7.90 has made a decimal-hours claim of 7 hours 54 minutes — probably not what was meant. Converting the intended clock time here gives the correct decimal to write down instead.
Why payroll systems speak decimal hours
If you have ever been paid through ADP, QuickBooks Payroll or Kronos (UKG), you have noticed the paystub never says 7 hours 45 minutes — it says 7.75. That is not a formatting quirk. Payroll engines ultimately multiply hours by an hourly rate, and arithmetic on a decimal (7.75 × $20.00 = $155.00) is exact and unambiguous, while arithmetic on a mixed-base clock value (7:45) risks treating the 45 as if it were a hundredth. Storing time as a decimal removes the mixed base entirely, which is why every major time-and-attendance platform normalizes punches to decimal hours before anything else happens.
The practical consequence is that decimal hours are the interface between you and your pay. Your employer's system converts your punches to decimals, applies any rounding rule, multiplies by rate, and prints the result. When the stub says 38.42, that number already contains every punch, every lunch deduction and every rounding decision the system made. Decoding it back to 38 hours 25 minutes is how you check the front end of that pipeline, and this converter is the decode step.
It also explains why overtime thresholds, PTO balances and job-costing reports are all quoted in decimals. A PTO balance of 6.25 hours is 6 hours 15 minutes of leave; a job that consumed 112.5 labor hours consumed 112 hours 30 minutes. One consistent unit keeps the whole payroll stack — time clocks, schedulers, payroll, accounting — from having to translate at every boundary.
The 7-minute rule: how 29 CFR 785.48 shapes your decimals
In the United States, many employers round punch times to the nearest quarter hour under 29 CFR 785.48(a), the Department of Labor regulation behind the familiar '7-minute rule.' Under neutral rounding, punches in the first 7 minutes of a quarter count back to the quarter, and punches in the last 8 minutes count forward to the next one. A punch at 8:07 becomes 8:00; a punch at 8:08 becomes 8:15.
That rule is why so many paystubs show decimals that only take the values 0.00, 0.25, 0.50 and 0.75 after the whole hours. If every daily figure on your stub ends in one of those four fractions, your employer is quarter-hour rounding; if you also see 0.1, 0.3 or 0.6, they are rounding to the nearest tenth instead. The regulation permits either, with one firm condition: the practice must average out neutrally over time rather than systematically shaving minutes off employees.
Knowing the rule changes how you read a decimal. An 8.00 on the stub does not necessarily mean you clocked in at exactly 8:00 — it can mean you clocked in anywhere from 8:00 to 8:07 and were rounded back. When a disputed day matters, the converter helps you reconstruct both readings: take the actual punch pair, convert the true elapsed minutes, and compare against the rounded decimal the system recorded.
Tenths of an hour: the 6-minute billing increment
Lawyers, consultants and many professionals bill in tenths of an hour, and a tenth of an hour is exactly 6 minutes. Under that convention a 4-minute client call bills as 0.1 hours, a 13-minute contract review bills as 0.3 (13 ÷ 60 = 0.2167, rounded up to the next tenth), and a 47-minute deposition prep bills as 0.8. At a $350 hourly rate, that 4-minute call is a $35 line item.
Reading a legal invoice is therefore a decimal-to-time exercise. A statement showing 2.4 hours for 'motion drafting' is 2 hours 24 minutes of recorded work. Clients who audit invoices decode every line this way, and firms keep minutes-to-tenths strips by the keyboard for the same reason: 1–6 minutes is 0.1, 7–12 is 0.2, 13–18 is 0.3, and so on up to 55–60 being 1.0.
The increments also compound. Six entries of 4, 11, 13, 27, 38 and 47 minutes total 140 raw minutes — 2.3333 exact hours — but billed in 6-minute increments they become 0.1 + 0.2 + 0.3 + 0.5 + 0.7 + 0.8 = 2.6 hours. That 16-minute gap is the rounding-up system working as designed, and at $350 an hour it is a $93 difference on one ordinary day. Decoding billed tenths back into minutes is the first step in any fee dispute.
Construction and field service: the quarter-hour grid
Construction crews, trades and field-service businesses overwhelmingly report time on a quarter-hour grid: 0.25, 0.50, 0.75. A job ticket reading 6.75 hours means 6 hours 45 minutes on site; a service call logged at 2.25 hours is 2 hours 15 minutes. The quarter-hour is coarse enough to key in from a clipboard and fine enough that material and labor estimates stay honest.
The grid matters when jobs are billed through to customers. A contractor who quotes $85 an hour and works 5 hours 40 minutes converts to 5.6667 exact hours, but invoices 5.75 on the quarter grid — $488.75 instead of $481.67. Crews that time jobs in wall-clock terms (5h 40m) and bill in decimals need the conversion every single ticket, which is why the same contractor's office keeps a decimal chart taped near the invoice book.
It also cuts the other way: reading a bid. If a subcontractor's change order claims 14.5 labor hours, that is 14 hours 30 minutes — check whether the crew's timesheet supports half an hour of continuous work at that task, or whether quarter-rounding stacked up. Converting every claimed figure back to clock time is the fastest way to see whether the numbers describe real work.
Decoding a paycheck: what 38.42 really means
Take a realistic stub figure: 38.42 hours. The whole-number part is hours, and only the fraction converts — 0.42 × 60 = 25.2, so the week is 38 hours 25 minutes (the 0.2 of a minute is a rounding artifact of the two-decimal stub, not real time). Notice what would happen if you misread it as 38 hours 42 minutes: you would claim roughly 17 extra minutes of work, and at a $25 rate across a year of similar weeks that misreading compounds into real money.
The reverse check is just as useful. If you believe you worked 38 hours 25 minutes, converting forward should reproduce the stub: 25 ÷ 60 = 0.4167, which the payroll system's two-decimal display rounds to 38.42. If your forward conversion gives 38.28 instead, the discrepancy is either a rounding rule you have not accounted for, an unpaid break you forgot, or a punch that did not make it into the system — and now you know exactly what to ask about.
One more subtlety: some systems truncate instead of round, so 38.4299 prints as 38.42 while others round to 38.43. The difference is at most a fraction of a minute per week, but if you are reconciling totals across months, knowing whether the display truncates or rounds explains why your hand-added decimals drift slightly from the printed year-to-date figure.
Excel traps: why TIMEVALUE and SUM fight you
Excel stores time as a fraction of a day, not as hours and minutes — 6:18 is really the number 0.2625 hiding behind a time format. That single fact explains most spreadsheet pain. Add 7:45 and 8:30 with SUM and you may get 16:15, 0.68 or ###### depending on the cell format, because the underlying values (0.3229 + 0.3542) sum to 0.6771 of a day, and Excel decides how to display it based on formatting, not intent.
To convert a true decimal like 7.75 into an Excel time, the pattern is division: =7.75/24 turns the decimal hours into Excel's day-fraction and displays as 7:45 when the cell is formatted as time. Going the other way, multiply a time cell by 24 (=A1*24) to get decimal hours — and format the result as a plain number, or Excel will cheerfully display your decimal as a clock time again. TIMEVALUE("6:18 PM") produces the day-fraction for a clock time, not decimal hours, which is the step people skip.
Totals bring the third trap: a weekly sum of 45 hours 30 minutes displays as 21:30 instead of 45.5, because Excel's default time format wraps at 24 hours. The fix is the elapsed-time format [h]:mm, or converting with =SUM(A1:A5)*24 to decimal before formatting. Anyone who has stared at a payroll column that 'loses' 24 hours has met this wrap — the hours were never lost, they were displayed modulo a day.
Google Sheets: duration format done right
Google Sheets shares Excel's day-fraction time model but handles elapsed time more gracefully: its Duration format (Format → Number → Duration) displays 45:30:00 for 45.5 hours without wrapping at 24. Converting decimal hours to a displayable duration is still the same division — enter =7.75/24 and format the cell as Duration to see 7:45:00 — and converting a duration back to decimal hours is =A1*24, exactly as in Excel.
The common Sheets mistake is typing a duration like 7:45 into a cell formatted as time-of-day. Sheets interprets 7:45 as 7:45 AM, and later arithmetic quietly treats it as 0.3229 of a day. If a SUM of shift durations returns a clock-looking answer like 23:15 for what should be 47.25 hours, some cells are time-formatted rather than duration-formatted — reformat to Duration and the total snaps to 47:15:00.
Sheets also round-trips cleanly with time-tracking exports, which is why it anchors many payroll workflows: paste decimal hours from a report into one column, convert to =value/24 durations in another, and conditional-format anything over 8 hours per day. Both directions of that workflow are the same decimal-to-time conversion this page performs, just batched.
Cross-midnight shifts and the decimal hours that follow
A shift that runs 22:15 to 06:45 is 8.5 hours, but naive subtraction (6.75 − 22.15-style clock arithmetic) gives nonsense or negatives. The clock values must first be converted to a continuous timeline: 22:15 is 22.25 hours, 06:45 is 6.75 + 24 = 30.75 on the same timeline, and the difference is 8.5. Cross-midnight work is exactly where handwritten conversion attempts break, because the 'borrow a day' step has no obvious place in the arithmetic.
Once the elapsed duration is right, the decimal conversion is ordinary: 8 hours 30 minutes is 8.5. But payroll adds a wrinkle — some employers split overnight shifts at midnight for attendance or shift-differential purposes, so the same 8.5-hour shift might be recorded as 1.75 hours (22:15–00:00) plus 6.75 hours (00:00–06:45). Reading such a stub, the two decimals decode independently: 1.75 is 1 hour 45 minutes, 6.75 is 6 hours 45 minutes, and together they reconstruct the shift.
Night-shift premiums amplify the stakes. If the midnight-anchored portion earns a $2 differential and that portion is 6.75 hours, the premium is 6.75 × $2 = $13.50 — but only if the 6.75 is truly 6 hours 45 minutes and not a misread 6 hours 75 minutes or 6.075. Converting every differential-window decimal back to clock time before multiplying is the audit that catches those errors.
Overtime in decimal: the 40-hour FLSA threshold
The FLSA overtime threshold is 40 hours in a workweek, and under decimal reporting the judgment is direct: 39.75 hours is 39 hours 45 minutes — under the threshold, no overtime; 40.25 hours is 40 hours 15 minutes — a quarter hour into overtime, which must be paid at 1.5× the regular rate. The decimal display makes the threshold crisp precisely because hours are the unit the law is written in.
The subtlety is what feeds the 40. Regular rate calculations include nondiscretionary bonuses and shift differentials, so the 'hours' that cross 40 are often a decimal sum of daily figures, each possibly rounded. If a stub shows 40.25 and the daily entries sum to 40.18, the question is whether rounding happened per day or per week — and which rule the employer applied. Converting the daily decimals back to minutes is the way to see where the extra 0.07 of an hour (about 4 minutes) came from.
Overtime pay itself then lives in decimals: 0.25 overtime hours at a $24 regular rate is 0.25 × $36 (1.5×) = $9.00. Employees checking an OT line item decode the hours first — 2.5 OT hours is 2 hours 30 minutes — then verify the rate multiplication. Both steps are decimal-to-time and back, which is why this converter earns its place on a payroll clerk's bookmark bar.
A historical footnote: France's decimal day of 1793
The conversion on this page bridges decimal hours and sexagesimal time, but France once tried to abolish the bridge entirely. On 5 October 1793, revolutionary France decreed decimal time: a 10-hour day, 100-minute hours, 100-second minutes. Under that system the day ran from midnight (0h) to 10h, and 6.30 would genuinely mean six hours and thirty decimal-minutes — a world where this converter's ×60 rule would be wrong.
The experiment lasted barely seventeen months as mandatory law and lingered in some official contexts until 1801 or so. Clocks were made with dual faces, but the public never adopted decimal time for daily life: rebuilding every clock, almanac and habit in the country was a cost the Revolution's other crises outranked. The failure is instructive for our purposes — it shows just how entrenched the 60-based minute is, and why every modern 'decimal time' proposal stops at decimal hours rather than touching minutes and seconds.
It also explains a terminology trap. In decimal-time historical contexts, 'decimal hour' can mean one-tenth of a day (2.4 modern hours). In payroll and billing contexts — everything this site covers — 'decimal hour' simply means clock hours expressed as a base-10 fraction, where 2.5 is two and a half real hours. Same words, different quantities; the context of a timesheet versus an 18th-century almanac settles it.
Time-tracking apps: Toggl, Harvest and decimal exports
Time-tracking tools bridge clock time and decimal time daily. Toggl and Harvest both capture entries as start/stop durations but export decimal hours for invoicing and payroll — a Harvest invoice shows '2.75 hrs' for a 2-hour 45-minute block, and Toggl's detailed reports offer decimal totals per project and per user. The decimal is the format downstream systems (invoicing, payroll, budgets) accept, so the app does the conversion at the boundary.
Reading those exports is this converter's home turf. A weekly Toggl report showing 12.33 hours on a client is 12 hours 20 minutes (0.33 × 60 ≈ 20); a Harvest time sheet at 31.80 hours is 31 hours 48 minutes. Notice the recurring trap: 0.80 of an hour is 48 minutes, not 80, and reading 31.80 as '31 hours 80 minutes' overstates the week by more than half an hour.
Rounding policies flow through these exports too. Harvest can round entries to the nearest 6, 12 or 15 minutes for billing; Toggl reports raw durations to the second. So the same afternoon of work can export as 4.35 hours in one tool and 4.4 in the other, depending on whether the firm's billable convention rounds up in tenths. When two tools disagree, decode both decimals back to minutes before assuming either is wrong.
T&M invoices and the odd decimals nobody plans for
Time-and-materials (T&M) contracts — common in legal work, construction change orders, IT field service and government contracting — bill labor strictly by hours worked, and those hours are almost always stated in decimals. A T&M invoice line reading 'Senior technician: 7.35 hrs × $110' is 7 hours 21 minutes of billable time at $110 an hour, or $808.50. Because the customer pays for exactly the time recorded, every digit of the decimal is money: 7.35 versus 7.53 is a $19.80 swing on a single line.
The decimals also get strange at the edges. Some field-service systems accumulate time across many short visits and emit totals like 11.97 hours — 11 hours 58 minutes — which reads as if it were 'about 12' but is 2 minutes short, and billing rules may or may not round it to 12.0. Others emit values beyond 24 for multi-day engagements: 51.25 hours is 51 hours 15 minutes, not anything clock-like; the decimal is a pure duration and should be read as one.
Finally, negative-looking situations do occur in imports and corrections: an adjustment entry of −0.5 hours is a 30-minute credit against previously billed time. Decimal durations have no natural 'negative clock time' reading — the minus sign means reversal, not time before an epoch. Decoding the magnitude (−0.5 → 30 minutes) and reading the sign as 'credit' is the correct interpretation, and it is the last conceptual trap between you and reading any decimal-hours figure with confidence.
Payroll rounding rules: 6-minute versus 15-minute increments and their wage impact
Two rounding granularities dominate payroll: the 6-minute tenth (0.1 h) and the 15-minute quarter (0.25 h). The choice looks minor but creates measurable wage differences over time. With 6-minute rounding, the largest single-entry error is ±3 minutes — half the interval — while 15-minute rounding allows up to ±7 minutes per punch pair. Multiply those gaps across 260 workdays a year and a full-time employee can see annual wage discrepancies of 20 to 45 minutes under 6-minute rounding versus 60 to 100 minutes under 15-minute rounding, before any bias in the employer's favor enters the picture.
A concrete side-by-side shows the stakes. Suppose an employee clocks in at 8:04 and out at 16:52, a raw shift of 8 hours 48 minutes (8.8 exact hours). Under 6-minute rounding, 8 hours 48 minutes falls exactly on the 0.8 mark, so the decimal is 8.8 and pay is exact. Under 15-minute rounding, 8:04 rounds back to 8:00 and 16:52 rounds forward to 17:00, producing 9.0 hours — the employee gains 12 minutes. Now flip the sign: a shift of 8 hours 37 minutes (8:00–16:37). Under 6-minute rounding, 37 minutes rounds to 36 (nearest sixth), so the decimal is 8.6 = 8 h 36 min, losing 1 minute. Under 15-minute rounding, 16:37 rounds back to 16:30, so the decimal is 8.5 = 8 h 30 min, losing 7 minutes. That single 7-minute loss at a $20/h rate is $2.33 per day, or about $600 a year.
The legal requirement is neutrality, not precision: DOL guidance under 29 CFR 785.48 allows either increment as long as the rounding averages out over time — it must not systematically favor the employer. In practice, neutrality is hard to audit from a single stub. The correct approach is to collect 4–8 weeks of raw punch pairs, convert each to exact decimal hours, sum the exact totals, and compare against the sum of rounded decimals the payroll system recorded. If the rounded sum is consistently lower by more than a few tenths across the sample, the rounding rule may not be neutral and a wage-and-hour complaint is worth considering.
Common decimal-to-time errors on timesheets and how to catch them
The most pervasive timesheet error is treating the decimal part as if it were hundredths of an hour instead of a fraction of 60. An employee who writes 7.45 meaning 'seven hours forty-five minutes' has actually recorded 7 hours 27 minutes — a loss of 18 minutes per entry. At $22/h that is $6.60 per day and $1,716 per year. The fix requires nothing more than this page: type 7 hours 45 minutes into the converter, confirm the decimal is 7.75, and write that number instead. The symmetrical mistake appears in the other direction when someone writes 7.75 on a form that expects hours:minutes and the software interprets it as 7 hours 75 minutes — no such time exists, and most systems will reject it, but those that silently convert it treat the entry as 8:15, adding 30 minutes of phantom pay.
Boundary cases around the hour mark cause a disproportionate share of errors. The transitions 0.9 → 1.0 and 1.9 → 2.0 are the two places where rounding and carrying interact. A shift of exactly 59 minutes is 0.9833 decimal hours; rounding to one decimal gives 1.0, which looks like a full hour. A system that displays one decimal place will show 1.0 for any shift between 57 and 62 minutes — a six-minute window where very different actual times produce the same displayed decimal. Employees and supervisors reviewing totals should flag any whole-number decimal (1.0, 2.0, 3.0) and verify that the underlying punch pair really did round to exactly that value, especially when the rounded figure sits at or just above a threshold like 8.0 hours (overtime trigger) or 40.0 hours (FLSA weekly threshold).
Entry-order errors — logging the out-punch as the in-punch — produce nonsensical negative durations that most systems catch, but partial-day corrections introduce subtler problems. If an 8.5-hour entry is corrected by deleting 0.5 and re-entering 8.0, some platforms treat the correction as a new entry and sum both, reporting 16.5 hours. The audit check is to verify that the day total before and after a correction changes by exactly the intended amount, not that the corrected entry itself shows the right number. Expressing the check in decimal is simpler than in clock time: confirm that the day-level delta is −0.5 (or whatever was removed), not that any single field displays a target value.
Rounding boundary cases and the numbers payroll systems never print
Payroll software almost always displays two decimal places on stubs, but the underlying arithmetic uses more. A shift of 7 hours 23 minutes is 7.3833 repeating — the system stores 7.3833 or 7.38333 internally, multiplies by the rate to the cent, and only then rounds the dollar figure. Displaying 7.38 on the stub hides the fact that 7.38 hours × $20 would give $147.60 while the actual computation 7.3833 × $20 gives $147.67. The difference is 7 cents on one entry, but for a bi-weekly payroll processing 100 employees, sub-cent rounding across thousands of entries can shift payroll totals by several dollars before the payroll vendor's rounding policy kicks in.
The five canonical boundary decimals for quarter-hour rounding are 0.00, 0.25, 0.50, 0.75, and 1.00 (= carry). For 6-minute rounding they are 0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, and 1.0. The numbers that payroll stubs never print are the infinite decimals that fall between those boundaries: 0.4167 (25 minutes), 0.3667 (22 minutes), 0.5833 (35 minutes). If an employee's shift genuinely lasted 6 hours 25 minutes, they worked 6.4167 hours, but the stub will show either 6.42 (two-decimal truncation), 6.4 (one-decimal rounding), or 6.5 (quarter-hour rounding), depending on the employer's system. None of those matches the exact elapsed time, and none is 'wrong' by itself — the question is only whether the chosen rounding rule is consistently neutral.
A quick self-check: take any weekly total off a stub, multiply the decimal by 60, and verify the product is a whole number of minutes. If 38.42 × 60 = 2305.2, the 0.2 minutes is a display artifact of two-decimal rounding, not a real 12-second slice of time. Any decimal with more than two significant fractional digits visible on a stub signals that the system is displaying a partially-rounded value, and the true elapsed minutes may differ by up to 30 seconds per entry from the apparent figure. Knowing this does not change the legal validity of the paycheck, but it prevents futile disputes where an employee adds up stub minutes and gets a different total than the printed year-to-date — the apparent discrepancy comes from display rounding, not from missing time.