Billing in 15-Minute Increments: A Rounding Rule for Devs

Almost everything written about billing increments assumes you are a lawyer with a six-minute convention inherited from the profession. You are not, and your day looks different. A developer's hour is a mix of one long block of focused work and a scatter of three-minute Slack answers, quick deploys and "can you just look at this" pings. How you round that scatter decides whether the invoice feels fair or feels padded.

Here is the working rule, then the numbers behind it.

What does billing in 15-minute increments mean?

It means 15 minutes is the smallest unit you charge for, and anything past a boundary moves up to the next one. Work is recorded as a decimal fraction of an hour so the invoice math stays simple: hours times rate equals amount.

The same idea exists at finer grain. Billable hours are typically recorded in six-minute intervals in the legal world, which means tenths of an hour, and the Northern District of California's conversion chart shows the scheme in its plainest form: 1 to 6 minutes is 0.1, 7 to 12 is 0.2, and so on up to 55 to 60 minutes at 1.0. Quarter-hour billing is the same mechanism with bigger steps.

Here are both conversions side by side. Keep this table open while you build an invoice.

Minutes worked	Tenths (6-minute blocks)	Quarters (15-minute blocks)	Half hours (30-minute blocks)
1 to 6	0.1	0.25	0.5
7 to 12	0.2	0.25	0.5
13 to 15	0.3	0.25	0.5
16 to 18	0.3	0.5	0.5
19 to 24	0.4	0.5	0.5
25 to 30	0.5	0.5	0.5
31 to 36	0.6	0.75	1.0
37 to 42	0.7	0.75	1.0
43 to 45	0.8	0.75	1.0
46 to 48	0.8	1.0	1.0
49 to 54	0.9	1.0	1.0
55 to 60	1.0	1.0	1.0

All three columns round up to the next block. The tenths column matches the court chart above. The quarter and half-hour columns are the same rule at a larger step.

One more conversion worth memorizing: 0.25 on an invoice is 15 minutes. 0.5 is 30, 0.75 is 45. If your client reads "2.75 hrs" they should not have to do arithmetic to know it is two hours and 45 minutes.

Is 6, 15 or 30 minutes fairer for development work?

Fifteen is the best default for developers, six is the fairest to the client, and thirty is only defensible with a stated minimum for a specific kind of work.

Six minutes is the most precise and the most irritating to administer. A long day produces dozens of entries, and the invoice reads like a ledger of interruptions. It is also the grain that invites line-by-line questions, because every entry is small enough to argue about. It suits retainer work where the client wants a detailed audit trail and is happy to pay for the bookkeeping.

Fifteen minutes is the sweet spot for most project work. It is coarse enough that a day compresses into a handful of readable lines, and fine enough that a ten-minute task does not cost the client a half hour. Quarter hours also map to a clock face, which makes the invoice easy to sanity-check from a calendar.

Thirty minutes works as a minimum, not as the increment. "Emergency fixes and calls are billed at a 30-minute minimum" is a reasonable clause because those requests break your focus and cost you more than the clock shows. Billing everything at half-hour blocks is a different thing, and clients notice. A three-minute answer billed at 0.5 is an invoice they will query.

Whatever you choose, the principle is the same: the increment is a billing convenience, not a surcharge. The goal is an invoice the client can read without feeling that the rounding is where your margin comes from. If you are still working out the tracking side of this, tracking billable hours as a developer covers the log format that makes any increment easy to apply later.

Do you round each task or the day's total?

This choice moves the invoice far more than the increment does. Rounding each task and rounding the total are not interchangeable, and the gap grows with the number of small tasks you do.

Here is one realistic day for a contractor working on a single client's codebase. The rate is $100 an hour, which is just a round number for the example. Every row is invented to show the mechanics, not drawn from a real client.

Task	Actual minutes	Round up to 6 min	Round up to 15 min	Nearest 15 min
Standup call	12	12	15	15
Slack answer	3	6	15	0
Slack answer	4	6	15	0
Fix checkout redirect bug	47	48	60	45
Deploy hotfix	5	6	15	0
Slack answer	3	6	15	0
Review a pull request	22	24	30	15
Build the export feature	118	120	120	120
Slack answer	3	6	15	0
Quick staging deploy	4	6	15	0
Email the client	8	12	15	15
Slack answer	3	6	15	0
Total minutes	232	258	345	210
Hours	3.87	4.3	5.75	3.5
Amount at $100/hr	$386.67	$430	$575	$350

The same twelve tasks produce four different invoices. Rounding every task up to a quarter hour bills 5.75 hours for a day that contained about 3.87 hours of work, which is almost 50 percent more than the time spent. Rounding each task to the nearest quarter hour swings the other way and quietly gives away 22 minutes. Six-minute rounding stays close to the truth at 4.3 hours, but at the cost of twelve fiddly lines.

Now compare rounding the total instead of the tasks.

Method	Billed hours	Amount at $100/hr	Difference from actual time
Exact minutes	3.87	$386.67	none
Day total, up to 15 min (232 becomes 240)	4.0	$400	about 8 minutes
Day total, up to 6 min (232 becomes 234)	3.9	$390	2 minutes
Every task up to 6 min	4.3	$430	26 minutes
Every task up to 15 min	5.75	$575	113 minutes

