billable.devHourly invoice template
Billing hours is simple arithmetic that goes wrong in predictable places: inconsistent rounding, line items nobody can map to work, and totals that don't reconcile against an estimate. Here's the structure that gets hourly invoices approved without a reply, and a free generator that builds it in your browser.
The three columns that do all the work
An hourly invoice line needs exactly three numbers: hours, rate, and the product of the two. That sounds obvious, and it's still the thing most templates get wrong — they show a description and a total, leaving the reader to trust the arithmetic. A finance person who can't verify a total without emailing you will email you, and your invoice moves from the approve pile to the pending pile.
Show the multiplication. It costs one column and removes the single most common reason an hourly invoice sits unpaid for a week.
Pick a rounding increment and never vary it
Quarter-hours are the sensible default. They're granular enough that a 20-minute fix doesn't get billed as an hour, and coarse enough that you're not defending a 7-minute entry. Whatever you choose, the rule matters more than the number: the same increment on every line, on every invoice, for the life of the engagement.
Varying it is what causes trouble. If one invoice rounds up to the hour and the next bills 3.1 hours, the client notices the inconsistency rather than the work, and now you're discussing your billing practices instead of the project.
Write line items a non-technical approver can parse
The person approving your invoice usually did not do the work with you and often has no technical context. "Development — 32 hrs" tells them nothing except the size of the number. Group by deliverable and name the outcome:
- Checkout flow: payment retry handling and error states — 6.5 hrs
- Admin dashboard: order search and CSV export — 11 hrs
- Production incident 14 Aug: queue backlog diagnosis and fix — 3.25 hrs
Each line answers "what did we get for this?" before it gets asked. That is the entire job of an hourly invoice. If you're billing development work and your commits already describe the work, the git log import turns them into exactly this shape of line item.
Group by task, not by day
Time tracked across scattered sessions should be totalled per task before it reaches the invoice. Four half-hour blocks on the same bug across three days is one line reading 2 hrs, not four dated lines. A long list of small dated entries makes modest invoices look inflated and gives a reluctant payer four things to question instead of one.
Reconcile against the estimate, in the open
If the work was estimated, the invoice should make the comparison easy — because the client is doing it anyway. When you land under, say so; it buys more goodwill than the money costs you. When you land over, the overage belongs on its own labeled line with a short reason, and it should never be the first time the client hears about it. Approval for extra work is a conversation, not an invoice line.
Terms, and the part that actually gets you paid
Put the due date on the invoice as a date, not as "Net 30". Translating terms into a calendar day is one less step between reading and paying. Include the payment method with everything needed to use it, and the invoice number in the reference field so reconciliation on their end is automatic. More on this in net terms, deposits and late fees.
When hourly is the wrong model
Hourly billing caps your income at your calendar and quietly penalises you for getting faster. If you're consistently delivering the same category of work, fixed-price or a retainer usually pays better for the same output — the tradeoffs are worth reading before your next contract, and retainer invoices have a different structure worth knowing.
Build it in the browser
Billable is this structure as a working tool: hours and rate columns with the maths done for you, a live preview of the printed page, A4 PDF output, saved invoices, CSV import, and JSON export. Everything runs client-side, so your rates and client names never leave your machine.
Common questions
- What increment should I round hours to?
- Pick one increment, put it in the contract, and use it on every line. Quarter-hours (0.25) are the common default for project work and are granular enough that neither side feels cheated. Rounding to the nearest hour is simpler but starts arguments on short tasks; billing to the minute reads as pedantic and invites line-by-line challenges.
- Should I show my hourly rate on the invoice?
- Yes, if you bill hourly. Hiding the rate behind a lump sum is the fastest way to get an invoice queried. Showing hours times rate equals amount on every line lets a finance person verify the arithmetic without contacting you, which is usually what stands between you and same-day approval.
- Do I need to attach a timesheet?
- Usually not, if your line items are descriptive enough. A line that reads 'Checkout flow: payment retry handling and error states — 6.5 hrs' is its own timesheet. Attach the detailed log when the contract requires it or when the client's finance process asks for it, not by default.
- How do I invoice partial hours from several days?
- Group by task, not by date. Five scattered half-hours on the same feature belong on one line with the total, because the client is approving an outcome. Splitting them into five dated lines makes a small invoice look padded.
- What if I go over the estimate?
- Raise it before you invoice, never in the invoice. An overage that first appears as a number on a bill reads as a surprise charge no matter how justified the work was. If it's already happened, put the approved figure on the invoice and the overage on its own clearly labeled line with a one-sentence reason.
