The Complete Guide to European E-Invoicing for Freelancers (2026)

For most of the last twenty years, "sending an invoice" meant emailing a PDF. That's ending across Europe. One country after another now requires invoices between businesses to be structured data a computer can read, not a document a person reads, and the EU has set a date when the same rule covers cross-border sales too. If you freelance for business clients in the EU, this will reach you sooner or later. This guide explains what's changing, where, and when, and what to do about it now.

What is e-invoicing?

An e-invoice is an invoice issued, sent, and received in a structured format that software can process automatically, without anyone retyping it. Legally, that's newer than it sounds: the EU VAT Directive has long counted any invoice "in any electronic format" as electronic, emailed PDFs included. The VAT in the Digital Age (ViDA) directive (opens in a new tab) changes that: from 2030, an "electronic invoice" in the EU means one in a structured format, by default one that follows the European standard EN 16931.

That standard is the common thread. EN 16931 is a data model: a fixed set of fields every e-invoice carries (seller and buyer identifiers, line items, a VAT breakdown per category, totals, currency, payment details) and the rules those fields must follow. It was written by the European Committee for Standardization so that invoicing software in one country can produce invoices that software in another country can read and validate. For the deeper version, including what a compliant invoice needs field by field, see EU e-invoicing explained: EN 16931 and UBL.

Why governments care: if every invoice between businesses is data, the tax authority can match what one business says it sold with what the other says it bought, often in near real time. Closing the VAT gap is the main reason behind almost every mandate below. Faster processing and fewer payment disputes are the main benefit for you.

PDF vs XML: what's the difference?

A PDF is a picture of an invoice. It looks right to a person, but to software it's a page of text and shapes. Getting the total, the VAT number, or the due date out of it takes OCR or manual typing, and both make mistakes.

An XML e-invoice is the invoice as data. There's no layout, just labelled fields, so the receiving system knows exactly which value is the invoice number, which is the VAT amount, and which VAT category each line falls under. EN 16931 allows two XML syntaxes:

• UBL 2.1 (Universal Business Language), the more common one, and the basis for Peppol.
• UN/CEFACT CII (Cross Industry Invoice), used mostly inside hybrid formats like ZUGFeRD and Factur-X.

Then there's the hybrid format: a PDF with the XML embedded inside it, like Germany's ZUGFeRD or France's Factur-X. A person opens the PDF, and software reads the XML. Hybrids count as e-invoices where the law allows them, and they do in Germany and France, because the embedded XML is EN 16931-compliant. What matters legally is the data, not the PDF around it.

One practical point: when an e-invoice is required, the XML is the legal invoice, and the PDF is just a readable copy. That changes what you have to keep in your records and what "correcting an invoice" means, both covered below.

Want to see the difference for yourself? The free e-invoice generator builds an EN 16931 UBL file and a matching PDF from the same form, no account needed.

What is Peppol?

Peppol is a network for sending e-invoices (and other business documents) between companies, run by the non-profit OpenPeppol (opens in a new tab) in Brussels. It started in 2008 as an EU public-procurement project and is now used well beyond Europe.

The easiest way to think about it is email for invoices, with stricter rules:

• You don't connect to your client directly. You connect to a Peppol access point, a certified service provider. Your client connects to theirs, which can be a different provider. The two access points exchange the invoice. This is called the four-corner model: you, your access point, their access point, your client.
• Everyone has a Peppol ID, usually based on their VAT or company registration number. Your access point looks up your client's ID in a central directory to find where to deliver the invoice.
• Invoices follow Peppol BIS Billing 3.0, a profile of EN 16931 in UBL syntax. A Peppol invoice is therefore a valid EN 16931 invoice, but not every EN 16931 invoice is ready for Peppol, because BIS adds its own rules.

