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 statutory for invoices to authorities in Europe, including in Germany. In Italy (and Hungary) they are already mandatory also between companies, they are approved to becoming mandatory for companies in France, in the process of becoming approved to become mandatory for businesses in Germany and, in the context of Vat in the digital Age, VIDA, also in the rest of Europe.
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:
- 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.
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.
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.
- 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
- 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