Web Developer Invoice Template
Development invoices work best when they mirror how the work was scoped: build, integrations, deployment. Clients who can map the invoice to the proposal pay faster and dispute less.
This free template starts with hourly frontend work, API integration and a deployment line. Adjust the hours and rates, add tax if you charge it, and export a watermark free PDF straight from your browser. Everything stays on your device.
Open this template in the free generator →
No signup. No watermark. Runs in your browser.
What this template starts you with
| Description | Qty | Rate |
|---|---|---|
| Frontend development | 24 | 85.00 |
| API integration | 8 | 90.00 |
| Deployment and documentation | 3 | 75.00 |
What a good web developer invoice includes
- Hours per work stream rather than one total, so the invoice matches your estimate
- A line for deployment and documentation, which is real work and often forgotten
- What post launch support is included, stated in the notes
- Change requests as separate lines that reference the ticket or email that authorised them
- Third party costs such as licences and hosting passed through at cost on their own line
What to put on a web developer invoice
| Field | Example | Why it matters |
|---|---|---|
| Your business name, address and tax number | Byte Lane Ltd, VAT GB123456789 | Without a tax number the client's finance team may not be able to process the invoice at all. |
| Client entity and PO number | Northwind Retail Ltd, PO 8842 | In companies with procurement, the PO number is the difference between paid in two weeks and paid in two months. |
| Invoice number | 2026-031 | Unique and sequential, and worth matching to your project code so you can find it later. |
| Billing period or milestone | Sprint 4, 12 to 23 May | Tells the client which chunk of work they are approving, which is what they actually check. |
| One line per work stream | Frontend development, CMS setup, integrations | A single "development" line invites questions. Streams that match the estimate do not. |
| Hours and rate shown separately | 32 h at 85 | Lets the client verify the arithmetic themselves instead of asking you to. |
| Change requests as their own lines | CR-07 filter UI, approved 14 May | Keeps the original quote intact and makes extras visible rather than buried in a bigger number. |
| Pass through costs at cost | Font licence, 90 | Marked as a pass through so nobody assumes it is padding on your rate. |
| What support is included | 30 days of bug fixes from launch | Defines where the paid project ends and a support arrangement begins. |
| Deployment and handover | Deployment, DNS cutover, handover call | Real work that is routinely given away for free. Bill it as a line and it stops being invisible. |
| Payment details and late fee | Bank transfer details, late fee after due date | Include the reference you want the client to use so reconciling payments is not a guessing game. |
A small business website build, line by line
A realistic build invoice with the work split the way it was estimated. Amounts are placeholders in whatever currency you set in the generator.
| Line item | Qty | Rate | Amount |
|---|---|---|---|
| Technical discovery and estimate | 1 | 400 | 400 |
| Frontend development | 32 h | 85 | 2,720 |
| CMS setup and content migration | 10 h | 85 | 850 |
| Payment and CRM integration | 8 h | 95 | 760 |
| Accessibility and performance pass | 6 h | 85 | 510 |
| Deployment, DNS and monitoring setup | 3 h | 75 | 225 |
| Handover documentation and training call | 2 h | 75 | 150 |
| Total | 5,615 |
Two details do most of the work here. Integrations carry a higher rate than page building, because that is where the risk sits, and the last three lines are the ones developers most often absorb for free.
For a fixed price project, keep the same lines and replace the hours with milestone amounts. The point is that the client recognises the shape of the estimate, not that they can audit your timesheet.
Payment terms that work for developers
For project work, bill in milestones: a deposit to start, one or two payments as agreed chunks land, and the balance at handover. Never let the unpaid amount grow larger than you can afford to write off, and size the final milestone so it is small enough that the client has no reason to stall it.
For ongoing work, invoice on a fixed rhythm, every two weeks or monthly, and send it on the same date every time. Predictable invoices get approved without discussion. Irregular ones get read carefully.
Net 14 is normal for small clients and net 30 for anyone with a finance department. Put the calendar due date on the invoice, add a late fee clause, and ask for the PO number before you start rather than after you have sent the invoice, since a missing PO can hold up payment for weeks and is entirely avoidable.
Say what happens with access and credentials. A common approach is deploying to a staging environment during the build and transferring production access, DNS and repository ownership after the final invoice clears. Write it in the notes so it is a process, not a standoff.
Setting your rate
We do not publish rate tables here, because the figures floating around developer forums come with no methodology and are usually a mix of markets, seniorities and currencies. Build your number from your own costs and your own market.
Start with the floor. Take the annual income you need, add taxes, equipment, software, insurance and the unbilled time you spend on sales, admin and learning, then divide by the days you can realistically bill. Most independent developers land somewhere near half of the working year once holidays, gaps between projects and unpaid overhead are counted. Anything below that number costs you money to accept.
Charge different rates for different risk. Straightforward page building, integration work against a third party API you do not control, and emergency fixes on someone else's codebase are not the same job and should not carry the same number. The sample above prices integrations above frontend work for exactly that reason.
Raise the rate on new clients first, not existing ones. It is the lowest risk way to test a number, and within a year it becomes your normal rate without a single awkward conversation.
Common questions
Should I bill hourly or fixed price for development?
Hourly protects you on projects with moving requirements. If you quote fixed price, keep the line items but replace hours with milestone amounts.
How do I handle scope changes on the invoice?
Add them as separate line items referencing the change request. It keeps the original agreement clean and makes extras visible instead of buried.
How do I invoice for maintenance and support?
Separately from the build, on a fixed monthly amount for a defined scope, or an hourly rate against a pre agreed block of hours. Mixing support into a project invoice makes both harder to approve and makes it look like the project is still running.
Should I charge for the estimate or the discovery phase?
If it takes more than an hour and produces something the client keeps, such as a technical spec or an architecture proposal, charge for it. Paid discovery also filters out the clients who were never going to commission the build.
What do I do about hosting and third party licences?
Put them on the invoice as pass through lines at cost, or have the client buy them on their own account. Whatever you choose, do not bury them in your rate, because a surprise renewal charge a year later is worse than an itemised line today.
When should I hand over production access?
After the final invoice clears is the common arrangement, with the client working on staging until then. Say so in the notes at the start of the project so the handover is a scheduled step rather than a negotiation at the end.