Homepage 5 E-invoicing for software companies and developers

E-invoicing for software companies and developers

Software companies and developers play a key role in successfully establishing e-invoicing in both the public administration and the private sector. Are you a software company or developer? Do you want to make your software capable of exchanging electronic invoices with the authorities of Germany’s federal administration? If so, this page will provide you with an overview of what you need to know to successfully implement standard-compliant electronic invoicing.

About e-invoicing in the federal administration

A quick overview

  • The requirement to receive and process electronic invoices applies not only to public sector customers but also to their suppliers.
  • Since 27 November 2020, suppliers have been required to issue electronic invoices for services rendered under contracts and concessions with the public sector in accordance with section 1 of the federal E-Invoicing Ordinance (E-RechV).
  • It is therefore important that you, as a software company/developer, make it possible for your customers to issue standard-compliant invoices to their customers in the public sector.

Advantages of an e-invoicing software

You can greatly help your customers by providing them with software which allows them to do the following:

✓ create (standard-compliant) e-invoices

✓ transmit e-invoices securely and seamlessly

✓ receive, collect and forward e-invoices

✓ process invoice data

✓ archive e-invoices

By providing these functionalities and supporting standard-compliant e-invoicing, you will be greatly helping to realise the potential of digital technology and automation – from procurement through to payment.

Implementation of e-invoicing occurs in 3 phases

To help you incorporate e-invoicing, and especially the XRechnung standard, into your software, we have put together the following information relating to each phase of implementation.

1.

Planning phase

2.

Testing phase

3.

Production phase

1. Planning phase

In the planning phase, you will define the requirements for your software solution. In the section below, we explain what you need to know for this phase and what points to include in your design.

Requirements for the XRechnung standard for creating e-invoices

On 22 June 2017, Germany’s IT Planning Council decided to make XRechnung the standard format to implement the EU’s requirements for electronic invoicing. The XRechnung standard is Germany’s national version of the European standard EN 16931 – in other words the German CIUS.

An electronic invoice, in contrast with a paper or PDF invoice, is a structured, machine-readable XML file, which can be sent and received electronically, allowing seamless, automated, electronic processing.

In addition to the XRechnung standard, other standards can be used for electronic invoicing in public procurement, such as ZUGFeRD version 2.2.0 in the XRECHNUNG profile (since 1 July 2020 also available in the structured XML format only). However, other standards can only be used if they meet the requirements of

  1. the European standard on electronic invoicing (EN 16931),
  2. Germany’s federal E-Invoicing Ordinance,
  3. the terms of use of Germany’s ZRE and OZG-RE invoice submission portals.

Requirements for the XRechnung specification

As explained above, various requirements must be met by the e-invoicing standard used to exchange electronic invoices. The XRechnung specification meets these requirements; it is Germany’s realisation of the semantic data model of the European standard. XRechnung is an XML-based semantic data model. In Germany, this data model is the de facto standard for electronic invoicing. In other words, XRechung determines how electronic invoices are exchanged with offices of the federal administration, both from the perspective of the invoice recipient and from that of the invoice issuer.

The XRechung standard, which consists of various components, is developed and operated by the Coordination Office for IT Standards (KoSIT). This includes the XRechnung specification itself, which is composed of the semantic data model and the technical implementation of business rules. The business rules determine the logical dependencies of invoice contents and are an integral part of implementing the specification. We therefore recommend studying the legal provisions in detail.

In addition to the XRechnung specification, other components are provided which help to implement the standard at a technical level and/or can be used for the transmission of invoices:

  • a validator configuration – an open-source reference implementation used to check whether an XML document conforms to the XRechnung standard,
  • a test suite with test cases (sample invoices and test messages),
  • a development resource for the visualisation of XRechnung.

These components are provided, maintained and updated by KoSIT. They are important resources which you can use to implement processes, among other things, and which you can integrate into your software. Invoice validation, for instance, is important for receiving electronic invoices.

