E-invoicing
An electronic invoice is the same bill as the PDF, in a structured format a machine can read. Public bodies across the EU require one, and a growing number of private buyers ask for it.
Kontier generates the document from the invoice you already have.
What is generated
EN 16931 is the European semantic standard. XRechnung is the German implementation of it, and what German public authorities require. Both are produced from the finalised invoice, so the numbers cannot disagree with the PDF.
Generation happens against a profile, which fixes the flavour of the output. Which profile a buyer needs is something they tell you.
Kontier generates the document; it does not deliver it
There is no transmission. Nothing is sent to a network, and there is no Peppol delivery. You receive a validated document and send it through whatever channel the buyer has told you to use.
Anything claiming otherwise is out of date, including older versions of these docs.
Clean customer data
A structured invoice is validated, so data the PDF would tolerate will fail here.
The usual culprits are a missing or malformed VAT identification number, an incomplete billing address, and a missing buyer reference where the buyer requires one. Fixing those on the customer before finalising is much easier than reissuing afterwards.
Per-customer preference
Not every customer wants one. Customers carry an e-invoicing preference, so you can generate for those who need it and leave everyone else on the PDF.
Reference
| Topic | When you need it |
|---|---|
| Invoices | The document this is generated from |
| Customers | Tax identity and address, the inputs that get validated |
| Taxes | Why the tax breakdown must be resolvable |