The decimal hours calculator payroll actually needs
Timesheets and payroll systems rarely add 7 hours 45 minutes and 8 hours 30 minutes directly — they expect decimal hours, such as 7.75 and 8.5. This decimal hours calculator converts between clock notation and decimal hours in both directions, so you can check a timesheet, verify a paycheck, or fill in a billing system without doing arithmetic in your head. Type on either side of the converter and the other side updates instantly.
The math is simple but easy to get wrong under time pressure: minutes are a sixtieth of an hour, so 15 minutes is 0.25, 30 minutes is 0.5, and 45 minutes is 0.75. Instead of memorizing fractions or trusting mental math at the end of a long shift, let the calculator do the division and give you an exact, payroll-ready decimal every time. The stakes are real: at a $22 hourly wage, misreading 7:45 as 7.45 instead of 7.75 costs 0.3 hours — $6.60 — every single day, which is over $1,700 a year for a five-day worker.
That example is not hypothetical. The single most common decimal-time mistake is treating the minutes part as if the decimal worked in hundredths like money. In clock notation the colon divides hours from sixtieths; in decimal notation the point divides hours from sixtieths too, but written as a fraction. Once the sixtieth relationship clicks, every conversion on this page is the same one operation, repeated.
How 7:45 becomes 7.75 — the hand calculation, step by step
Working one example by hand is worth more than reading ten explanations, so here is the full conversion of 7:45 with nothing hidden. Step one: keep the hours whole — 7 stays 7. Step two: take the minutes, 45, and divide by 60, which gives 45 ÷ 60 = 0.75. Step three: add the two pieces together, 7 + 0.75 = 7.75 decimal hours. That is the entire procedure, and it never changes no matter how large the numbers get.
A harder example shows where people stumble. Take 8:23. The hours are 8. The minutes give 23 ÷ 60 = 0.383333..., which is where you decide how many places to keep: payroll convention is two or four decimals, so 8.3833 rounded for display becomes 8.38. Notice the trap in the middle step — 23 minutes feels like it should be 0.23 of an hour, but it is actually closer to 0.38, because a minute is bigger than a hundredth of an hour. Six minutes is exactly 0.1 of an hour, so any minute count divisible by six converts to a clean terminating decimal: 12 minutes is 0.2, 18 is 0.3, 24 is 0.4, 36 is 0.6, 48 is 0.8.
The reverse direction runs the same logic backwards and is the one people need on payday. A pay stub showing 37.52 hours converts back like this: keep the 37 whole hours, take the 0.52 and multiply by 60, getting 31.2 minutes — so 37.52 is 37 hours 31 minutes (the 0.2 of a minute is display rounding, not real time). Multiplying by 60 instead of dividing is the only difference between the two directions; everything else is identical.
Rounding is where exact math and payroll policy part ways. 23 minutes is exactly 0.3833 hours, but many employers round punches to the nearest quarter hour first — 8:23 becomes 8:30, which converts to a clean 8.5. Other systems round the final decimal to two places and leave it at 8.38. Both are legal, both are common, and neither matches the exact 8.3833 this calculator shows. Knowing the exact value first lets you tell the difference between a rounding policy and an error.
Three paycheck calculations, worked in full
A retail associate works Monday through Friday: 8:15, 7:45, 8:30, 8:00 and 7:50. Converting each shift: 8 + 15/60 = 8.25, 7 + 45/60 = 7.75, 8 + 30/60 = 8.5, 8.0, 7 + 50/60 = 7.8333. Weekly total: 8.25 + 7.75 + 8.5 + 8.0 + 7.8333 = 40.3333 decimal hours. All 40.3333 hours fall within a single workweek, so FLSA overtime kicks in on the 0.3333 excess: 40 hours at $17.50 = $700.00, then 0.3333 × $17.50 × 1.5 = $8.75. Gross pay: $708.75. Had the associate written 8.15 for 8:09 on Wednesday instead of 8.5, the week would show 40.1667 and the overtime calculation would still trigger, but the straight-time base would be $5.25 short — a discrepancy a manager catches instantly when the converter is on-screen.
A home-care aide in California works a 12-hour shift on Saturday: clock-in 07:00, clock-out 19:15, with a paid 15-minute rest and a 30-minute unpaid meal. Elapsed time is 12:15. Subtract the unpaid 30 minutes: 11:45 paid. Convert: 11 + 45/60 = 11.75 decimal hours. California Labor Code § 510 applies: the first 8 hours are at the regular rate of $21.00, hours 8 through 12 are at 1.5×, and anything beyond 12 hours is at 2×. So: 8 × $21.00 = $168.00, plus 3.75 × $31.50 = $118.13. Saturday is already a seventh consecutive workday, which triggers all-day 1.5× under § 510(a), but only if the prior six days were worked — a payroll clerk confirms that from the punch log, not from the decimal alone. Total for the shift: $286.13. The decimal conversion is just the first step; the rate structure is where real errors hide.
A freelance UX designer bills three clients in a single week. Client A: two sessions of 1:45 and 2:10, billed in 0.25-hour increments — 1 + 45/60 = 1.75, 2 + 10/60 = 2.1667, rounded up to 1.75 and 2.25, total 4.0 hours at $110 = $440.00. Client B: one 3:20 session at the same 0.25 increment — 3 + 20/60 = 3.3333, rounded up to 3.5 hours at $95 = $332.50. Client C: four short async sessions of 0:20 each — 0.3333 per session, rounded up to 0.5 per session × 4 = 2.0 hours at $75 = $150.00. Week total: 4.0 + 3.5 + 2.0 = 9.5 hours, $922.50. The same conversion runs every row, but the rounding policy differs by client contract — three different increments, three different totals, all traceable back to the same 60-second minute.
Weekly totals and the 40-hour overtime line
Adding a week's worth of clock times by hand creates a carry problem: minutes overflow at 60, not at 100, so the column addition requires a modular correction at every digit. Add Monday's 8:45, Tuesday's 7:50 and Wednesday's 8:35 and the column reads 24:130 — subtract 120 to carry 2 hours, leaving 26:10, then add Thursday's 8:20 to get 34:30, then Friday's 8:15 to reach 42:45. In decimal: 8.75 + 7.8333 + 8.5833 + 8.3333 + 8.25 = 41.75. No carry, no modular correction, no intermediate conversions — plain addition gives the right answer in one pass. The weekly overtime threshold of 40 hours is 40.0000 in decimal, and the converter above shows each day's exact value, so the running total is visible before Friday's last punch.
The 40-hour line is not hypothetical for people who work variable shifts. A week that totals 39.9833 hours — two minutes short of 40:00 exact — clears the threshold under quarter-hour rounding and becomes 40.00, triggering overtime at 1.5× the regular rate on 0.0 hours of excess after rounding, or on 0.0167 hours exact. The same weekly total under a nearest-5-minute rounding rule stays at 39:55 and straight time. The difference between the two rounding rules can be $0 or $0.50 in a given week, which seems small — but if the employer's rounding consistently pushes workers below 40 rather than averaging on both sides, the Department of Labor's Wage and Hour Division has found systematic underpayment in precisely this pattern. Knowing the exact decimal before rounding is the one check that makes the discrepancy visible.
For workers in states with daily overtime — California and Alaska require 1.5× after 8 hours in a single workday, not just after 40 in a week — the per-day decimal matters as much as the weekly total. A 9.5-hour Monday means 8 straight-time hours plus 1.5 overtime hours, regardless of how the rest of the week plays out. Running the daily conversion each night, rather than waiting to total on Friday, catches the overtime accrual at the moment it happens rather than the moment payroll closes. The <a href='/time-card-calculator'>time card calculator</a> handles the full seven-day picture; this converter handles the single-day check. Both use the same 60-second arithmetic; the only difference is how many rows you fill in.
Time tracking apps: export formats and decimal reconciliation
Toggl Track, Clockify, Harvest and Everhour all export time entries as CSV or spreadsheet files, and none of them agree on a single format. Toggl's default CSV uses HH:MM:SS duration strings in a column labeled Duration; Harvest's export offers a decimal Hours column by default, though the raw-data CSV also includes a Start Time and End Time in ISO 8601 format. Clockify's CSV uses HH:MM duration strings and also gives start/end timestamps. The practical consequence: a Toggl export pasted into a billing spreadsheet needs the HH:MM:SS column converted to decimal before any math can happen, while a Harvest export usually plugs straight in. Clockify sits in between — the column is formatted like a clock but is actually an interval, so the ×24 trick that recovers decimal hours from Excel's internal time format does not work here. The reliable path is to use a purpose-built converter and treat every time-tracking export as an HH:MM input until the decimal output is confirmed.
Reconciling a time-tracking app against a payroll system's stub requires putting both in the same unit. The app total is usually a decimal (Harvest) or needs to be converted to one (Toggl, Clockify); the stub is always a decimal. Once both show the same format, a simple subtraction reveals the gap: if the app says 42.3333 hours and the stub says 42.00, the payroll system rounded down by 0.3333 hours — 20 minutes at the regular rate. Identifying which rounding rule produced that gap — quarter-hour, nearest-5-minute, or none — requires checking individual daily entries rather than just the weekly total, because the same net rounding can arise from different patterns. A daily column in the tracker, converted here, compared to the daily stub column makes the pattern visible in a few rows rather than a few hours.
For teams using Jira or Linear with logged work hours, the hour-logging fields typically accept decimal input directly. A developer who logged "1h 40m" in Jira expects to see 1.67 in any downstream report — but some integrations format it as 1.4 (treating the 40 as a decimal fraction rather than minutes) or as 100 (treating it as minutes). Each of those is a different conversion bug, and none of them surfaces until a payroll or billing export is audited. The safest practice is to log in whole or quarter-hour decimals at the source — 1.5, 1.75, 2.0 — so that the input format is unambiguous and the export needs no translation. Where legacy systems force HH:MM input, a one-column convert-on-paste workflow using this page keeps the downstream decimal clean. All three companion tools — the <a href='/minutes-to-decimal-hours'>minutes chart</a>, the <a href='/decimal-time-conversion-chart'>conversion chart</a>, and the <a href='/time-card-calculator'>time card calculator</a> — accept or display decimal hours, so any entry converted here travels cleanly through the entire toolkit.
Why employers and freelancers both bill in decimal hours
Companies like ADP, QuickBooks, Harvest and nearly every time-and-attendance system store worked time as decimal hours because multiplying a decimal by an hourly rate is one-step math: 7.75 hours at $20 an hour is exactly $155. If you are an employee comparing your paycheck stub against your own records, or a freelancer invoicing a client, converting HH:MM to decimal is the bridge between what you tracked and what the system calculated.
This page is also a sanity check. If your timesheet says 42.25 hours but your notes add up to 41:45, one of the two was rounded or mistyped. Convert both numbers to the same format here and the discrepancy surfaces in seconds — before it becomes a payroll dispute. The same check works in the other direction for anyone who bills clients: an invoice that says 6.75 hours can be read back as 6:45, and clients who verify line items convert with exactly this method.
The economics of the format choice are the real reason decimals won. Clock notation cannot be multiplied directly — no payroll engine can compute 7:45 × $22 without converting first, because time-of-day notation has no meaningful product. Decimals plug straight into a multiplication, a SUM formula, or a database column of type DECIMAL. Every system that touches wages — the time clock, the scheduling tool, the payroll processor, the GL export — inherits the format decision made at the first step, which is why the decimal habit spread everywhere money meets hours.
Decimal time before the computer: 1793 and the ten-hour day
The idea of dividing the day decimally is older than payroll software by two centuries. In October 1793, Revolutionary France decreed that each day would have ten hours, each hour one hundred minutes, and each minute one hundred seconds. French Republican clocks were manufactured with faces numbered 1 to 10, government offices adopted them, and midnight to noon took five decimal hours instead of twelve. Under that system, what we call 6:00 AM was 2.5 decimal hours, and noon — the anchor of the whole system — was exactly 5. The commission behind it included some of the same mathematicians who gave France the metric system, and the ambition was the same: strip medieval counting units out of daily life.
The ten-hour day failed on a physical fact — the decimal second was 1.4 conventional seconds, so old clocks could not be reused, and the new units fit no human rhythm. By April 1795 the law was suspended, and Napoleon formally abandoned decimal time in 1806. But the decimalized pieces that survived are everywhere: the metric system for everything except time, and, in payroll, the compromise this page implements — keep the 24-hour day and the 60-minute hour, decimalize only the part that touches arithmetic. France had proved the fully decimal day was possible; two centuries of timesheets proved the half-measure was more practical.
The dream kept resurfacing. In 1998 the Swiss watchmaker Swatch launched Internet Time, dividing the day into 1000 .beats of 86.4 seconds each, counted from a world-reference meridian (@000 at Biel midnight, @500 at noon) so that everyone on the planet shared the same time value. Swatch sold watches with a beat scale, and a few websites displayed @-time for online meetings. It never displaced time zones, but the arithmetic is a direct descendant of 1793 — a fixed decimal slice of the day — and it fails for the same reason: people meet at 2:30 in the afternoon, not @625. Stardate in Star Trek is fictional, but the writers' various schemes for it kept running into the same wall: a decimal day counter reads beautifully and translates into human schedules terribly.
Where decimal day-counting did stick is astronomy. The Julian Day system, running continuously since January 1, 4713 BC, counts days with a decimal fraction appended — JD 2460000.5 is noon on a specific date, and the .5 exists precisely so that the day boundary falls at midnight rather than noon. Astronomers convert observation timestamps to Julian Dates because the decimal fraction makes interval arithmetic trivial: subtract two JDs and the difference is the elapsed time in days and decimal fractions of a day, no calendar, leap year, or time zone involved. It is the one field where a full decimal day won outright, and for exactly the reason payroll decimals won — subtraction and multiplication need plain numbers.
The seven-minute rule: 29 CFR 785.48
United States wage law gives employers a specific allowance for rounding punches, and it is written down at 29 CFR § 785.48. The regulation permits recording employee starting and stopping times to the nearest 5 minutes, or the nearest tenth or quarter of an hour, provided the practice averages out so it does not systematically underpay. Its own worked example is where the famous seven-minute rule comes from: under quarter-hour rounding, time from one to seven minutes past a quarter may be dropped, while eight or more minutes must count as the full quarter.
Concretely: an employee punching in at 8:07 is paid from 8:00 — those 7 minutes round down. A punch at 8:08 is paid from 8:15. On a time card, that means a raw 7:52 punch converts to 8.00 rounded but 7.8667 exact; a raw 7:53 becomes 8.00 either way. Over a year of daily punches, the difference between the exact and rounded values is usually a wash — which is the neutrality condition the regulation demands — but the wash only happens if the rounding is symmetric. Schemes that round down on every arrival and round down on every departure have been struck down in wage cases precisely because they fail the averaging test, even though each individual rounding looked trivial.
The practical takeaway for anyone reading their own timecard: compute the exact decimal first, apply the stated rounding rule second, and compare the two week after week. If the rounded totals keep landing below the exact ones by more than chance, the rounding is not neutral, and the exact values from this calculator are the evidence. Employees near the 40-hour overtime line have an extra reason to run this check, since a single rounding decision at week's end can move a 39:59 total above or below the threshold — 39.9833 exact rounds to 40.00 under quarter-hour rules and triggers overtime, while a nearest-5-minute rule keeps it at 39:55 and straight time.
How payroll software handles decimal input
Open any modern payroll product and the hours field is a plain number box, not a clock picker. QuickBooks asks for 7.75; Gusto and Rippling validate the same way; ADP's timesheet grid stores two-decimal values. The reason is boring and decisive: payroll is multiplication, and multiplication happens on numbers. Some systems accept 7:45 in the box and convert it silently — QuickBooks Time does this, showing both formats — but the stored value underneath is always the decimal, because the wage calculation (hours × rate), the overtime split (hours above 40 × 1.5 × rate), and the tax prorations all consume that single number.
That silent conversion is worth understanding, because it explains a class of paycheck mysteries. Enter 7:45 in a field that does not parse colons and the system may keep only the 7 — a 45-minute loss every day it goes unnoticed. Enter 7.75 in a field that expected clock notation and some systems read it as 7:75, an impossible time, and either reject or clamp it. When a weekly total looks wrong by 0.5 or 0.75 hours, the first thing to check is which format the field wanted, and the second is whether the decimal matches what your punch times actually produce — both checks take seconds with the converter above.
The software convention has a legal shadow, too. Some US states — California is the well-known example — require recorded time in clock notation on the wage statement even though payroll computes in decimals, because disputes are argued in punch times. The result is that California stubs show both: the 8:12-to-16:45 punches and the 8.55 decimal that drives the dollars. Anyone comparing the two lines is doing exactly the bidirectional conversion this page performs, and the two figures will only agree if the employer's rounding policy sits between them.
Reading a pay stub: turning 80.00 and 79.92 back into time
Most US pay stubs carry a line labeled Regular Hours, REG HRS or Current Hours, and it is always decimal. A stub reading 80.00 means two clean 40-hour weeks; 79.92 means 79 hours 55 minutes were counted — 0.08 of an hour is under five minutes, the kind of gap created by a rounding rule or a missing punch. Multiply the decimal by 60 on the fraction part and the stub speaks in real time again: 0.92 × 60 = 55.2, so 79.92 is 79:55 to the minute.
Overtime usually appears on its own line as OT Hours or O.T. HRS, also in decimal, and multiplying that figure by 1.5 times your rate is the fastest sanity check on the overtime dollars above it — 4.75 OT hours at a $24 rate should be $171.00, and if the stub shows $166, something between the hours and the dollars got adjusted. Some employers add a third line for double time at holiday rates. When the printed decimal does not match the hours you believe you worked, this calculator converts their figure back to minutes so you can say precisely which punch is in dispute rather than arguing over an unfamiliar decimal.
Paid-time-off lines follow the same convention and deserve the same scrutiny. A stub with 8.00 PTO hours next to 32.25 Regular means a day off was recorded plus four days worked — but 32.25 is 32:15, not 32:25, and checking that detail before the pay cycle closes is a two-minute job with the converter. Salaried-exempt workers occasionally see decimals too, when partial-day PTO is deducted in tenths or hundredths; 0.15 of an eight-hour day is 72 minutes, a number most people would never guess from the decimal alone.
Spreadsheets, CSVs and the 7:45 paste trap
Excel and Google Sheets interpret values containing a colon as times of day and everything else as plain numbers, and that single parsing rule causes most decimal-time chaos in spreadsheets. Type 7:45 into a cell and the sheet stores it as a fraction of a day — about 0.3229 — formatted as a clock. Multiply it by a rate and you get nonsense, because the sheet thinks you worked a third of an hour. The fix is either multiplying the cell by 24 once to recover true decimal hours, or never letting clock notation into the sheet at all: paste 7.75 and it stays a clean number.
CSV exports from time-tracking apps make this trap invisible, because the file itself is just text — 7:53 in a CSV is neither a time nor a number until a spreadsheet opens it and decides. A payroll import fed raw clock strings may reject the file or, worse, interpret 7:53 as a date in some locales. The reliable workflow is to decide which side owns the conversion before any transfer: convert punch times to decimals here, paste the decimals, and format the column as plain numbers. Totals over 24 hours need Excel's [h]:mm format if they must display as time — plain hh:mm wraps at 24, so a 27-hour week shows as 3:00, a classic end-of-month surprise.
One paste-level detail catches even careful people: pasting 7:45 into Excel converts it to a time, but typing 7.75 keeps a number, and the difference stays invisible until a SUM or VLOOKUP crosses the boundary between the two kinds of cells. Mixed-format sheets produce some rows right and some rows wrong, with errors nobody can reproduce on request. A column of =A2*24 next to the suspects shows instantly which cells were parsed as times — the ones that return sane values were numbers all along.
How to use the converter
Enter hours and minutes on the left to get decimal hours on the right, or type a decimal like 6.75 on the right to see it as 6 hours 45 minutes on the left. Everything runs locally in your browser: nothing is uploaded, no account is needed, and results appear as you type. On a phone the layout stays one-column and the inputs are large enough to use one-handed.
For the numbers people look up most often, the companion pages cover the full 0–60 minutes quick chart and a complete decimal time conversion chart from 0:15 to 12:00 in 15-minute steps. If you want to total a whole week and estimate gross pay, the time card calculator adds seven days of entries and multiplies by your hourly rate. Each page covers one slice of the same conversion, so the anchors you memorize here — 15 minutes is 0.25, 6 minutes is 0.1 — carry across all of them.