The distinction freelancers mix up most often: EN 16931 is the format, Peppol is the delivery channel. Some countries mandate only the format and let you send it however you agree with your client. Others prescribe Peppol (Belgium, and from 2027 Slovakia), and others run their own national platform instead (Italy's SdI, Poland's KSeF, Romania's RO e-Factura, France's approved platforms).

Some countries add a fifth corner: the tax authority receives a copy of the invoice data along the way. Slovakia's model works that way, and Belgium plans the same for its e-reporting.

Which countries require it?

Two different things get called "mandatory e-invoicing," and it helps to keep them apart:

• Public sector (B2G). Since 2019 (2020 for some regional and local bodies), public bodies in every EU country must be able to accept EN 16931 e-invoices under Directive 2014/55/EU (opens in a new tab). Many now require them from suppliers. If you invoice a government body anywhere in the EU, assume a PDF won't be enough.
• Between businesses (B2B). This is the wave that affects most freelancers, and it's country by country. As of October 2026:

A few patterns worth knowing:

• Mandates are domestic. They cover invoices between businesses in the same country. If you're a Dutch freelancer invoicing a Belgian company, the Belgian mandate doesn't oblige you to use Peppol, though your client may well ask for it, because their own systems are now built around it. Cross-border B2B comes later, in 2030.
• Receiving comes before issuing. Germany, France, and Croatia all made businesses able to receive e-invoices a year or more before they had to send them. Even if you're exempt from issuing, you'll probably need a way to receive.
• B2C is mostly out of scope. Italy and Romania are the exceptions. Invoices to private individuals can usually stay as PDFs.
• Small-business exemptions exist, but they're narrow. Germany's Kleinunternehmer don't have to issue e-invoices, but must still be able to receive them. France gives micro-entrepreneurs an extra year, not an exemption. Slovakia has no threshold at all.

What changes in 2026?

2026 is the year e-invoicing went from "Italy and a few others" to normal in much of the EU:

• 1 January: Belgium and Croatia start mandatory B2B e-invoicing. In Belgium the tolerance period ended on 31 March, and fines now apply for non-compliance.
• February and April: Poland moves all invoicing into KSeF, the largest taxpayers first, then everyone else apart from the smallest businesses.
• March: Greece makes e-invoicing mandatory for businesses above €1 million in turnover, after a one-month delay. Smaller Greek businesses follow from the autumn.
• May: CEN publishes a revised EN 16931-1. Invoices following the 2017 version stay compliant during the migration period, so there's nothing to do on day one, but software has to catch up.
• 1 September: France's reform goes live. Every French business, including micro-entrepreneurs, must be able to receive e-invoices through an approved platform. Large and mid-size companies must also issue them.
• September: the Netherlands announces it plans B2B e-invoicing and reporting from July 2030.
• 6 October: Spain publishes the ministerial order that starts its countdown, giving businesses one or two years depending on turnover.
• 31 December: in Germany, the general transition period ends. From 2027 a PDF or paper invoice is allowed only from businesses with up to €800,000 in turnover.

Meanwhile Slovakia and Latvia opened voluntary periods, so businesses can test before their mandates start.

What changes before 2030?

The next four years are when most remaining freelancers get pulled in:

The 2030 date matters most for freelancers with clients abroad. Under ViDA (opens in a new tab), an invoice for a cross-border B2B sale inside the EU has to be an EN 16931 e-invoice, issued within ten days, with its data reported to the tax authority. That reaches the freelancers no national mandate catches: a German designer billing a French agency, or a Dutch developer billing a Belgian startup. ViDA also lets each EU country introduce a domestic mandate without asking Brussels for permission first, which is why new national dates keep appearing. Countries that already run their own real-time systems get until 2035 to align with the EU model.

Assume this list will keep changing. Dates in Greece, Latvia, Poland, and Spain all moved at least once in the past year, almost always later, never earlier.

How freelancers should prepare

You don't need to do everything at once. In rough order:

