Electronic invoices
Definition
Electronic billing, or electronic invoicing is 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.
Electronic invoices are not related to electronic payment, the recipient can still pay how (s)he likes, even in cash.
Structured vs unstructured
Unstructured invoices are human readable, for example the image file of a scanned paper invoice. PDF files may contain a text layer, but even this text does not define the precise meaning of the amounts are not defined in a machine readable way: both PDF files with and without text layers are 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.
A structured electronic invoice is usually a XML file. It defines data and meaning but it does not define a layout.
Structured electronic invoices are already obligatory for B2G invoices in some countries like for invoices to national authorities in Germany.
Hybrid vs native
Since the layout of a XML file 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 Cross Industry Invoice (CII) (Requirements, Schema and Reference “Vocabulary” and Codelists) and UBL are just two examples and there is a very nice comparison between UBL and UN/CEFACT available.
Reading capability for structured invoices can be implemented in any software, which can then also check the calculation. But for semantical correctness, also native e-invoices usually have to be manually approved.
Hybrid e-invoices define both meaning and layout. Factur-X/ZUGFeRD define 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:
Use cases
- Have magic scans (hybrid only)
- Some service providers scan paper invoices for their customers and deliver 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. This can e.g. be done with the open source onlinebanking software Hibiscus or a commercial product called CIB SEPArator which converts ZUGFeRD files to SEPA XML.
Few sources feature a world wide overview of electronic invoicing.
European Situation: Business 2 Government: EN16931
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 bandwidth, 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 and Germany’s e-Rechnungsgesetz / e-Rechnungsverordnung define electronic invoices as structured, while the german law on VAT (Umsatzsteuergesetz) speaks of electronic 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 do not know what electronic invoices are.
The European standardization authority CEN has published EN16931 to augment 2014/55/EU. From it’s five parts the first, EN16931-1, the list of qualified syntaxes and EN16931-2, the calculation rules, are available free of charge.
Switzerland followed with electronic invoices in 2016. Germany national authorities started accepting electronic invoices as of November 2018 and made them compulsory as of November 2020 on a federal level as well as possible as of April 2021 on “subcentral” level (states, counties and cities).
B2B
Electronic invoicing is voluntarily in the B2B sector.
A 2022 initiative of the european parlaments, recommended a standard for cross-border B2B(?) E-invoices (Recommendation C1), but that does not say if anybody should be oblidged to send/receive B2B E-invoices. In December 2022 they detailled on more comprehensive plans to reform VAT in an initiative “VAT in the Digital Age” abbreviated ViDA, introduce a european CTC and on regulations on cross border e-invoices.
The exception is Italy, which introduced mandatory e-invoices on January 1st, 2019. Apparently, and potentially because of less fraud, in 2019 their VAT income was 3% higher than 2018.
France introduces mandatory B2B e-invoices between 2024-2026. Their national B2G invoice portal Chorus Pro (current documentation and EDI and API description) will apparently be extended and decentralized sub-portals will be certified.
After a (german) paper how the italian approach could also be applied on Germany the Federal Audit Office (Bundesrechnungshof) mentioned it, the Scientific Service of the Bundestag investigated and a political party requested mandatory B2B invoicing in Germany. In the 2021 coalition treaty to form the newly elected German government the parties agree to at least introduce a Continuous Transaction Control system (CTC) on the basis of individual invoices “We will introduce an electronic reporting system as quickly as possible on a uniform basis throughout Germany, which will be used for the creation, verification and forwarding of invoices. In this way, we will significantly reduce the susceptibility of our VAT system to fraud and at the same time modernize and reduce bureaucracy in the interface between the administration and businesses.” (“Wir werden schnellstmöglich ein elektronisches Meldesystem bundesweit einheitlich einführen, das für die Erstellung, Prüfung und Weiterleitung von Rechnungen verwendet wird. So senken wir die Betrugsanfälligkeit unseres Mehrwertsteuersystems erheblich und modernisieren und entbürokratisieren gleichzeitig die Schnittstelle zwischen der Verwaltung und den Betrieben.”). In November 2022 Germany asked the EU for permission to introduce domestic mandatory e-invoices and as of 18 April 2023 a discussion paper was circulated if that was possible to January 1st, 2025 ((german) source). This seems ambitious given the fact that today, in April 2023, not even the number of invoices is recorded, let alone their content.
Alexander Kollmann et al. described possible CTC models, and mention a rather limited effort to implement a model similar to France’s using Peppol: The french model is the right one in the diagram on their page 6, with the difference that also the government issues invoices.
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. Poland and Greece however, seem to consider mandatory B2B-e-invoices for “Entrepreneurs”.
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 4th (2020) “EU compendium on e-invoicing retention” which also lists the legal requirements for the different countries, the e-Invoicing country factsheets or the (german) collection on legal foundations for electronic invoices in the EU (Sammlung der Rechtsgrundlagen für elektronische Rechnungen in der EG).
German Situation
B2G
In August 2018 there was a 1h (english) speech on the 13th Froscon outlining the situation. Feel free to have a look at the slides and/or the video recording:
As defined in the german e-invoice law (amended E-Rechnungsgesetz in Bgbl 19/2017) and the E-Rechnungsverordnung, structured e-invoices became mandatory vis á vis the national authorities (and Bremen) as of November 2020. The following states will follow: Baden-Württemberg and Saarland (as of 2022), Mecklenburg-West Pomerania as of April 2023, Rhineland-Palatinate as of 2024 and Hesse as of 18.04.2024 (german source).
All European formats providing the according attributes are allowed but the first german “country version” (i.e. CIUS) was the XRechnung, now also ZUGFeRD’s EN16931 profile is listed.
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 potentially 300,000 stakeholders which may have been affected.
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.
B2B
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 (and potential embedded XML) 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 exhaustive 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.
With a 10 minute (still german) update in 2019.
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 has to be provided.
Calculation rules
EN16931 buy from your national standard body consists of 16931-1 to 16931-5, the first two of which are published free of charge, EN16931-1 (german version) covers the calculation rules, EN16931-2 (german version) the eligible formats.
Attribute values
There is a very helpful lists of all codes which can be used in EN16931 files, e.g. for currencies, countries, means of identification and units.
History
Further reading
- General topics
- The ECO coined the term passive acceptance
- Seeburger has a interesting whitepaper on Purchase-To-Pay
- GS1 Switzerland published a (german) Whitepaper on electronic hybrid invoices.
- 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
- Validation
- The CEN released Schematron for UN/CEFACT CII SCRDM 16B
- The X-Rechnung Validator (is based on that schematron and also contains XRechnung sample files)
- FNFE’s validator is based on the Factur-X-Validator
- The validator of ZUGFeRD Community is based on Mustangproject itself
- The CEF also deploys a validator as linked
- Peppol practical has a validator which has moved and is based on a open-source engine