Another important issue in connection with electronic invoices in the XRechnung standard is that of mandatory syntaxes (Universal Business Language (UBL) version 2.1 and UN/CEFACT Cross Industry Invoice (CII)). These are specified by the European standard and must therefore be implemented / complied with. In using syntaxes you should be aware of the following:

  • If you provide a software solution for outgoing invoices, you can choose either of the two approved syntaxes.
  • However, if your software solution is for incoming invoices, it must be capable of processing both of the approved syntaxes. You are permitted to transform syntaxes by means of syntax mapping, but please note that mismatches may occur during transformation.

The list below provides further relevant information, including links which may be useful in the planning phase:

  • Information from KoSIT on the XRechnung standard: The Coordination Office for IT Standards (KoSIT) runs the XRechnung standard. This link will provide you with the XRechnung specification and other XRechnung components (information available in German only). XRechnung specification and other XRechnung components ›

  • KoSIT GitHub: This GitHub repository provides access to various components needed to implement the XRechnung standard. In addition to the code lists to be used, these include supporting tools, such as a validation component and visualisation component (development resources). GitHub KoSIT ›

  • KoSIT operating strategy for the XRechnung standard: The XRechnung operating strategy is a document adopted by the IT Planning Council. It is the basis for the operation of the XRechnung standard. “Operation” refers to all activities required for maintaining, upkeeping and providing the standard; for supporting the application of the standard; for communicating with interested parties; for representing the interests of the federal administration in standardisation committees at European level; and for all administrative activities required in this context (document available in German only). XRechnung operating strategy ›

  • XRechnung standard – Operation and support (FAQs): The KoSIT website answers frequently asked questions on implementing the XRechnung standard (web page provided in German only). FAQ XRechnung ›

Requirements in connection with transmission methods

The federal administration has two portals for transmitting e-invoices related to public procurement contracts: the Federal Central Invoice Submission Portal (Zentrale Rechnungseingangsplattform des Bundes, ZRE) and the Online Access Act-compliant Invoice Submission Portal (OZG-konforme Rechnungseingangsplattform des Bundes, OZG-RE). Organisations of the indirect federal administration may also have their own individual e-invoicing solutions.

  • Third-party/alternative solutions at federal level: Organisations of the indirect federal administration which cannot or do not want to use the OZG-RE must offer their suppliers alternative solutions for invoice submission.

 

When sending e-invoices to the federal administration via the federal invoice submission portals, senders have a choice of four possible transmission methods:

  1. Web submission
  2. Manual upload
  3. Peppol
  4. Email

The web submission and upload methods are adequate for sending smaller volumes of invoices, whereas email, and Peppol in particular, are more appropriate for sending high volumes of invoices. Peppol (Pan-European Public Procurement Online) enables machine-to-machine communication to take place, for example via a defined interface, allowing automated information exchange between senders and recipients of invoices.

Generally, when exchanging invoices via email and Peppol, e-invoices must first be created externally and then exchanged via the transmission method in question. On the invoice sender’s side, your solution should therefore at least allow the creation of standard-compliant invoices, and ideally automated sending.

For the successful implementation of XRechnung, you should already decide at the outset which transmission method you wish to use for exchanging e-invoices. As a software company or developer, you will probably want to enable your customers to transfer large volumes of invoices. The transmission methods best suited to this purpose are email and Peppol. The lists below compare the relative advantages of email and Peppol as transmission methods.

Advantages of email

  • Well-established transmission method
  • Widely available to senders and recipients of smaller volumes of invoices
  • Server structures usually already set up (therefore low maintenance, no extra costs)
  • Can be used immediately

Advantages of Peppol

  • High standard of security
  • Confirms delivery of documents
  • Future-proof, thanks to legally compliant document exchange (also in connection with upstream processes, e.g. procurement)
  • Interoperable thanks to uniform standards
  • Mass import of documents possible
  • Direct delivery

 

See also the Important information on using email as a transmission method in the ZRE and OZG-RE

For mass transmission, the federal web service can be used via Peppol. The web service is available through a SOAP or REST interface. Detailed information on Peppol is available on our Peppol page. 

Requirements for invoice information and contents

