billable.devWeb Development Invoice: Line Items That Get Approved
By Mark Fulton · 2026-08-19 · 12 min read
A web development invoice gets approved when every line tells the approver three things: what was delivered, over what period, and on what basis it was priced. "Development work, 40h" fails all three. "Booking flow build: date picker, availability API, confirmation email (40 hrs at $110)" passes all three, and it passes them for a finance person who has never opened your repo. The working rule is one line item per thing the client agreed to buy, worded the way the agreement worded it, with third-party costs in their own clearly labelled section and every row stating whether it is hourly or fixed.
Template pages hand you a blank grid with columns called Description, Quantity, Rate and Amount. The grid is the easy part. What decides whether the invoice clears in five days or sits in an approvals queue for three weeks is the text you type into that first column. Below is the actual wording, per project type, plus rewrites of the vague lines that cause the most friction.
What line items belong on a web development invoice?
Every line item is answering one question in the approver's head: did we agree to buy this? So the unit of a line item is not an hour and not a day. It is a unit of agreement. A milestone from the proposal, a change request that was approved by email, a named deliverable, a retainer period.
That gives you a simple test before you type anything: can the client point at a document, an email, or a conversation that this line corresponds to? If not, the line will generate a question no matter how you word it.
Here is copyable wording for the four project shapes that make up most web development billing. Swap in your own rates, dates and scope.
New build or redesign
| Line item wording |
|---|
| Design implementation: homepage, pricing and contact templates from approved Figma files (fixed, per proposal dated 2026-06-14) |
| Content model and CMS setup: 6 content types, editor roles, preview environment (fixed, per proposal dated 2026-06-14) |
| Responsive QA and cross-browser fixes: Safari, Firefox, Chrome, iOS Safari (8 hrs at $110) |
| Launch: DNS cutover, SSL, redirects from legacy URLs, analytics verification (fixed) |
API and payment integration
| Line item wording |
|---|
| Stripe integration: checkout session, webhook handler and refund endpoint, with retry on failed webhooks (fixed, per SOW section 3) |
| Shipping-rate integration: live rates at checkout for 3 carriers, with flat-rate fallback (fixed) |
| Sandbox to live cutover: credential rotation, live-mode smoke test, error alerting (3 hrs at $110) |
| Vendor API upgrade: move to v3 endpoints ahead of the provider's deprecation date (5 hrs at $110) |
Migration
| Line item wording |
|---|
| Content migration: posts and media library moved to the new CMS with slug parity (fixed) |
| Redirect map: 301 rules for retired URLs, verified against the crawl export (4 hrs at $110) |
| Post-migration verification: broken-link crawl, sitemap resubmission, Search Console coverage check (2 hrs at $110) |
| Legacy decommission: old host wind-down, final backup delivered to client storage (1 hr at $110) |
Performance and maintenance
| Line item wording |
|---|
| Largest Contentful Paint work: image pipeline (modern formats, lazy loading below the fold) and font preload (7 hrs at $110) |
| Database query optimisation: index on orders lookup, N+1 removal in the dashboard endpoint (5 hrs at $110) |
| Before-and-after report: lab and field measurements, delivered as PDF (1 hr at $110) |
| July retainer: content updates (9 requests), plugin and core updates, uptime monitoring (fixed monthly) |
Everything else on the document, the identity block, the numbering, the dates and the terms, is covered in what belongs on a software development invoice. This piece is only about the descriptions.
How specific should each line item be?
Specific enough that a stranger can match the line to something they agreed to buy. Short enough to read in a single pass. That is the whole target, and it is narrower than it sounds, because both failure modes are common: developers either write nothing ("Dev work") or dump a time-tracker export with forty two-minute entries.
The requirement is not just etiquette. UK guidance on what an invoice must include lists "a clear description of what you're charging for" alongside the invoice number, the supply date and the amounts. Most jurisdictions expect something equivalent. A description that only makes sense to you is not a clear description.
At larger clients the stakes go up, because a human is not reading your line at all first. Accounts payable teams commonly run a two-way or three-way match, comparing the invoice against the purchase order and, where relevant, a record of receipt. A university finance team's own invoice matching guide spells out the consequence: when the documents do not align, or a difference exceeds the tolerance, the invoice is held and the approve button is hidden until someone resolves the exception. Your job is to make the match obvious. Use the PO number they gave you, and use the same nouns their PO uses.
Here are the rewrites that do most of the work.
| Instead of this | Write this |
|---|---|
| Development work, 40h | Booking flow build: date picker, availability API, confirmation email (40 hrs at $110) |
| Bug fixes | Post-launch fixes: cart total rounding, mobile nav overlap on iOS, 500 error on password reset (6 hrs at $95) |
| Consulting | Architecture review and written recommendation: hosting, caching, deploy pipeline (fixed, delivered 2026-07-22) |
| Phase 2 | Milestone 2 of 4: payment integration, per proposal dated 2026-06-14 (fixed) |
| API work | Shipping-rate API integration: live rates at checkout for 3 carriers, with flat-rate fallback (fixed) |
| Meetings | Project calls and written updates, 1 to 31 July: 6 calls plus weekly status notes (5 hrs at $110) |
| Website updates | July retainer: content updates (9 requests), plugin and core updates, uptime monitoring (fixed monthly) |
| Extra work | Change request CR-03: multi-currency pricing, approved by email 2026-07-09 (12 hrs at $110) |
| Misc | (delete the line and put the work under the deliverable it belongs to) |
| Hosting | Pass-through: production hosting, 1 to 31 July, billed at cost, vendor receipt attached |
Notice what every rewrite adds: a named deliverable, a bounded period or a reference to the agreement, and an explicit basis of pricing. Notice also what none of them add: internal ticket IDs, branch names, or a story about how hard it was.
If you track work in commits, most of that specificity already exists in your history with timestamps attached. Turning it into descriptions is a mechanical job, and converting a git log into invoice lines is the fastest honest way to do it.
How do you bill mixed hourly and fixed work on one invoice?
Almost every real project ends up mixed: a fixed-price scope from the proposal, plus hourly change requests that arrived after it was signed. The mistake is letting both kinds sit in one undifferentiated list, where an approver cannot tell which numbers are locked and which are variable.
Split the invoice into labelled sections with their own subtotals, and make every row state its unit.
| Description | Qty | Rate | Amount |
|---|---|---|---|
| Fixed scope (per proposal dated 2026-06-14) | |||
| Milestone 3: account settings and billing portal | 1 | $3,200.00 | $3,200.00 |
| Milestone 4: admin reporting views | 1 | $1,800.00 | $1,800.00 |
| Approved change requests (hourly, $110/hr) | |||
| CR-04: SSO with Google Workspace, approved 2026-07-09 | 9 hrs | $110.00 | $990.00 |
| CR-05: CSV export on the orders table, approved 2026-07-18 | 4 hrs | $110.00 | $440.00 |
| Pass-through costs (billed at cost) | |||
| Managed hosting, 1 to 31 July, receipt attached | 1 | $58.00 | $58.00 |
Two habits make this section painless. First, get every change request approved in writing before you build it, and quote the approval date on the line. Second, if a change request is open-ended, agree a cap up front and say so on the invoice ("capped at 12 hrs, 9 used"). An approver who can see the ceiling does not need to go looking for it.
If you are still deciding which basis to use in the first place, hourly versus fixed price for developers works through the trade-offs. On the invoice itself, the answer is that both are fine as long as each row declares which it is. Billable's line items take hourly or fixed per row, so a mixed invoice does not need a workaround.
What wording makes clients question an invoice?
These are the patterns that reliably generate a reply asking for a breakdown, which is exactly the delay you are trying to avoid.
- Internal-only references. "PROJ-482" and "feature/checkout-v2" mean nothing to accounts payable. Translate to the outcome, or put the ticket ID in parentheses after a plain description.
- Suspiciously round totals. A line reading exactly "40 hrs" for a month of work invites the thought that the number was chosen rather than measured. If it genuinely was 40, break it into the days or features that add up to 40.
- Catch-alls. "Misc development", "sundry", "additional work". Every one of these is an invitation to ask what it was.
- Minute-level dumps. Forty entries of 6, 12 and 18 minutes look rigorous and read as unreviewable. Group by day or by feature instead.
- "As discussed". The client's finance team was not in the discussion. Name the thing.
- Silent rate drift. If your rate went up, the change belongs in an email before the invoice, not as a surprise on line four.
- Unlabelled tax lines. A line called "Tax" with no name or rate is a guaranteed question. Write the actual name and percentage.
- Work that appears for the first time on the invoice. Nothing should be a surprise. If you built it without a written go-ahead, expect to explain it.
How do you itemize third-party costs (hosting, plugins, APIs)?
Third-party spend is where otherwise clean invoices go wrong, usually because the cost is buried inside a labour line. Give pass-through costs their own labelled section, state whether you are billing at cost or with a markup, and attach or reference the vendor receipt.
| Cost | Line item wording |
|---|---|
| Managed hosting | Pass-through: managed hosting (production), 1 to 31 July, billed at cost, vendor receipt attached |
| Premium plugin licence | Pass-through: annual plugin licence, purchased in client's name on 2026-07-03, billed at cost |
| Transactional email | Pass-through: transactional email plan, July usage, billed at cost |
| Stock imagery | Pass-through: 6 stock images, extended licence, billed at cost |
| Domain renewal | Pass-through: domain renewal (2 years), billed at cost |
| Your setup time | Third-party setup: hosting provisioning, DNS, staging environment (2 hrs at $110) |
Three rules keep this section clean. Separate the cost from your labour on it. Provisioning a host is your billable time; the host's fee is not. Be explicit about markup. If you add a handling percentage, put it on the invoice as its own line rather than quietly inflating the vendor's number, because the client can look up the vendor's price. Put recurring services in the client's account and name where you can. Whoever holds the credit card holds the site, and a client who inherits a renewal they never authorised has a real complaint even when the amount is small.
Whether pass-through costs are treated as reimbursements or as taxable supplies varies by jurisdiction and by how your agreement is written. This is general information rather than tax or legal advice, and it is a good single question for an accountant when you start.
Frequently asked questions
Should each feature be its own line item?
Only when the client agreed to it as a distinct thing. Features that were part of one milestone belong on that milestone's line, named inside the description. A useful ceiling is roughly six to twelve lines for a monthly invoice: enough that nothing looks like a black box, few enough that the approver reads all of them. If you find yourself at thirty lines, you are itemising tasks rather than deliverables.
How do I invoice for meetings and communication time?
Bill it, and name it. Hidden communication time is the most common source of unbilled hours in freelance web development, and clients rarely object to a line reading "Project calls and written updates, 1 to 31 July: 6 calls plus weekly status notes (5 hrs at $110)". What they object to is discovering it inside a vague development line. If your agreement includes a set amount of included support, show it and zero it out ("Included support: 2 hrs of 2 used, $0"). Showing the value you gave away is worth more than silently absorbing it.
Do I list subcontractor work separately?
List the deliverable, not the org chart. Your client contracted with you, so bill "Illustration set: 12 custom icons for the marketing site (fixed)" rather than "Designer, 14 hrs". Naming subcontractors on the invoice raises questions about who holds the relationship and can complicate your own margin. Separately, if you pay contractors yourself, the reporting obligations sit with you: US payers should check the IRS guidance on reporting payments to independent contractors and equivalent rules elsewhere. Again, general information rather than advice. Confirm the current thresholds with your accountant, since they change.
How much detail is too much?
Detail becomes too much at the point where it invites negotiation on individual lines instead of approval of the whole. Minute-level time entries, internal debugging steps, and anything that reads as an apology ("re-did the header after the first approach failed") all cross that line. Keep the description at the level of the thing the client wanted to exist. One sentence per line, no wrap onto a third row, no explanation of why it took as long as it did. If the client asks for a deeper breakdown afterwards, you have your time log and your commit history and can produce it in minutes.
The generator on this site handles the structure so you can spend the effort on the wording: line items take hourly or fixed pricing per row, sections and subtotals for mixed invoices, and pass-through lines that stay separate from your labour. Nothing leaves your browser, and there is no account to create. Build your web development invoice free, or start from the free invoice template for developers if you would rather work from a filled-in example. If you want saved clients, custom branding and recurring invoices, Billable Pro is $4/mo billed $24 per 6 months, or $79 lifetime.