Should I bill hourly or fixed-price as a freelance developer?

Hourly works best when scope cannot be fully defined upfront — most ongoing engagements, integration work, and architecture-heavy tasks. Fixed-price works best when scope is clear, deliverables are bounded, and the client wants budget certainty. Sprint-based billing (a fixed price per 2-week sprint) is a useful middle ground that protects both sides without locking either into an all-or-nothing commitment.

How detailed should my time tracking be on the invoice?

For hourly invoices, the invoice itself should show summary totals (e.g. "Sprint 14, 38.5 hrs"), but most enterprise clients require an attached timesheet that breaks hours down by ticket, day, or feature. For sprint-based or fixed-price invoices, time detail is optional — the deliverable is what is billable, not the hours.

When does my client legally own the code I delivered?

Standard practice is that intellectual property transfers from the developer to the client upon receipt of full payment, not on delivery. This should be in your contract, and the invoice should reference it. Until full payment clears, the client has a temporary licence to use the code but does not own it. This trigger gives both sides a clean dispute mechanism if payment is delayed.

Should I charge for cloud and tool costs separately, or include them in my rate?

Charge them separately as pass-through line items, typically with a small management margin (5-15%) on top of the actual cost. This is cleaner for tax (pass-through is not your revenue), keeps your hourly rate transparent, and avoids the situation where AWS costs spike unexpectedly and erode your effective rate.

What is a fair day rate for freelance development in 2026?

It varies wildly by region, specialisation, and seniority — but as a 2026 reference point, mid-level full-stack developers in Western Europe and the US typically charge €600-1,200 per day, senior specialists (security, ML, distributed systems) €1,000-2,500 per day, and junior or near-junior developers €300-600 per day. Day rates assume 6-7 productive hours; if you are billing 8+ hours per day you should be on hourly, not a day rate.

Should I bill in my client’s currency or my own?

Bill in the currency that is most natural for your client unless your contract specifies otherwise. Use a payment service that handles FX conversion (Wise, Stripe) so you receive the correct amount in your home currency. The exception is when your costs (software subscriptions, cloud) are in a different currency from the invoice — in those cases, bill in the cost currency to avoid FX risk eating your margin.

Free Invoice Template for Freelance Developers — 2026 Guide

Developer invoices get burned three predictable ways: vague time tracking, silent scope creep, and unclear code ownership. A 2026 walkthrough with a free template.

Freelance developers get burned at the invoicing stage in three predictable ways: time-tracking detail that the finance team rejects as too vague, scope creep that never makes it onto an invoice, and contracts where it is unclear at what point the client legally owns the code that was delivered. None of these are coding problems. They are document problems, and a well-structured invoice solves all three.

This is a 2026 guide to freelance developer invoices — what to include, how to handle the hourly-vs-fixed question, what code ownership clauses to reference, and a free template you can use in under 60 seconds.

Why developer invoices look different from other freelance invoices

Developer engagements split into roughly four shapes, each of which produces a different kind of invoice:

Hourly contract — billed weekly or biweekly, line items by ticket / pull request / day
Sprint-based — fixed price per sprint (typically 2 weeks), one invoice per sprint cycle
Fixed-price project — milestones tied to delivery (50/50 or 33/33/33)
Retainer — recurring monthly fee for guaranteed availability, with overages billed separately

The structure of your invoice should mirror the structure of the deal. A retainer client wants to see "Retainer May 2026 — 40 hrs", not 40 individual ticket line items. A fixed-price client wants to see milestone deliverables, not hourly breakdowns. Mismatching these is the single most common reason developer invoices stall in finance.

12 things every freelance developer’s invoice must include

The first 8 are universal; 9-12 are developer-specific.

1. Your business name and tax information

Top of the invoice. Full legal/trading name, address, email, and tax/VAT number where applicable. For US developers working with US clients, your EIN or SSN may also be required (typically captured on a W-9, not the invoice itself). If you bill internationally, your VAT number and a note about reverse-charge status (for EU B2B) protects both sides from compliance issues.

2. Unique invoice number

Sequential. INV-2026-001, INV-2026-002. Do not restart, do not skip. If you have many clients, a client prefix (ACME-001) helps your own bookkeeping. Many countries legally require sequential invoice numbering for tax purposes, and a gap can trigger an audit question.

3. Issue date and due date

Both, in unambiguous format ("10 May 2026", not "10/05/2026"). Specify a calendar due date rather than "Net 30" — clients pay specific dates more reliably than relative phrases.

4. Client legal entity and billing address

Bill the legal entity (the company), not your contact person. For startups your contact may be the founder; the invoice still goes to "Acme Inc., …", not "Sarah Founder". For larger clients, confirm the AP email address and any required PO number before sending.