To produce a standard-compliant invoice, certain requirements must be met, as described above. These place further requirements on the contents of the e-invoice, and thus on the information to be processed by your system.

The step diagram below shows which requirements must be met by the invoice contents. This is followed by some examples illustrating the requirements.

Step-by-step model on content requirements starting with the requirement for the contractor and the client, legal provisions and XRechnung and EN 16931

Illustration: Step diagram of requirements for invoice contents

At the lowest step are the requirements of the EN 16931 and XRechnung standards. These ensure that the information elements of the data model are implemented. This is necessary in order for the invoice to conform to the XRechnung standard. Please note that since the introduction of XRechnung, new or reformatted information elements and/or invoice contents must be provided. Examples of this are the use of code lists and the requirement to enter a “buyer reference” (BT-10).

The relevance of legal provisions is particularly apparent in this context. In line with the E-Invoicing Ordinance (E-RechV), for instance, the required element “buyer reference” (BT-10) corresponds to the so-called Leitweg-ID . Other invoice contents and elements to be aware of are listed here.

In addition to the external factors (requirements stipulated by standards and regulations) you should also consider internal factors, i.e. the requirements of the invoice issuer and invoice recipient. You may find that invoice issuers and recipients have specific requests in terms of implementing reference data such as customer number, purchase order reference, or sales order number. In order for outgoing e-invoices to be delivered to the correct recipient via the correct submission method, it should be made possible to specify not just the buyer reference but also the invoice submission portal used by the recipient, as well as the transmission method (email, Peppol) and/or associated address (email, Peppol) of the recipient.

2. Testing phase

Testing phases allow you to carry out defined tests with defined tasks to check whether your system’s behaviour is as it should be. When exchanging invoices with the federal administration, in addition to meeting standard requirements, the invoices your system receives or sends must be checked to ensure they are valid / standard compliant. When e-invoices are sent from your system, there also needs to be confirmation of whether they have arrived safely with the recipient. Key information about this is provided below.

Validation of e-invoices

After your system has successfully created or received e-invoices compliant with the XRechnung standard, it is very important to check their validity. E-invoices must be validated in order to avoid processing errors. And only valid invoices can be exchanged via the Peppol network, for instance.

To help with this, the Coordination Office for IT Standards (KoSIT) provides a validator configuration along with testing rules and reference implementations. We recommend that these be taken into account already in the planning and deployment phases. The testing module is an open-source solution and helps with validating invoices to ensure that they conform with the XRechnung standard.

Transmission testing

Transmission tests should be carried out to ensure that e-invoices can be successfully sent and delivered to the correct recipient. Below you will find some important resources which can be used for testing.

For both of the federal invoice submission portals (ZRE and OZG) test environments are provided specifically for test purposes. These test environments function almost exactly like the production environments of their respective portals. The difference is that e-invoices submitted via these environments are not processed or paid by the invoice recipient. Nevertheless, using the test environments of the submission portals, you can check whether invoices have been successfully transmitted. Below are links to the test environments of both the ZRE and the OZG-RE.

In addition to the invoices produced by your system, the Coordination Office for IT Standards (KoSIT) provides test messages and test invoices in the current specification for each portal. These can be used for transmission tests – including for incoming invoices.

  • KoSIT: The Coordination Office for IT Standards (KoSIT) maintains and develops the XRechnung standard. Homepage of the KoSIT ›

  • GitHub: This GitHub repository provides access to various components needed to implement the XRechnung standard. In addition to the code lists to be used, these include supporting tools, such as a validation component and visualisation component (development resources). KoSIT Github ›

3. Production phase

In production, it is important to note that XRechnung is subject to a regular release cycle.

Releases

KoSIT releases a new version of the XRechnung specification twice a year: on 31 July (summer release) and 31 January (winter release). Each release becomes valid six months later, on 1 February and 1 August, respectively. The federal invoice submission portals (ZRE and OZG-RE) are constantly being updated and are always able to work with new releases.

Please stay informed about new releases and updates via the KoSIT website (German only).