Sending electronic invoices: What can you expect?

Whether on social networks or in industry trade journals, everyone is talking about the start of the so-called e-invoicing obligation on January 1, 2025. Put simply, from this date, companies must be able to receive and process electronic invoices for B2B transactions without prior consent.

However, this step is just the beginning, as you will generally have to gradually switch to an e-invoice format in subsequent years. There are exceptions, for example if an invoice does not exceed a total amount of 250 euros. In this article, however, we assume that you want to create an e-invoice and outline what you can expect. Very important: The topic is still subject to change and our article represents the status as of November 2024. Different requirements may therefore apply if you read it at a later date.

The term e-invoice may sound standardized, but it actually combines different data formats. You must first distinguish between hybrid and purely structured e-invoices. In a hybrid format, the invoice exists both as a generally readable document and as a structured data record. The best-known hybrid format in Germany is probably ZUGFeRD. Here, the structured data record is embedded as an XML file in a PDF document. If the generally readable part differs from the structured data record, the latter is decisive for the evaluation and processing of the invoice.

The group of purely structured data formats is in turn divided into formats that comply with the European standard EN 16931 and those that do not. Let's start with formats in accordance with EN 16931. The easiest way to think of the standard is as a multi-part guide, the first part of which specifies the content of the e-bill. In the second part, only the two XML formats UBL 2.1 and UN/CEFACT CII are currently declared to be compliant with the standard. At national level, these are becoming increasingly widespread in the form of XRechnung.

Formats that are not listed in EN 16931 are referred to by the Federal Ministry of Finance as 'other e-invoice formats'. This includes classic EDI formats, particularly those based on the EDIFACT or ANSI X12 standards. In the automotive industry in Germany, this is primarily VDA 4938, whereas in the retail, media and healthcare sectors it is more likely to be EANCOM INVOIC. In contrast to the receipt of EN-16931-compliant e-invoices, the invoice recipient must explicitly agree to the use of such formats.

As you can see, you are not simply introducing 'the' e-invoice, but one or more data formats from a whole group of candidates.

As described, the XRechnung is available in both CII and UBL format. Your customers may only be able to process one of the two formats, at least for the next few months. You could therefore be faced with the problem, at least in the initial phase, that important customers are not yet able to process your version of the XRechnung. Or your customer may prefer a different e-invoice format instead of an XRechnung, at least temporarily. In general, the following applies to data exchange: the customer usually specifies which format is to be used.

So to avoid unpleasant surprises, you should at least check for your most important customers in what form they expect e-invoices and ask for manuals for the required interfaces. You should also expect to have to implement several data exchange formats if you have not yet sent any e-invoices at all.

E-invoices are like onions: they have several layers. At the innermost core are the legal requirements, in Germany, for example, those of Section 14 of the Value Added Tax Act. These naturally also apply to an e-invoice. EN 16931 (and therefore the XRechnung) also recognizes the concept of the core invoice model and sender compliance.

The core invoice model defines various functionalities that an e-invoice should fulfill. To be compliant as a sender, you must be able to create invoices that meet the requirements of the core invoice model. The functionalities are divided into the areas of invoice issuance and delivery, invoice verification, posting, VAT registration, payment and auditing. The core invoice model has a total of 70 potential requirements, but in reality not all of them will apply to your invoices.

For reasons of space, we cannot present the requirements individually, but they can be roughly divided into the following areas:

• Dates on document and position level
• References on document and position level
• Informationen regarding the business parties on document level
• Currency Informationen on document level
• Charges and allowances on document and position level
• Customs and taxes on document and position level
• Line items with IDs, names and descriptions for the identification of goods or services
• The calculated quantity per invoice item
• Net or gross prices on position level
• Net amount per position
• Information on payment processing at document level
• Several total amounts of the invoice, e.g., the total VAT amount
• The VAT breakdown
• Additional documents justifying the invoice

The topic of 'documents justifying the invoice' is particularly exciting. These are documents, such as a time sheet, on the basis of which the invoice was created. They can be embedded in an XRechnung, but only if your software A) is technically capable of doing so and B) has the documents available at the time the invoice is created. Compared to other requirements, the topic can become more complex, so you should pay particular attention to this topic when analyzing customer requirements.

For a complete overview of the potential requirements in an XRechnung, we recommend visiting the website of the Coordination Office for IT Standards (KoSIT). Here you will not only find lots of information about XRechnung, but also the current documentation and sample messages.

In the top layer, you will find additional requirements from your customers or extensions to the core invoice model of EN 16931. VDA 4938 can, for example, contain the production number, mileage and first registration of vehicles. EANCOM INVOIC, on the other hand, recognizes package information at item level. And the XRechnung extends the core invoice model by recognizing invoice sub-items, among other things.

The actual requirements vary depending on the industry and customer. You can therefore only find out what is required of you if you systematically analyze your customers' manuals or requirements catalogs. If anything is unclear, it is advisable to identify a suitable contact on the customer side and discuss this with them.

The sheer volume of potential requirements may have just put you off. To take some of the sting out of the subject, we would like to share three more thoughts with you: First, the requirements of the top two tiers are at least partially industry or case specific. In addition, you probably only have to implement part of what is requested in your customers' manuals. For reasons of efficiency and overview, these are often written in such a way that they contain all possible business transactions. Possibly even those that do not apply to you at all.

Secondly, you can find numerous service providers at trade fairs or on the Internet who can help you implement e-billing. If you have already made a list of your customers' actual requirements, you can check which partner suits you by discussing the requirements with the candidates.

Thirdly, you still have plenty of time (at least if you are reading this article in winter 2024/25) to get started. We recommend that you ask customers with whom you have a particularly good business relationship whether they are available as pilot partners for the implementation. They may take more time to provide feedback and be more patient in correcting test files. As an added incentive, your customers will also benefit from being able to process your invoices automatically at an early stage.