How to Invoice as a Freelance Software Developer (EU Guide)

Freelance software developers invoice differently from most freelancers. The work is almost always B2B, the amounts are large, the engagements run for months, and — because good developers work remotely — the client is frequently in another country. That last point is where invoices go wrong: a backend contractor in Lisbon billing a startup in Berlin is a cross-border B2B transaction, and the VAT treatment is not the same as a local invoice.

This guide covers what belongs on a developer’s invoice, how to bill day rates and retainers cleanly, and the reverse-charge rules that decide whether you add VAT or not.

What goes on a developer’s invoice

The legal essentials are the same as any B2B invoice, but a few fields matter more for contract dev work:

1. Your details and VAT ID — name/company, address, and your VAT identification number. For cross-border EU work the VAT ID is non-negotiable.
2. The client’s details and VAT ID — including their VAT number, which you’ll need for the reverse charge.
3. A unique invoice number and the issue + supply dates.
4. A specific description — not “consulting.” Write “Backend API development — Sprint 14” or “Frontend build, milestone 2.” Vague descriptions are the number-one reason an accounts-payable team parks your invoice.
5. Rate, quantity and unit — e.g. 8 days × €640/day. Show the unit (hour / day / month) explicitly.
6. Subtotal, VAT (or the reverse-charge note), and total.
7. Payment terms and how to pay — due date, IBAN/bank details, and any PO or reference the client asked for.

Rate models: hourly, daily, milestone, retainer

Most dev contracts use one of four shapes, and each maps to a clean line item:

• Hourly — best for ad-hoc work and small fixes. List hours × rate.
• Daily — the default for sprint-based contract work. List days × day rate.
• Milestone / fixed-price — invoice on delivery of each milestone, ideally with a deposit up front.
• Monthly retainer — a fixed monthly amount for ongoing availability; one recurring line item per month.

The part that trips developers up: cross-border VAT

Whether you put VAT on the invoice depends entirely on where your client is and whether they’re a business:

• Client in your own country — charge your local VAT rate as normal.
• Business client in another EU country — this is the common case for remote devs. You apply the reverse charge: you invoice with no VAT, and your client accounts for it in their country. The invoice must carry both VAT IDs and a note such as “Reverse charge — VAT to be accounted for by the recipient (Art. 196 VAT Directive).”
• Client outside the EU (US, UK, etc.) — the service is generally outside the scope of EU VAT, so no VAT is charged.

Two things make the reverse charge valid: a real, verifiable client VAT number, and reporting the sale. Always check the client’s VAT ID against VIES (the EU’s validation system) before you invoice — if it’s invalid, the reverse charge doesn’t apply and you may owe the VAT yourself. These sales also go on your recapitulative statement (the EC Sales List equivalent in your country).

E-invoicing is coming to B2B

Several EU countries are making structured e-invoicing mandatory for B2B over the next couple of years (Germany, France, Poland, Spain and others on staggered timelines). A PDF won’t be enough — invoices will need a structured format like Peppol BIS, XRechnung, Factur-X or FatturaPA, all built on the EN 16931 standard. If you contract across borders, pick a tool that already outputs these so you’re not re-tooling later.

Payment terms that get developers paid

Net 14 or net 30 is standard for dev contracts. For fixed-price projects, take a deposit (commonly 30–50%) before starting and invoice the rest on milestones — it protects your cash flow and filters out clients who were never going to pay. State late-payment terms explicitly; in the EU you’re entitled to statutory interest and a recovery fee on overdue B2B invoices.

Common mistakes

• Vague line descriptions that invite questions and delay.
• Forgetting the reverse-charge note (or charging VAT when you shouldn’t).
• Not validating the client’s VAT ID on VIES.
• Missing the PO number or reference the client’s finance team requires.
• Invoicing in the wrong currency, or not stating which currency the total is in.

In short

A developer’s invoice is a normal B2B invoice with two things done carefully: a precise description of the work, and the right VAT treatment for where your client sits. Get the reverse charge right and your cross-border invoices sail through. Create your first developer invoice here — the VAT logic is built in.