E-invoicing, without touching XML

Nothing is pushing you — and that is the honest version

Three of the regimes named above already run, and all three sit in countries that have their own language on this site. If you are reading the English pages, you are most likely in a country that has not yet mandated anything between businesses.

What you do have is a horizon. Directive (EU) 2025/516 requires structured e-invoices for intra-EU B2B from 1 July 2030. The Council approved the package on 11 March 2025; Ireland's Revenue names milestones in 2028 and 2030 and is running its own consultation towards them. That is four years out, and no garage buys software in 2026 because of 2030.

So this page will not sell you a deadline. It is a precaution argument, and precaution is worth something precisely because it is cheap while nothing is burning: the format question gets decided the day you choose software, not the day a law arrives. If you pick a system that already writes the European format out of the job, the deadline is a date that passes rather than a migration you live through.

The date that will actually reach you first is not a directive's. It is a customer's — a fleet, a leasing company, a public buyer who asks for a structured invoice because their own system asks for one. They do not wait for a legislature, and there is no notice period.

One norm — and the line where our part ends

EN 16931 is the European norm for the content of an electronic invoice. What our system writes for a customer abroad is an invoice in plain EN 16931, with no national profile on top, generated from the job you entered anyway. For a garage established in Spain, Italy, Poland or Türkiye our system issues no invoices, so it writes no such file there. The same holds for a garage established in another country whose law ties the invoice to a system the state prescribes — in some countries only for invoices to businesses or public bodies. The Invoice profile shows whether your country is one of them. A national CIUS — one country's tightening of the norm — sits on top of that, and which one applies is a country question, not a format question.

Now the part most suppliers leave out, and the reason this block exists: we produce the document. We do not send it over the Peppol network. There is no access point in our software. The electronic address of both parties is filled with an email address, which is what a garage's customers actually have.

• Business to business, that is enough. You mail the file, your customer's bookkeeping reads it. No network registration is involved on either side.
• To a public buyer, the file alone does not deliver. Public bodies are generally addressed through a network registration rather than an inbox. If a municipal fleet or a public institution is your customer, settle the route with them before the first invoice — a rejected e-invoice does not arrive late, it does not arrive at all, and no payment term starts running.

Two German format names travel with our origin, and neither is the answer here. XRechnung is Germany's own tightening of EN 16931; ZUGFeRD is a PDF with XML inside it. Both are right in Germany. Neither is what a buyer in Lisbon, Oslo or Prague is asking for, and we would rather say so than let a German feature list read like a European one.

Three sentences that cost money

• “We already email PDFs.” A PDF without structured data is an ordinary invoice — digital, but not electronic. What the norm is about is the data, not the sending channel. This is the cheapest misunderstanding to hold and the most expensive to discover at the receiving end.
• “The software says EN 16931, so we are compliant.” The norm governs the document. Whether your country also wants the document routed through a national platform, or wants your bookkeeping or invoicing system itself registered or certified, is a separate question with a separate answer per country — and no format answers it. This is the sentence this whole page exists to prevent.
• “There is one European e-invoicing rule.” There is one European norm and roughly as many regimes as there are countries. That is exactly why this page tells you what we generate instead of telling you what you comply with.

The second is the expensive one, and not for the reason you would guess. Someone who believes compliance is settled buys on the wrong ground: he compares packages on a format instead of on whether the invoice comes out of the work order at all. In this market that is the real difference — and it is why the invoicing page is about the document and this one is about the format and the route.

Receiving is the half nobody plans

Everything above is about invoices you send. The invoices you receive arrive first, they arrive whether or not you were ready, and they are where retention duties fail most often.

The rule is short: the structured file is the original and the printout is a copy. Printing an incoming e-invoice and filing the paper keeps the copy and loses the record. It is not the format that fails here — a mailbox is technically enough to receive one.

What fails is that nobody decided where incoming invoices land, who matches them against the parts order, and who files them. A supplier's e-invoice that drops into a personal mailbox is lost exactly the way a delivery note on a workbench is lost, and it is worth less, because there is no second copy on the counter.