5. Engagement reference and PO number

Include the contract or statement-of-work reference, and any PO number the client uses. For any client over ~50 employees, missing PO numbers are the most common reason invoices get rejected. If the client says "no PO needed", get that in writing in advance.

6. Itemised line items by engagement type

Hourly contract:

Sprint 14 work (2026-04-29 → 2026-05-12), 38.5 hrs × €95 — €3,657.50
After-hours emergency response (2026-05-03), 2 hrs × €142 — €284
Tooling: AWS sandbox account, May — €87
Total — €4,028.50

Sprint-based:

Sprint 14 (2026-04-29 → 2026-05-12), agreed scope: payment service migration
Fixed sprint fee — €4,500

Fixed-price project:

Milestone 2 of 3: API integration complete and accepted — €6,000

For hourly invoices, attach a separate timesheet PDF that breaks down hours by ticket, day, or feature. Most enterprise clients will not approve an hourly invoice without one.

7. Subtotal, taxes, and total

Standard. Show the pre-tax subtotal, the tax line (with rate), and the total. For EU B2B with VAT-registered clients in different EU countries, write "Reverse charge — VAT to be accounted for by the recipient" on the line where VAT would be. This is required by the EU VAT directive and the absence of it will get the invoice bounced back.

8. Payment terms and methods

Specify due date, accepted methods (bank transfer with full IBAN/SWIFT, or Wise/Stripe link), and any late fee policy. Include a single line stating payment terms ("Payment due within 14 days") and your bank details in full. A typo in the IBAN can hold a payment for weeks.

9. Engagement model and scope reference

Add a one-line summary near the top of the invoice that names the engagement model and scope: "Hourly contract per SOW dated 2026-03-15 — Sprint 14 of ongoing." This anchors the invoice to a specific agreement and helps finance teams resolve queries without contacting the developer.

10. Code ownership / IP transfer clause

This is the legal version of "you own the code when you have paid for it". Most freelance developer contracts state that intellectual property in the deliverables transfers from the developer to the client upon receipt of full payment. The invoice should reference this — even just one line: "IP in delivered code transfers to Acme Inc. upon receipt of full payment, per master service agreement dated 2026-03-15."

Why this matters: until that transfer happens, a client who has not paid does not legally own what you delivered. Disputes get cleaner when the trigger is an objective event (payment received) referenced on a specific document (the invoice).

11. Pass-through costs (cloud, tools, third-party services)

If you are paying for AWS, Vercel, Stripe Connect, or any third-party infrastructure on the client’s behalf, list these as a separate line on the invoice. Do not roll them into your hourly rate. Two reasons:

Tax treatment differs (pass-through costs are reimbursed expenses, not your revenue)
It makes your hourly rate look healthier (€95/hr looks better than €130/hr where €35 is invisible AWS pass-through)

Common practice is to add 5-15% on top of the actual cost to cover the time spent managing the account.

12. Scope-creep and overage handling

For hourly contracts, scope creep just adds hours and is naturally captured. For fixed-price or sprint-based contracts, scope creep needs to be handled deliberately, usually as a separate "Out-of-scope work" line item:

Out-of-scope work (per change request CR-014, additional auth flow), 6.5 hrs × €120 — €780

Reference the change request or written approval in the line item description. This protects both sides — the work is visible, the approval is referenced, the cost is explicit.

How to handle the hourly-vs-fixed question

This question comes up at the start of nearly every freelance developer engagement. The honest answer in 2026:

Hourly works best for ongoing or open-ended work where scope cannot be fully defined upfront
Fixed-price works best for tightly-scoped, well-understood projects with clear deliverables
Sprint-based hits the middle: predictable cost for the client, predictable revenue for you, scope handled per-sprint

A hidden third path is hybrid: a small fixed-price discovery and scoping engagement, followed by either hourly or sprint-based delivery. This protects both sides — the client does not commit to a number before the work is understood, and you do not underbid because of unknowns.

Common mistakes in developer invoices

Sending an invoice for "Development work — €5,000" with no breakdown
Hourly invoices without an attached timesheet — most enterprise AP teams reject these
Missing the engagement / SOW reference on the invoice (finance cannot match it to anything)
No PO number on invoices to medium or large clients
Pass-through costs rolled into hourly rate, hiding margin and complicating tax
No reverse-charge VAT note on cross-border EU B2B invoices
Bundling scope creep into the regular invoice silently — the client never sees it called out, you are slowly losing money
Sending invoices as Word documents — many corporate AP systems only accept PDFs
Inconsistent invoice numbers (gaps, restarts, duplicates) — can trigger tax audits in some jurisdictions