DE
Book an appointment
 
HELP CENTRE · DATEV · E-INVOICING · FP SIGN

Answers when you need them.

Step-by-step guides with videos on DATEV Unternehmen online, Meine Steuern, DATEV Personal, e-invoicing and FP Sign. Still have a question? Our assistant can help, or simply get in touch with us.

24/7available
DATEVMember

E-invoices: how to create an e-invoice

An e-invoice does not require any new invoice details – the mandatory information remains the same; only the format changes. This guide explains how to create an e-invoice.

Introduction

If you issue invoices to other businesses, this applies to your outgoing invoices. Depending on your transition period, your outgoing invoices will eventually need to be e-invoices – the content changes less than many people expect. We’ll guide you through the transition and help you choose the right format.

A few clarifications first, as there are often misunderstandings here:

An e-invoice does not require any new mandatory content. The details specified under Section 14 of the German Value Added Tax Act (UStG) are the same as on a paper invoice.

What is changing is the format: the details must now be included in the structured data set, not just in the visible part. It is not sufficient for a mandatory detail to be provided as an attachment or as a reference to an external document.

This guide goes through the mandatory details, explains the structured format, the sequence of data and technical requirements, and the choice of format. We will cover how to send a completed e-invoice in a separate section.


What is changing – and what isn’t

The most common misconception is that an e-invoice is an invoice with different content. This is not the case. An e-invoice is the same invoice in a structured format.

The mandatory details, the logic behind VAT and the commercial content remain unchanged. What is changing is the technical structure of the invoice and how it is transmitted.

This distinction helps with the transition. Anyone who currently issues their invoices correctly does not need to relearn what belongs on an invoice – they simply need to ensure that this information is included in a structured data set in future.


Mandatory details under Section 14 of the German Value Added Tax Act (UStG)

The mandatory details are set out in Section 14 of the German Value Added Tax Act (UStG) and apply to e-invoices in exactly the same way as before. A complete invoice contains:

  • the full name and address of the supplier and the recipient
  • the tax number or VAT identification number of the supplier
  • the date of issue
  • a sequential invoice number
  • the quantity and type of goods supplied or the scope and nature of the service
  • the date of supply (date of supply or period of supply)
  • the consideration, broken down by tax rates and exemptions
  • the applicable tax rate and the amount of tax, or a reference to a tax exemption

In certain cases, further details are required, such as the note ‘Tax liability of the recipient’ in the event of a reverse charge, or the term ‘credit note’ when the recipient issues the invoice.

Simplified details apply to low-value invoices up to 250 euros, and these are exempt from the e-invoicing requirement. We will deal with which invoices are exempt separately. \[Link zu einem Hilfsartikel]


New: all mandatory details in the structured section

The most significant change when creating invoices does not concern the content, but rather the location of the details. All mandatory details must be included in the structured data set – the XML file.

It is no longer sufficient for the details to appear anywhere on the invoice. Only what is contained in the machine-readable section is legally considered to be the content of the invoice. A non-embedded attachment or a link to an external destination is not sufficient to fulfil a mandatory requirement.

For hybrid formats, the structured part is what counts

With ZUGFeRD, there is the visible PDF and the embedded data record. The structured part is legally binding. If the content of the PDF and the data record differ, this may be regarded as a second, potentially incorrect invoice – with the risk of double tax reporting.

You should therefore ensure that the visible display and the data set match. In practice, your software ensures this, provided you generate the invoice within the programme and do not subsequently modify the PDF.

If a mandatory field is missing from the structured part, the invoice may be considered incomplete despite having a technically correct format. One example is the buyer reference, which is required as a routing ID for invoices sent to public authorities. We will cover what the routing ID is in a separate section. \[Link zu einem Hilfsartikel]


Data first, then technology

When making the switch, it’s worth thinking in the right order. The focus should be on clean data, not the technology.

If your master data is correct – complete addresses, correct tax numbers, clear service descriptions – the transition to the structured format is manageable. An e-invoice is only as good as the data that goes into it.

The technology is the final step. An invoicing programme generates the structured format from the recorded data and checks it. If, on the other hand, you start with unclear master data, you’re simply shifting the problems into a new format.


Which format for which recipient

When creating an invoice, choose the format that suits your recipient. You do not need to be proficient in both formats.

For invoices to other businesses, ZUGFeRD is often the practical choice, as the visible PDF can be read without specialist software.

For invoices to public authorities, XRechnung is usually required, often together with a routing ID.