Rounding the day's total up to the next quarter hour lands within eight minutes of reality. That is the argument for per-day rounding: you still get the protection of a minimum billable increment, but the rounding error happens once, not twelve times.

The rule that follows from the numbers is simple. Round at the level of the invoice line, not at the level of the interruption. If your invoice has one line per day, round the day. If it has one line per feature, round each feature's total. The finer the unit you round, the more the rounding compounds.

How do you bill a stream of 3-minute interruptions?

Do not bill them one at a time. Collect them into a named line and round that line once.

A day of Slack answers, quick deploys and one-line config changes is real work, and clients who rely on you for it should pay for it. The question is how to charge without producing a dozen 0.25 lines that make the client feel nickel-and-dimed. Three approaches hold up.

1. Batch by day or by week. Add the small items up and bill them as "Support and quick fixes, Oct 20: 0.75 hrs." In the example day above, the five Slack answers, two deploys and one email total 33 minutes. Rounded together they are 0.75 hours, not the 2.0 hours you get from rounding eight separate entries up to a quarter hour.
2. Set a floor with a named trigger. If a request needs more than a quick reply, such as opening the code, reproducing something or deploying, it becomes its own entry at the 15-minute minimum. Anything shorter goes in the batch. Put the trigger in the contract so it is a rule rather than a judgment call you make mid-week.
3. Move predictable interruptions into a retainer. If the same client pings you daily, a monthly block of support hours is cleaner than a river of tiny charges. Billing a retainer client covers how to word and invoice that arrangement.

A timer will catch some of this and miss the rest. The cheapest fix is to record the interruption the moment it ends, in the same log you use for everything else, and let the batching happen at invoice time.

Should you round up or to the nearest increment?

If you round to the nearest block, short tasks disappear. In the table above, the nearest-15 column turns seven separate small tasks into zero billed minutes, which gives away 25 minutes of real work on that day while the fix and the feature round close to their actual time. Over a month that pattern costs you money without anyone noticing.

If you always round up at the task level, you overcharge in the other direction, as the 5.75-hour result showed. Neither extreme is honest in both directions.

The combination that holds up is to round up, but at the line level, with a stated minimum:

• Round each invoice line (a day, a feature or a batch) up to the next increment.
• Apply a 15-minute minimum to any separate task that needs real context switching.
• Never round up a block you also bill somewhere else.

That last point catches people. If the 3-minute deploy is part of the feature you are already billing, it is not an extra entry. It is part of that feature's time.

Where do you state the increment?

State it in three places: the contract, the estimate or statement of work, and the invoice itself. A client who has read the rule twice does not read it as a surprise on the third.

A short clause is enough:

Time is billed in 15-minute increments (0.25 hours). Each invoice line is rounded up to the next increment. Requests outside the agreed scope that require separate attention carry a 15-minute minimum. Hours are recorded in a timesheet available on request.

That wording is general information, not legal advice. If a client's procurement team sends their own terms, run both sets past someone qualified before you sign. The same applies to how a billing rule interacts with other terms, which is why freelance contract payment terms is worth reading alongside this one.

On the invoice, put the rule in the notes line, for example "Hours billed in 0.25 increments, rounded per line." Show hours as a decimal in the quantity column, your rate beside it, and the amount on the right. If you attach a timesheet, group it the way the invoice groups it. What belongs on a software development invoice walks through the full set of fields a finance team will look for.

One practical note on software: most invoice tools accept hours as a decimal quantity, and the rounding itself is on you. In the free hourly invoice template, the hours field steps in quarter-hour increments, so a 2.75 entry is one click away from a 3.0.

Frequently asked questions

Is rounding up every task honest?

It is honest only when the client agreed to it and the effect is small. Rounding every task up to 15 minutes inflated the example day by almost 50 percent, which is hard to defend as a fair reading of the time spent. Rounding each line or the day's total keeps the error to a few minutes. Whatever you do, write it into the contract so the client is agreeing to a rule, not discovering one.

What is 0.25 hours on an invoice?

It is 15 minutes. The decimal is a fraction of a 60-minute hour, so 0.25 is a quarter, 0.5 is 30 minutes and 0.75 is 45 minutes. At $100 an hour, a 0.25 line is $25. Put the decimal in the quantity column and your hourly rate beside it so the client can check the multiplication.

Will clients accept a 30-minute minimum?

Many will for a defined category such as emergency requests or after-hours calls, because the premium is easy to explain: those requests interrupt other work. A blanket 30-minute minimum on every task is a harder sell, because it turns a 4-minute answer into a charge that looks arbitrary. State the minimum where it applies, tie it to a trigger, and offer a retainer if the same client keeps hitting it.

Should I round to the nearest increment or always up?

Always up, but at the line level rather than the task level. Rounding to the nearest block erases short tasks entirely, which is how a day of small interruptions ends up unbilled. Rounding the line total up to the next block keeps the minimum-increment protection while limiting the error to one rounding step per line.

---

Quarter hours go in as 0.25 quantities. When you are ready to turn the day's rounded hours into a document, build the hourly invoice free at billable.dev. It runs in your browser, with no account, and your data stays on your machine.