The fix is a decision, not a purchase: one address, one person, one place they are kept in their original form. Make it before the first one arrives.

When a structured invoice bounces

A PDF with a mistake in it produces a phone call. A structured invoice with a mistake in it produces a rejection — and a rejected invoice did not arrive late, it did not arrive. Nothing was received, no payment term ever started, and the clock you believed was running was not. That difference is the single practical consequence of the norm being strict, and it is worth understanding before the first one comes back rather than after.

Three reasons a file is refused, and they are not equally likely:

• A mandatory field your data does not carry. The norm and the national rules built on it insist on things a paper invoice never needed — an electronic address for both parties, tax identifiers, a buyer reference where the recipient requires one. Most rejections are this, and most of this is a customer record that was never completed.
• A national tightening of the norm. A CIUS is one country's stricter reading of EN 16931, and a document that satisfies the general profile can still fail one. Between two German parties, and to a German public body that gave you its Leitweg ID, we write XRechnung; between two Dutch parties NLCIUS, unless the customer is a private person — a Dutch public body gets it too; otherwise plain EN 16931, which is not a national CIUS. Between two French parties, again unless the customer is a private person, that plain EN 16931 file also meets the French rules. Such a Dutch invoice needs the registration number (KvK or OIN) of both parties, a French one yours and your customer’s (SIREN or SIRET), plus whether your invoices cover goods, services or both. A customer you mark as a private person is asked for none of it, because neither rule set is written for consumers. Your part goes in the Invoice profile, your customer’s number on the customer record. If your customer sits in a country that runs its own, that is a question to settle before the first invoice, not a defect to discover from a rejection notice.
• The route, not the document. A file that never reached a system able to check it is not a format problem. That is mostly a public-buyer situation, and it is covered in the block on public buyers below.

What to do when one comes back is undramatic, and one instinct has to be resisted. Do not quietly edit the invoice and send it again. An issued invoice is corrected by a second document, for reasons the invoicing page sets out, and a rejection does not suspend that. Keep the rejection message itself: it names the rule that failed, which is the fastest route to the field that was wrong, and it is the evidence that the invoice was sent at all.

The consoling part: a rejection is better news than it feels like. The alternative is a wrong invoice accepted silently and found months later, in a different quarter, by somebody else.

Public buyers: a reference, a route, and only one of them is ours

If a municipality, a public hospital, a school authority or a state-owned fleet is among your customers, three things work differently — and none of the three is the format.

• They name a reference, and it has to be on the invoice. An order number, a cost center, a contract identifier. The norm has a field for exactly this, the buyer reference, and our invoice form carries it; left empty it falls back to your customer number, which is right for a private customer and wrong for a public one. So ask for the reference when you take the job in, not when you write the invoice — by then the person who knows it is not standing in front of you.
• They name a route, and the route is not ours. Public bodies are generally addressed through a network registration rather than an inbox, and we generate the document without operating the transport. Settle with the buyer how the invoice is to reach them before the first job, and settle who does that part.
• They pay along their own process. A public payment passes a checking step a private customer does not have. A missing reference therefore does not come back as a question the same afternoon; it comes back as a refused document weeks later, with no payment term having run in the meantime.

None of this makes public work unattractive — it is steady, it repeats, and it is the kind of customer that stays for years. It makes it work you set up once. One conversation before the first invoice, the reference field filled from the first job, and the route agreed in writing by somebody who can name it.

What actually changes on the garage floor

Three things. None of them is a format question.

• The job is the source. If times, parts and positions already hang on the job, the invoice comes out of it and the XML comes with it. Writing the invoice a second time beside the job means typing twice and holding two truths, one of which shows up in an audit.
• A missing field is no longer a phone call. The norm is strict. A wrongly filled or missing mandatory field means machine rejection at the other end — the error surfaces at your customer, not at your counter, and it comes back as a returned document days later. A form that will not let the gap open is worth more here than any format list.
• The first ones to ask are your biggest customers. Fleets, leasing companies and public buyers run systems that want structured data. Being able to hand it over is not a compliance story at that moment, it is the reason the job stays with you rather than moving to the garage down the road.