1. Map your clients. List which countries your clients are in, whether they're businesses, public bodies, or individuals, and which you invoice most. That tells you which rows of the tables above apply to you, and when.
2. Check your own status. Look up your country's rules for your situation: VAT-registered or not, under a small-business scheme or not, above or below the turnover thresholds. Ask your accountant if anything's unclear; this is exactly the question they're there for.
3. Clean up your client data now. E-invoices need structured data a PDF can get away without: the client's VAT number, the exact legal name, a correct VAT category per line (standard, zero-rated, reverse charge, exempt), and in some countries their Peppol ID or e-invoicing address. Collecting this during client onboarding is far easier than chasing it when an invoice gets rejected. The client onboarding checklist is a good place to add it.
4. Use software that produces EN 16931 output. A Word template or a PDF generator won't get you there. Check that your invoicing tool creates a real structured file, UBL or CII, not just a nicer-looking PDF.
5. Sort out delivery where it's prescribed. If you're in Belgium, or Slovakia from 2027, you need a Peppol access point. In France, an approved platform. In Poland, KSeF; in Italy, SdI; in Romania, RO e-Factura. Several of these offer free options for small businesses, and paid providers often bundle several countries.
6. Make sure you can receive. Even if you don't have to send e-invoices yet, you may already have to receive them: in Germany since 2025, in France since September 2026. For a freelancer that usually means an email address or platform account where suppliers can send XML invoices, plus a way to read them.
7. Correct with credit notes, not edits. Once the XML is the legal invoice, you can't fix a mistake by re-sending a changed PDF. Issue a credit note that references the original invoice, then a new invoice if needed. See how to correct an invoice with a credit note.
8. Archive the XML. Keep the e-invoice files themselves, not just the PDFs, for as long as your country's retention rules require (often seven to ten years). Consistent, sequential numbering matters even more when software checks it; see invoice numbering and record keeping.
9. Test with one friendly client. Before a deadline forces it, send one client an e-invoice and ask whether their accounting system imported it cleanly. A rejected test invoice costs nothing. A rejected real one delays your payment.

How Billebly supports these changes

Billebly is built for freelancers invoicing European clients, so e-invoicing is part of the core product, not a paid add-on:

• An EN 16931 e-invoice for every invoice. Each invoice you create automatically comes with a UBL 2.1 XML file structured to EN 16931: seller and buyer identifiers, a VAT category per line (standard-rated, zero-rated, reverse-charged, exempt, or outside the scope of VAT), and structured totals. You create the invoice the way you always have, and the e-invoice is generated alongside it.
• Sent with the PDF your client already gets. The XML is attached to the same email as the readable PDF, so clients whose systems import e-invoices can use it, and clients who don't can ignore it.
• Credit notes in the same format. Correct an invoice in a couple of clicks with an EN 16931 credit note that references the original, the way the mandates expect.
• Bulk export for your records. Download every e-invoice and credit note you've issued as one ZIP from Settings → Export, for your archive or your accountant.
• Free tools while you figure things out. The e-invoice generator and credit note generator work without an account.

What Billebly doesn't do today is deliver invoices through a prescribed channel. It doesn't transmit over the Peppol network or connect to France's approved platforms, Poland's KSeF, Italy's SdI, or Romania's RO e-Factura. If your country or your client requires one of those, you'll need a provider connected to that channel alongside Billebly. Because Billebly's XML follows the same EN 16931 standard those channels build on, it's a solid starting point. If you're outside those countries, or invoicing clients abroad before 2030, the EN 16931 file Billebly creates is usually all you need right now.

We'll keep this guide updated as dates move, and they will.

Sources

• Directive 2014/55/EU on electronic invoicing in public procurement (opens in a new tab)
• Council Directive (EU) 2025/516 (VAT in the Digital Age) (opens in a new tab)
• European Commission: the European standard on eInvoicing (opens in a new tab)
• OpenPeppol: about Peppol (opens in a new tab)
• National rules: linked from each country in the table above.