Electronic invoicing is moving from optional to mandatory across Europe, country by country, on different timetables and in different formats. For a hosting provider selling across borders this is not a single project — it is a rolling series of national deadlines, each with its own file format and its own transmission channel.
Here is the shape of it, and what to check in your billing platform before a deadline in a country you sell into becomes your problem.
Not tax or legal advice. E-invoicing mandates are national, they arrive on different dates, and several are still being amended. Scope, formats and deadlines differ by country and by whether the transaction is B2G, B2B or B2C. Confirm your obligations with an adviser in each country where you invoice.
What "e-invoicing" actually means
Not a PDF attached to an email. A PDF is a picture of an invoice; an electronic invoice in the regulatory sense is a structured data file that a machine can process without reading pixels — typically XML, in a defined schema, often transmitted through a specified channel rather than by email.
Three separate things tend to get bundled under one label, and it helps to keep them apart:
Format. The structured schema the invoice is expressed in. European mandates generally build on the EN 16931 semantic standard, with national syntaxes on top.
Transmission. How the document reaches the recipient and, where required, the tax authority. Some countries route through a government platform; others use a network of accredited access points.
Reporting. Whether the tax authority receives the data, when, and in what detail. This is the part that turns e-invoicing into near-real-time tax visibility, and it is the reason governments are doing it.
Why hosting providers get caught by this
Two structural reasons.
First, you invoice across borders by default. A hosting business with customers in six countries can fall under six different regimes, and the obligation usually attaches to where the customer is established, not where you are.
Second, you invoice at volume, automatically. A business issuing twelve invoices a month can bridge a mandate manually. A business issuing four thousand renewals a month cannot. If your billing platform cannot emit the required format, the fallback is not "do it by hand" — there is no by-hand at that volume.
What to check in your platform
- Can it emit structured XML at all, or only PDF and CSV? This is the binary question. Everything else is detail.
- Is the export format pluggable? You will need more than one format over time. A platform with one hardcoded national format solves one country and blocks the next.
- Does every mandatory field exist in the data model? Structured invoices demand fields that a PDF never needed: legal entity identifiers, tax registration numbers on both sides, unit codes, payment means codes, and a scheme-qualified customer identifier. If the field is not captured at order time it cannot appear in the file.
- Are credit notes handled as their own document type? Mandated formats treat them distinctly and require a reference to the original. See invoice numbering and sequence.
- Can you re-issue? Rejections happen. A rejected invoice has to be correctable and resubmittable without breaking your number sequence.
- Is there an audit trail of what was submitted and what came back? "We sent it" is not evidence. The acknowledgement is.
The data you are probably not capturing yet
This is the practical bottleneck, and it is worth acting on before any deadline because it is slow to fix retrospectively.
Structured invoicing generally requires the customer's tax identifiers and legal identity to be correct and machine-readable — not "Acme Ltd" in a free-text name field, but a registered legal name, a VAT identifier, and in several regimes a scheme-specific electronic address. Most hosting signup forms collect a name, an email and a country, because that is all a PDF ever needed.
Backfilling that across an existing customer base is a campaign, not a migration script. Start collecting the fields at signup now, even where no mandate applies to you yet, and the eventual switch becomes a format change rather than a data-gathering project.
A staged approach
- List the countries you actually invoice into, split by B2B and B2C.
- For each, find the current mandate status and date. Treat published dates as provisional; several have moved.
- Check whether your billing platform can emit a structured format at all, and whether adding another is a configuration or a development project.
- Start capturing the identifiers now — legal name, tax number, electronic address where relevant — at signup and on existing accounts.
- Confirm your archiving obligation. Several regimes require the structured file to be retained, not just the PDF, for years.
How FluxBilling fits
FluxBilling's accounting export is built as a registry of pluggable formats rather than one hardcoded output — XLSX, generic CSV, a country-specific accounting XML and bulk PDF all come out of the same document pipeline, with EU VAT allocated per rate and the customer's country attached. Adding a format is adding a serializer to that registry rather than rewriting the export.
Being straight about scope: FluxBilling does not today ship a certified connector to any national e-invoicing platform, and it is not a compliance product. The existing XML export targets a specific accounting package, not a government portal. If you are subject to a mandate that requires transmission through a national channel, you will need a service that does that transmission, and you should confirm the integration path with us before you rely on it. We would rather say that now than have you discover it against a deadline.
See handing your books to your accountant.
Closing thoughts
The format work is comparatively easy and the data work is not. Whatever your timetable, start capturing proper legal identifiers and tax numbers at signup this quarter. When a mandate does reach you, that is the difference between a configuration change and a year of chasing customers for details they have no reason to care about.