One meeting with your accountant, and what to take into it

These pages cannot tell you your country's rules, and everything above is written so as not to pretend otherwise. What they can do is stop you paying for the same meeting twice. Five questions, one appointment, and the answers hold for years:

• Which regime applies to me, and from when? Between businesses, towards public bodies, and whether anything at all is required of me today. Take the European horizon with you — structured B2B invoicing across borders from 1 July 2030 — so that the answer comes back with dates on it rather than as a feeling.
• How long must invoices be kept, and in what form? The period is national and no number for it appears anywhere on these pages. Get it, because it is the number that decides what leaving a software supplier actually costs you.
• What does my country add to the mandatory content? An extra identifier, a required wording, a threshold below which a shorter document is enough. This goes into the template once and then never has to be thought about again.
• Does my country regulate the software rather than the invoice? Registration or certification of an invoicing or bookkeeping system is a duty on the supplier — but you are the one who finds out the hard way. Ask independently of us; where we know the answer for a country, the country questions at the end of this section give it.
• How do you want the monthly hand-over? We produce a PDF and the structured file, and there is no direct ledger integration today. Whether that fits the way your books are kept is a five-minute answer that saves a year of workarounds — the invoicing page describes exactly what leaves the system.

Two things said plainly. We are not tax advisers and none of this is advice; it is a description of what our software produces and where it stops. And have the meeting at setup rather than after the first audit — at setup the answer changes a template, afterwards it changes a year of invoices.

Before you rely on us in your country, three questions

This page is written for a lot of countries at once, which means the useful thing it can give you is not an answer but the three axes on which your country can differ. Two of them we can answer for you. One we cannot, and we say which.

• Does your country require a route on top of the norm? A national clearance platform, or a network registration. We generate the document; we do not operate the route. SdI, KSeF and Verifactu are not covered, and there is no Peppol access point behind our export. For Italy our answer is already known: there an invoice between parties resident or established in Italy is an electronic invoice issued through the SdI, which our software does not reach, so it issues no invoices for a business established in Italy; it prepares them as drafts. For Poland our answer is already known as well: there invoices are issued as structured invoices through KSeF, the National e-Invoicing System, which our software does not reach, so it issues no invoices for a business established in Poland; it prepares them as drafts. That includes the invoices Polish law still allows outside KSeF, for example to a private customer. For Türkiye our answer is already known too: there an invoice is an e-Fatura or e-Arşiv Fatura, issued through the GİB portal, a GİB-licensed özel entegratör or a system GİB has approved for direct integration. Our software is none of these, so it issues no invoices for a business established in Türkiye; it prepares them as drafts. The same holds for a garage established in another country whose law ties the invoice to a system the state prescribes — in some countries only for invoices to businesses or public bodies. The Invoice profile shows whether your country is one of them.
• Does your country regulate the software rather than the invoice? Some do — registration or certification of the bookkeeping or invoicing system itself, which is a duty on us and not on you. For Spain our answer is already known: until our software meets Verifactu, it issues no invoices for a business established in Spain. For Portugal our answer is known now as well: an invoice issued with software must come from a program the tax authority (AT) has certified in advance, and ours is not, so it issues no invoices for a business established in Portugal; it prepares them as drafts. For Denmark our answer is known too, and it runs the other way: Danish law regulates the books, not the invoice. No Danish rule ties the invoice to a system the state prescribes, so our software issues invoices for a business established in Denmark. What the Danish Bookkeeping Act (bogføringsloven) regulates is the system the books are kept in: a business with a net turnover above DKK 300,000 in two consecutive years, or one that must file an annual report, keeps its books in a digital bookkeeping system that is registered with the Danish Business Authority or meets the act's requirements. That duty is about your bookkeeping program, not about the invoice we write; your accountant knows from when it applies to you.
• What must the invoice contain? National, and not ours to set. What the software carries is on the invoicing page; what your country adds on top is a single conversation with your accountant, worth having once at setup.

The reason this block is a list of questions rather than a table of ticks: a table would have to be filled in with things we have not verified, and a green tick that turns out to be wrong costs more than a blank ever did.