In many invoicing programmes, the default format can be set in the settings, so you only need to make the choice once.


How to create an e-invoice (general)

The process is similar to the usual invoicing procedure; the only difference is that the invoice is output in a structured format. An invoicing programme handles the technical steps for you.

  1. Check your master data

    Ensure that addresses, tax numbers and customer details are complete and correct. Errors here will affect every invoice.

  2. Enter the service

    You enter the service, quantity, service date and amount payable, along with the tax rate and tax amount – just as you would for any invoice.

  3. You select the format

    You select ZUGFeRD or XRechnung, depending on the recipient. In many programmes, this is pre-set for each customer.

  4. You generate and check the invoice

    You let the software generate the e-invoice. A validation check verifies the format and business rules before you send it.

  5. You send the invoice

    You send the completed e-invoice to the recipient. We’ll cover the sending process separately.


Special cases when creating invoices

Some scenarios differ from the standard case and are explored in more detail in separate articles.

In the case of advance payments and instalment invoices, settlement is spread over several stages; the final invoice therefore requires special handling:

In the case of a credit note, the service recipient issues the invoice, which must also comply with the requirements for e-invoices:

For ongoing services such as tenancy or maintenance contracts, a single e-invoice referring to the contract is sufficient at the start of the service period; if mandatory details change, for example due to a rent increase, a new e-invoice is required:


Common sources of error

  • Mandatory information only in the visible section: A piece of information appears in the PDF but is missing from the structured data record. Legally, the data record is what counts, so the invoice may be deemed incomplete.
  • PDF modified retrospectively: The visible PDF is amended after generation without updating the data record. The PDF and the data record then differ, carrying the risk of duplicate tax reporting.
  • Mandatory information as an attachment: A required piece of information is moved to a separate attachment. This is not permitted for mandatory information; it must be embedded.
  • Inaccurate master data: Addresses or tax numbers are stored incompletely. These errors are carried over into every e-invoice generated and jeopardise the recipient’s right to claim input tax deduction.
  • Format incompatible with the recipient: A pure XRechnung is sent to a recipient who can only open PDFs. Without a viewer, they cannot read the invoice.
  • Not checked before sending: The invoice is sent without validation. Format or business rule errors then lead to queries or rejection by the recipient.

How we work together

For outgoing invoices, you create the invoices; we ensure correct tax classification and posting.

Your tasks:

  • Maintain accurate master data and record services in full
  • Select the appropriate format for each recipient
  • Generate e-invoices and have them checked before dispatch

Our tasks:

  • Advising you on mandatory details and special cases
  • Posting outgoing invoices and classifying them for tax purposes
  • Provide support with questions regarding format or content

The exact breakdown depends on your software and your invoicing model.


Frequently asked questions

Does an e-invoice require different mandatory details to a paper invoice?

No. The mandatory details under Section 14 of the German Value Added Tax Act (UStG) are the same. The only change is that they must be included in the structured data set.

Is it sufficient for the details to appear in the visible PDF?

No. For an e-invoice, it is the structured part that counts. Mandatory details must be included there, not just in the PDF or in an attachment.

What happens if the PDF and the data record differ in ZUGFeRD?

The data record is legally binding. A discrepancy in content may be regarded as a second, incorrect invoice and result in double tax reporting. Please ensure they match.

Which format should I use for my customers?

For other businesses, ZUGFeRD is usually the most practical option; for public authorities, it is generally XRechnung. In many programmes, the format can be pre-set for each customer.

Do I need to change my invoicing software?

Not necessarily. Many programmes already generate e-invoices or are due for an update. Check whether ZUGFeRD and XRechnung are supported; if not, we’ll work with you to find the right solution.

How do I issue an invoice to a public authority?

Usually as an XRechnung, often with a routing ID provided to you by the public sector client. We’ll cover the details in a separate article. \[Link zu einem Hilfsartikel]

What about interim and final invoices?

These are also e-invoices where the obligation applies. Offsetting interim payments against the final invoice requires special handling, which we’ll explain separately. \[Link zu einem Hilfsartikel]

Do I need to check the invoice myself before sending it?

Validating the invoice before sending it is advisable to avoid errors relating to format and business rules. Invoicing software usually handles this automatically.


Legal notice

This article provides an overview and is not a substitute for individual advice. The legal situation and its interpretation may change; the current status at any given time is decisive. The information and format required in your case depend on your services and recipients.

If you have any questions about invoicing, please contact us directly.

Last updated: June 2026

Still have questions on this topic?