Electronic invoices in Europe
Electronic billing, or electronic invoicing refers to the digital transmission of an invoice, typically a file, from a sender computer to a recipient computer. This can e.g. be a XML file by email, a PDF download from a web portal, but it can also be a computer fax between two computers. If a dedicated protocol for the transmission of electronic invoices is used, it is still an electronic invoice, even a structured one, but more narrowly this is already called Electronic data interchange. In that particular case (of EDI) you might not even see a file.
Electronic invoices does not automatically mean you also have to pay electronically, however, the recipient can still pay how (s)he likes, e.g. in cash. It is under your responsability to pay the invoice, but at least structured and hybrid electronic invoices will state very clearly what has to be paid when to whom under which reference, so your banking software could technically present you a “balance this invoice” button.
Structured vs unstructured
Unstructured invoices are human readable, e.g. the image file of a scanned paper invoice. PDF files may contain a text layer, which can be used for OCR data if it is a scan. But even if this text may allow for copy&paste the precise meaning of the amounts are not defined in a machine readable way, both PDF files with and without text layers are still unstructured: a software would have to guess the meaning of a particular amount or a user would have to at least manually approve according assignments.
The meaning in a structured electronic invoice is usually expressed in a XML syntax: XML invoices are usually structured invoices. It defines data and meaning but it does not define a layout.
Structured electronic invoices are already obligatory for B2G invoices in some countries and will become also mandatory in germany.
Structured invoices can by hybrid or native.
Hybrid vs native
A invoice XML file, carrying the meaning of all items and attributes is typically a native structured electronic invoice: it does not carry layout information how to optically display it. So the layout of a print is not defined, the recipient would have to define that e.g. the total amount is to be displayed at the bottom right of the document. There are many native formats and versions, UNCEFACT CII and UBL are just two examples and there is a very nice comparison between UBL and UN/CEFACT available.
These formats require specialized reader software (standalone or integrated in your ERP) capable of understanding it and presenting it to the user: You can automatically check the calculation but for the correctness, also native e-invoices usually have to be manually approved.
Hybrid e-invoices define both meaning and layout. ZUGFeRD defines the invoice layout in a conventional PDF file, so you can use any PDF reader to access the invoice. The meaning (which amount is which tax amount and so forth), is additionally defined in a XML file which is embedded into the PDF file.
Since PDF readers are widely available, many recipients can use=pay the invoice manually “as usual”. The XML information will be used automatically if (s)he has a suitable specialized reader or ZUGFeRD capability integrated into her ERP system.
The FeRD published Guidelines for companies regarding electronic invoices. And E.ON Energie Deutschland GmbH produced a very basic (german) explanatory film on hybrid B2C e-invoices:
Pro hybrid invoices
- The reader software (PDF reader) is widely available.
- The sender does not have to know if the recipient is private, govermental or business customer and if a agreement has already been accepted.
- The invoice layout can be very close, if not identical, to printed invoices.
- The recipient and the sender can easily print hard copies.
- No fixed cutover date is necessary: due to the integrated fallback hybrid invoices can be introduced gradually.
- Invoice content and layout can be archived together.
- Service providers can digitalize a paper invoice and send the recognized invoice together with it’s raw image data.
- Additional files like time sheets or measurements can be included in the same invoice PDF file.
- The invoice can be digitally signed, which is still a requirement in some european countries like Hungary.
- Hybrid invoices (no prior agreement, wider availability of reader software) are more suitable for use in the B2C sector. (like e.g. used by EON or Conrad ) context.
Contra hybrid invoices
- Even if they are easily printable it is usually not sufficient to archive only a printed copy.
- Not only valid XML but also a valid carrier format like PDF-A is required.
- Only a few hybrid invoices will not save sufficient time to replace legacy workflows.
- People might continue to use the human readable part only.
- The decision if the machine or human readable part is used has to be documented in the process
documentation in some countries like Germany.
- There is usually little indication that a machine readable part exists.
- If the fallback is intact the sender might not even be notified if the machine reable
part is incomplete or corrupted.
- Hybrid invoices have a bigger filesize and require a layout, e.g. a letterhead.
- It is technically hard to automatically guarantee that the invoice layout (the human readable PDF “image”) matches the XML content. An attacker could send optically correct invoice PDFs with embedded counterfeit XML content. The attack will succeed if only the optical representation is checked, but the XML part is processed.
- ZUGFeRD 2.0 which added capability for european B2G invoices, is available since 2019-03-11.
- Have magic scans (hybrid only)
- Some service providers scan paper invoices for their customers and delivers them as PDF. Since anyway already a optical character recognition (ORC) was run on the scans, they now also offer the service of semi-automatic invoice recognition and add manually corrected (and therefore guaranteed) ZUGFeRD metadata to their scans so that they can be automatically processed.
- Facilitate Procure-To-Pay (hybrid and native)
- When companies use ERP systems where
- orders are entered into the system and
- the storage facility registers every delivered item upon arrival in the system and
- the invoice arrives as ZUGFeRD and refers to the order
The invoice can be automatically checked vis á vis the order and can be automatically payed and booked as envisaged when creating the order.
- Have your suppliers in line (hybrid and native)
- Some bigger companies have managed to persuade a significant amount of their suppliers to send ZUGFeRD invoices. This way they save money because no paper or unstructured PDF invoices need to be processed.
- Pay invoice files (hybrid and native)
- ZUGFeRD means no more need to copy&paste IBAN, amount or purpose field for a bank transfer, it’s sufficient to select the ZUGFeRD-PDF file to be paid. E.g. there is a proof of concept plugin for the open source onlinebanking software Hibiscus or a commercial product called CIB SEPArator which converts ZUGFeRD files to SEPA XML.
Some countries introduced mandatory electronic invoices in the B2G sector, Denmark was the first in 2005, followed by Sweden 2008, Spain and Finland 2010 and Austria and Italy 2014.
Probably also because already in 2009, Denmark could credibly explain that the e-invoice saves them 100 million Eur/year. The predicted savings vary in a great bandwith, in 2010 the European Commission referred to a report
which indicates 226 billion Euro savings potential within six years (“assuming the best case scenario” and “a linear evolution”). In 2014, the EU finally decided in their 2014/55 EU Guideline to make the support of electronic invoices mandatory for all member states.
The EU legislation ignores unstructured electronic invoices and defines electronic invoices as “an invoice that has been issued, transmitted and received in a structured electronic format”. This definition is not yet consitent through the laws of all countries, which might have led to confusion, e.g. Germany’s e-Rechnungsgesetz / e-Rechnungsverordnung follows this definition, whilst the german law on VAT (Umsatzsteuergesetz) speaks of elecronic invoices without further qualification and covers both structured and unstructured invoices. This unclear definition, often omitting the qualification “structured”, has caused some confusion, e.g. a german article stating that 68% of the participants in a survey (the article probably refers to this) do not know what electronic invoices are.
The european standardization authority CEN has followed it’s duty and published EN16931 to augment 2014/55/EU.
You can buy EN16931 from your national standard body but after a lengthy discussion at very high levels (further details (german)) it has been agreed that one edition of the first part of the standard, EN16931-1, which details on the calculation rules, numbers of decimals etc., are published free of charge (german version).
In the meantime, CEFDIGITAL has published a very helpful lists of all codes which can be used in EN16931 files, e.g. for currencies, countries, means of identification and units.
Switzerland followed with electronic invoices in 2016. Germany national authorities will start accepting electronic invoices as of November 2018 and make it compulsory as of November 2020 on a federal level.
Electronic invoicing is voluntarily in the B2B sector.
In Austria, e-invoices are more or less treated like digital versions of the printed invoices, which makes it very easy to handle with. Austrian companies might even be allowed to destroy paper receipts after scans.
In Hungary, apparently e-invoices have to be digitally signed.
Regarding Switzerland, in 2018 Simone Sporing held a (german) speech “Die E-Rechnung in Industrie und Handel” how Coop introduced ZUGFeRD and that and how it was certified by the authorities
For further details on all european countries please refer to the “EU compendium on e-invoicing retention” which also lists the legal requirements for the different countries and the (german) collection on legal foundations for electronic invoices in the EU (Sammlung der Rechtsgrundlagen für elektronische Rechnungen in der EG) and in particular interesting regarding B2G the CEFDIGITAL E-invoicing situation per country
As defined in the german e-invoice law (amended E-Rechnungsgesetz in Bgbl 19/2017) and the according act, the E-Rechnungsverordnung, structured e-invoices will become mandatory vis á vis the authorities as of November 2020 in germany.
Early 2018, Mr. Hauschild summarized in a german speech the situation in german non-federal administration, namely german states and counties (slides) and recommended a german handbook for the authorities.
According to the justification for the e-Rechnungsverordnung the authorities receive an annual total of 7.95 million invoices, of which they expects 80% (6.36 million invoices) to become electronical.
The justification refers to the Architekturkonzept e-Rechnung, which estimates (page 96) 8 million invoices, half of which are direct and the other half are vis á vis the administration. Other sources talk about an expected 300,000 directly affected suppliers.
The official justification further expects a reduction of the processing time from 22,6 minutes to 11,78 minutes each and total savings of up to 62.38 million Euro for the government along with savings of 10.87 million Euro for the industry. The costs are expected to amount to 6.1 million Euro as a one off investment and 1.125 million Euro annually.
These 62.38 million is quite a lot but still much less than the 500 million expected in e.g. the Billentis E-invoicing business case, whichs says (page 21), “The difference to the total “public sector saving potential” above [in that case 6500-2600-3400] is the saving potential for the federal administration.”). The business cases also mentions a total “Minimum public sector saving potential” of 6.5 billion Euro per year just for germany.
The german GOBD impose some obligations if you “save” an invoice in „the file-system“ – or if you accept (i.e. pay) structured or unstructured electronic invoices.
Among the most important duties is that both sender and recipient have to electronically archive the document in an unalterable way (“revisionssicher”), which requires (among others) tamper-free storage and a documentation of the process. BITKOMs has summarized the 10 most important requirements (german) and also published a exhausitive list of requirements vis á vis document management systems (in german).
On Youtube you will find a 20 minute german speech from 2016 on electronic invoices for SME.
In general, scanned paper invoices may be disposed, but only after certain criteria are met: e.g. it is defined who is responsible for that particular scan, the according person checked that its complete and legible, and the first digital backup has been created.
There is a (german) sample documentation on how to scan and how to file (also german). The DATEV has confirmed (in german) that digital files can be legally compliant.
In Germany there is no legal requirement to ask the recipient for permission to send her electronic invoices, if the invoice is accepted and paid, it means the the recipient also complies to the additional regulations. It is, however, her right to reject the electronic version and explicitly ask for a paper copy. In this case the paper original probably has to be provided without additional cost.
ZUGFeRD ( Zentraler User Guide Forum elektronische Rechnung Deutschland ) is a open european standard for a structured, hybrid PDF e-invoice . Technically, this works by embedding a XML file into PDF file. Embedded ZUGFeRD files work with all PDF readers but of course these readers may not automatically process the metadata.
ZUGFeRD is based on
- PDF for the optical representation and
- an embedded XML for the metadata/structural representation
The PDF used in ZUGFeRD is PDF/A-3. PDF/A is a subset of PDF which does not only allow validation (PDF per se can not be validated), it is specifically designed for better archival: e.g. external fonts are always embedded in PDF/A. PDF/A-3 (standardized in ISO 19005-3:2012 and not at all related to the paper format DIN-A3) is the third version of the archivable PDF/A edition, which supports embedded files.
The CEN semantic model of a core invoice is already foundation for ZUGFeRD 1.0. It e.g. defines the correct number of decimals (rule 9): in quantity (4) , currency prices (4) and totals (2), the units and how the invoice amount is calculated.
Andreas Starke has published his suggestions for ZUGFeRD Industry-specific extensions in June 2018.
Factur-X is just another name for ZUGFeRD 2.0.
ZUGFeRD 2.1 was been released on 23 march 2020.
- from 2.0 auf 2.1
- there is a english translation (there was none for 2.0)
- factur-x.xml is now not only allowed as filename of the embedded file but zugferd-invoice.xml has been deprecated
- the codelists have been updated to version 3 of the CEF artefacts
- many cardinalities have been adjusted, e.g. the extended profile now supports 2x grand total amounts, e.g. in Euro and foreign currency
- from 1.0 to 2.0
- ZUGFeRD 2 supports European B2G invoices, namely EN16931. Alternatively to ZUGFeRD (more precisely UN/CEFACT CrossIndustryInvoice D16B SCRDM uncoupled), UBL 2.1 and EDIFACT are also eligible for EN16931.
- ZUGFeRD 2 has been adopted by the french FNFE as “Factur-X version 1.0”.
- In particular to accommodate french requirements there are two new profiles below basic,
- Basic Without Lines (BASIC WL)
The profile Comfort has been renamed to EN 16931.
- The filename of the embedded file changes from ZUGFeRD-invoice.xml to zugferd-invoice.xml (lower caps) in ZF2 respectively factur-x.xml in FX
- The XML part of ZUGFeRD 1 was some sort of a customized XML format based on UN/CEFACT. ZF2 is based on the original version of the XML schema, UN/CEFACTS Cross Industry Invoice CII, more precisely on UN/CEFACT CII SCRDM 16B uncoupled .
- The root node therefore changes from CrossIndustryDocument to CrossIndustryInvoice.
- The schema change also means that some elements are renamed, e.g.
Name in ZF1 in ZF2 SpecifiedExchangedDocumentContext ExchangedDocumentContext HeaderExchangedDocument ExchangedDocument ApplicablePercent ram:RateApplicablePercent SpecifiedSupplyChainTradeDelivery ram:SpecifiedLineTradeDelivery SpecifiedLineTradeAgreement ram:AssociatedDocumentLineDocument SpecifiedSupplyChainTradeAgreement ram:SpecifiedLineTradeAgreement
- some element names became more specific, e.g. ID became IssuerAssignedID if it was used in BuyerOrderReferencedDocument, DeliveryNoteReferencedDocument, AdditionalReferencedDocument or ContractReferencedDocument
- Now also the sequence of some elements is defined more specifically, which may cause you to reorder some elements, e.g. in SpecifiedSupplyChainTradeTransaction the IncludedSupplyChainTradeLineItem now has to be the first child BuyerOrderReferencedDocument, DeliveryNoteReferencedDocument, AdditionalReferencedDocument ContractReferencedDocument now have to start with ID, then typecode and some more.
- The XSLT Style Sheet to convert to HTML will no longer be part of the release. But the ones from XRechnung can be used.
You can use the commandline or Have a look at Mustangprojects (not very complete) XSLT file which facilitates the transformation from ZF 1 XML to ZF 2 XML. There is also a first attempt for a Mustangproject sample file for version 2.
ZUGFeRD supports five different levels of required structured information
- Minimum (ZUGFeRD 2 only)
- Basic Without Lines (ZUGFeRD 2 only)
- EN16931 (called Comfort in ZUGFeRD 1)
Mustangproject complies to the Extended level.
- In 2015 Intarsys published some nice (german) slides on status, history and genealogy of ZUGFeRD 1 including several PDF aspects, tools and workflows and optically compares the profiles basic, comfort and extended.
- The Bitkom explained ZUGFeRD (in german) in 2014 and features a similar sample invoice with optical indications which attribute belongs to basic resprectively comfort on page 6.
EN16931 defines a common part (Core Invoice) and allows for national extensions, so-called Core Invoice Usage Specifications, CIUS. XRechnung is the CIUS for invoices to the german authorities.
Example: The Core Invoice requires country and email address of the recipient, but according to german §19 UstG an invoice has to bear the street address of the recipient. So the street address is among the attributes which XRechnung there are also additional optional attributes, e.g. the german Skonto (cash discount), despite being usual in Germany, is unusual in the rest of Europe, that’s why it didn’t make it into the Core Invoice.
The XRechnung requirements can be expressed in either UBL or UN/CEFACT XML. A UN/CEFACT XRechnung (like this one) is based on the same schema files, thus identical similar to the file embedded in a ZUGFeRD 2.0 PDF in the EN16931 profile.
|Name||Release date||File format||Hybrid||B2G||B2B with agreements||B2B without agreements||B2C||XML dialect|
|XRechnung 1.0||2017-05-10||.xml||n||y||y||n||n||UBL, UN/CEFACT CII|
|XRechnung 1.1||2017-11-30||.xml||n||y||y||n||n||UBL, UN/CEFACT CII|
|XRechnung 1.2||2018-12-18||.xml||n||y||y||n||n||UBL, UN/CEFACT CII|
|ZUGFeRD 1.0||2014-06-25||y||n||y||y||y||UN/CEFACT CII|
|ZUGFeRD 2.0||2019-03-11||y||y||y||y||y||UN/CEFACT CII|
You can also refer to a german ZUGFeRD/XRechnung comparison.
XRechnung has published open source XSLT style sheets to convert EN16931 XML to HTML, which also work on ZUGFeRD 2 and Factur-X files.
There are Online-Tools to create a UBL-XRechnung data structure.
The idea is that invoices to national authorities are uploaded to central platforms, Chorus in France, ZRE in Germany. The ZRE has a environment for uploads of productive and test invoices and almost certainly runs the open source Kosit validator on the incoming invoices.
- General topics
- Statistics and numbers
- IBI published a (german) Study in 2017, indicating 62% of all organisations send invoices by mail, 42% capture the data of electronic invoices but only 25% use this data. Around half of the organisations does not document their processes.
- The DIHK says 48% support the processing of electronic invoices