Legal background to the digital invoice and current potentials

There is much uncertainty regarding the digital invoice (eInvoice). Especially when trying to compare the requirements for eInvoices to the federal government with the general requirements for entrepreneurs.

As a common starting point, it can be noted that the eInvoice has been equated with the paper invoice with the EU Directive 2010/45/EU.

It becomes more difficult when it comes to the definition of an e-invoice.

As an example: In the EU Directive 2010/45/EU under Article 217[1] “For the purposes of this Directive, “electronic invoice” means an invoice which contains the information required by this Directive and is issued and received in an electronic format”. This definition of the EU Directive is very broad and thus allows an image based PDF sent by email.

Directive 2014/55/EU says: (7)3 The benefits of electronic invoicing will be maximized if the creation, sending, transmission, receipt and processing of an invoice can be fully automated. For this reason, only machine-readable invoices that can be processed automatically and digitally by the recipient should be considered to comply with the European e-invoicing standard. A simple image file should not be considered an electronic invoice for the purposes of this Directive.

In opposite to this, the Federal Law Gazette for the Republic of Austria published the year 2012 as of December 27, 2012 505. Regulation: e-Invoice Regulation Definition e-Invoice §2. ” An electronic invoice (e-invoice) is an invoice that is issued, sent, received and processed in a structured electronic format.[2]

There is again agreement on the storage obligations and the authenticity and integrity of electronic invoices. “The authenticity and integrity of electronic invoices can also be ensured by using certain existing technologies, such as electronic data interchange (EDI) and advanced electronic signatures. However, since other technologies exist, taxable persons should not be required to use a specific technology for electronic invoicing”(11)1

In addition, the European e-invoicing standard should also be suitable for use in business-to-business transactions.(22)[3]

To sum up: In contrast to Germany or Switzerland, in Austria it is allowed to store an invoice received as PDF via email according to the Federal Fiscal Code (BOA) by printing it out and archiving it in paper form. If this is done electronically, the authenticity and integrity must be proven over the archiving period. Signing the invoice itself on the receiving side or using the EDI procedure are examples. As stated in Directive 2010/45/EU, the taxpayer cannot be prescribed a specific technology.

For this reason, Difacturo has developed a technology that meets all the requirements for authenticity and integrity through an encrypted document in the cloud, secured by a block chain.

There are now many ways to create an e-invoice. The format ebInterface for e-invoices to the federal government, developed by the working group AustriaPro of the Austrian Federal Economic Chamber, is one of them.

Since the storage obligations for invoices – e-invoices are not excluded from this – are regulated in the BAO and EDI is a defined exception, it is still to be clarified how ebInteface (XML files) are to be stored in order to prove their authenticity and integrity.

In the Federal Law Gazette 516 [4] the requirement for electronic invoicing is also determined:

  1. Internal control procedure – Audit trail
  2. Transfer via company service portal or via PEPPOL (Pan-European Public Procurement OnLine)
  3. The invoice is provided with a qualified electronic signature
  4. Transfer of the invoice by electronic data interchange (EDI) if the agreement on this data interchange provides for the use of procedures guaranteeing the authenticity of the origin and integrity of the data.

The problem is that ebInterface can either be sent via interface from the system of the invoice sender to an interface of the recipient system or can be sent as XML document e.g. via email. The former thus falls under the definition of an EDI interface, see point 4 above. As a result, the EDI Directive 94/820/EC [5] is applied and an agreement must be concluded with each customer and supplier or a branch agreement must be used. Like any other invoice document, an XML document falls under the archiving obligations of the BAO.

The use of alternative formats, such as the ZUGFeRD format (Zentraler User Guide Forum elektronische Rechnungen Deutschland) [6], which was decided upon in Germany, fulfills the CE16931 standard of a structured electronic invoice with embedded XML (eXtensible Markup Language) according to CII (Cross Industry Invoice).

The advantage is that the recipient of the e-invoice in ZUGFeRD format receives a PDF/A3 and can capture it by manual capture and printing, or automatically with most accounting systems without manual intervention.

For example, a virtual printer driver can be used to create a ZUGFeRD e-invoice. This means that all programs from Word and Excel to fakutrierung or ERP systems can easily generate e-invoices.


[1] COUNCIL DIRECTIVE 2010/45/EU of 13 July 2010 amending Directive 2006/112/EC on the common system of value added tax as regards the rules on invoicing

[2] FEDERAL LAW GAZETTE FOR THE REPUBLIC OF AUSTRIA 505. Decree of the Federal Minister of Finance on the submission of e-invoices to federal agencies (e-invoice decree)

[3] DIRECTIVE 2014/55/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 16 April 2014 on electronic invoicing for public procurement

[4] FEDERAL LAW GAZETTE FOR THE REPUBLIC OF AUSTRIA 516. Decree of the Federal Minister of Finance amending the Decree determining the requirements for invoices transmitted by electronic means

[5] Commission Recommendation 94/820/EC on the legal aspects of electronic data interchange

[6] https://www.ferd-net.de/zugferd/definition/ferd.html

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

Leave a Reply

Your email address will not be published. Required fields are marked *