E-Rechnung & ZUGFeRD: Der Praxis-Guide

Der haeufigste Irrtum bei diesem Thema steckt schon im Wort. Viele Betriebe verschicken seit Jahren PDF-Rechnungen per E-Mail und halten sich damit fuer "elektronisch". Das Gesetz sieht das anders.

Eine E-Rechnung im Sinne der Richtlinie ist eine Rechnung in einem strukturierten elektronischen Format, das eine automatische, elektronische Verarbeitung erlaubt. Entscheidend ist nicht, wie die Rechnung transportiert wird, sondern ob eine Maschine ihre Felder lesen kann, ohne zu raten.

Ein PDF ist ein Bild von einer Rechnung. Ein Mensch erkennt darauf den Rechnungsbetrag; eine Software muss ihn per Texterkennung erraten — mit allen Fehlern, die dabei entstehen. Genau das soll die Umstellung beenden.

Praktisch heisst das: Rechnungen werden zu Daten, nicht zu Dokumenten. Der Beleg, den ein Mensch ansieht, ist ab jetzt ein Nebenprodukt. Wer diese Perspektive uebernimmt, versteht auch die restlichen Anforderungen sofort.

Die drei Missverstaendnisse, die in der Praxis Geld kosten:

• "Wir schicken doch schon PDFs per Mail." — Ein PDF ohne eingebettete strukturierte Daten erfuellt die Anforderung nicht.
• "Das betrifft nur grosse Unternehmen." — Fuer den Empfang gibt es keine Umsatzschwelle. Wer eine Rechnung bekommt, muss sie verarbeiten koennen.
• "Wir kaufen einfach ein Tool." — Das Werkzeug loest den Versand. Der Empfang, die Pruefung und die Archivierung bleiben Ihre Aufgabe.

In Deutschland sind zwei Formate relevant. Beide erfuellen dieselbe europaeische Norm, unterscheiden sich aber deutlich in der Handhabung.

XRechnung ist reines XML. Keine Darstellung, kein Layout, nur Daten. Im Geschaeftsverkehr mit oeffentlichen Auftraggebern ist es der Standard. Der Vorteil ist die Eindeutigkeit: Es gibt genau eine Wahrheit, naemlich die im XML. Der Nachteil zeigt sich, sobald ein Mensch die Rechnung ansehen soll — dafuer braucht es zusaetzlich eine Darstellungsschicht.

ZUGFeRD ist ein Hybrid: ein PDF/A-3, in das dieselben XML-Daten eingebettet sind. Der Empfaenger sieht ein gewohntes Dokument, seine Software liest die Daten daraus. In der Praxis ist das der verbreitetere Weg, weil er keinen Bruch im Arbeitsablauf erzwingt.

Wichtig ist dabei das Profil. ZUGFeRD kennt mehrere Auspraegungen, und nicht jede erfuellt die Anforderung. Erst ab dem Profil, das der EN 16931 entspricht, enthaelt die Datei alle Pflichtfelder — praktisch heisst das ZUGFeRD ab Version 2.0.1 in einem Profil ab EN 16931 (frueher "Comfort"). Niedrigere Profile wie Minimum oder Basic-WL sind fuer die interne Nutzung gedacht und reichen als Rechnung nicht aus.

Entscheidungshilfe:

• Sie beliefern oeffentliche Auftraggeber: XRechnung, weil dort gefordert.
• Ihre Kunden sind gemischt und arbeiten teils manuell: ZUGFeRD ab dem passenden Profil.
• Sie bauen ein System, das beides empfangen muss: Sie brauchen ohnehin beide Lesepfade — die Datenstruktur dahinter ist identisch.

Der letzte Punkt wird oft uebersehen: Wer nur ans Versenden denkt, baut die halbe Loesung. Eingehende Rechnungen kommen in dem Format, das der Absender waehlt, nicht in Ihrem.

Die Umstellung laeuft gestaffelt. Wer nur die Endfrist kennt, plant moeglicherweise ein Jahr zu spaet.

Empfangen: seit dem 1. Januar 2025, ohne Ausnahme. Jedes Unternehmen in Deutschland muss E-Rechnungen entgegennehmen und verarbeiten koennen. Es gibt keine Umsatzschwelle und keine Uebergangsfrist. Auch Kleinunternehmer nach § 19 UStG sind erfasst — sie muessen empfangen koennen, auch wenn sie selbst noch keine ausstellen muessen.

Versenden: gestaffelt nach Umsatz.

1. Bis Ende 2026 duerfen alle Rechnungsaussteller weiterhin sonstige Rechnungen verwenden.
2. Ab dem 1. Januar 2027 muessen Unternehmen mit mehr als 800.000 Euro Gesamtumsatz im Vorjahr im B2B-Bereich E-Rechnungen ausstellen.
3. Ab dem 1. Januar 2028 gilt die Pflicht fuer alle Unternehmen, unabhaengig vom Umsatz.

Die Umsatzschwelle bezieht sich auf das vorangegangene Kalenderjahr. Wer 2026 die 800.000 Euro ueberschreitet, ist ab Januar 2027 in der Pflicht — die Vorbereitung muss also 2026 laufen, nicht 2027.

Der praktische Fehlschluss: "Wir haben bis 2028 Zeit." Das stimmt nur fuer den Versand und nur unterhalb der Schwelle. Der Empfang ist seit Anfang 2025 Pflicht, und genau dort liegt der Teil, der ohne eigene Vorbereitung nicht funktioniert.

Fuer den Geschaeftsverkehr mit oeffentlichen Auftraggebern gilt die XRechnung-Pflicht bereits deutlich laenger — wer dort liefert, kennt das Thema schon.

Die europaeische Norm EN 16931 legt fest, welche Felder eine Rechnung enthalten muss und in welcher Form. Sie ist die gemeinsame Grundlage beider Formate. Wer sie verletzt, produziert eine Datei, die formal keine gueltige Rechnung ist.

In der Praxis scheitern Umstellungen selten an exotischen Feldern. Es sind fast immer dieselben Stellen:

1. Leitweg-Identifikationsnummer — Im Geschaeftsverkehr mit Behoerden ist sie Pflicht und muss vom Auftraggeber kommen. Fehlt sie, wird die Rechnung abgewiesen, obwohl inhaltlich alles stimmt.
2. Steuerkategorien pro Position — Nicht der Gesamtbetrag traegt den Steuersatz, sondern jede Position. Systeme, die intern nur einen Satz kennen, brechen hier.
3. Rundungsdifferenzen — Die Norm verlangt, dass Summen rechnerisch aufgehen. Ein Cent Abweichung zwischen Positionssumme und Rechnungssumme ist kein Schoenheitsfehler, sondern ein Fehler.
4. Zahlungsbedingungen in strukturierter Form — "Zahlbar innerhalb von 14 Tagen" als Freitext genuegt nicht, wenn ein Faelligkeitsdatum gefordert ist.
5. Einheiten nach Codeliste — "Stk." ist keine gueltige Einheit. Es gibt eine feste Liste, und nur die zaehlt.

Der Punkt mit den Rundungen verdient besondere Aufmerksamkeit, weil er in gewachsenen Systemen fast immer auftritt. Wenn Ihr System Netto-Preise mit vier Nachkommastellen fuehrt und die Anzeige auf zwei rundet, ergibt die Summe der gerundeten Positionen nicht zwingend die gerundete Gesamtsumme. Auf Papier faellt das niemandem auf. Ein Validator meldet es sofort.

Die Loesung ist nicht, den Validator zu ignorieren, sondern die Rechenlogik anzupassen: Positionsbetraege werden gerundet gespeichert, und die Summe entsteht aus den gerundeten Werten. Das ist eine Aenderung an der Fachlogik, nicht am Export.

Der wichtigste Rat aus der Praxis: Bauen Sie die Pruefung ein, bevor Sie die erste Rechnung verschicken. Nicht danach.

Fuer XRechnung und ZUGFeRD gibt es einen offiziellen Pruefwerkzeug-Satz, der die Schema-Konformitaet und die Geschaeftsregeln testet. Genau der laeuft auch in unserer Demo unter /ki-demo/e-rechnung: Datei hochladen, Bericht ansehen.

Dabei sind zwei Fehlerklassen zu unterscheiden, und die Verwechslung kostet viel Zeit:

• Schema-Fehler heissen: Die Datei ist strukturell kaputt. Ein Pflichtfeld fehlt, eine Reihenfolge stimmt nicht, ein Datentyp passt nicht. Das ist ein technisches Problem im Export.
• Geschaeftsregel-Verstoesse heissen: Die Struktur stimmt, aber der Inhalt ist unschluessig. Summen gehen nicht auf, eine Steuerkategorie passt nicht zum angegebenen Satz, ein Pflichtfeld ist im konkreten Fall doch erforderlich. Das ist ein Problem in der Fachlogik.

Die zweite Klasse ist die unangenehmere. Sie laesst sich nicht durch besseres XML loesen, sondern erfordert Aenderungen dort, wo die Rechnung entsteht.

Was in eine Pipeline gehoert:

1. Rechnung erzeugen
2. Gegen das Schema pruefen
3. Gegen die Geschaeftsregeln pruefen
4. Erst bei bestandener Pruefung versenden
5. Pruefergebnis mit archivieren

Schritt fuenf wird gern gespart und ist doch der wertvollste. Wenn Monate spaeter jemand fragt, ob eine Rechnung korrekt war, ist der damalige Pruefbericht die Antwort.

Der Einstieg ist kleiner, als viele befuerchten. Fuer die haeufigsten Aufgaben — ZUGFeRD-XML aus einem PDF lesen und ein konformes XML erzeugen — reichen wenige Bausteine.

XML aus einem ZUGFeRD-PDF holen. Die Daten liegen als Anhang im PDF/A-3. Der Dateiname ist standardisiert, es lohnt aber, tolerant zu suchen:

from pypdf import PdfReader

ZUGFERD_NAMEN = {"factur-x.xml", "zugferd-invoice.xml", "xrechnung.xml"}

def extrahiere_rechnungs_xml(pfad: str) -> bytes | None:
    """Holt die eingebettete Rechnung aus einem ZUGFeRD-PDF."""
    reader = PdfReader(pfad)
    anhaenge = reader.attachments  # {name: [inhalt, ...]}
    for name, inhalte in anhaenge.items():
        if name.lower() in ZUGFERD_NAMEN and inhalte:
            return inhalte[0]
    return None

Liefert die Funktion None, ist es ein gewoehnliches PDF — also keine E-Rechnung. Genau an dieser Stelle entscheidet sich im Wareneingang, ob ein Beleg automatisch weiterlaeuft oder auf den Stapel "manuell pruefen" wandert.

Betraege richtig rechnen. Der haeufigste Fehler in Python-Implementierungen ist die Nutzung von Fliesskommazahlen fuer Geld. Nutzen Sie Decimal, und runden Sie bewusst:

from decimal import Decimal, ROUND_HALF_UP

def auf_cent(betrag: Decimal) -> Decimal:
    return betrag.quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

def summiere_positionen(positionen: list[dict]) -> Decimal:
    """Summe aus den GERUNDETEN Positionsbetraegen — nicht umgekehrt.

    Sonst weicht die Summe um Cent-Betraege ab und der Validator meldet
    einen Verstoss gegen die Rechenregeln.
    """
    return sum(
        (auf_cent(Decimal(str(p["menge"])) * Decimal(str(p["einzelpreis"])))
         for p in positionen),
        start=Decimal("0.00"),
    )

Der Kommentar im Code ist der eigentliche Inhalt dieses Abschnitts. Erst runden, dann summieren — nicht andersherum.

Pruefung in den Ablauf einbauen. Der Validator ist ein eigenstaendiges Programm. Es lohnt, ihn als Dienst zu betreiben und die Pruefung als festen Schritt zu verdrahten, statt sie Entwicklern zu ueberlassen:

async def rechnung_freigeben(xml: bytes) -> tuple[bool, str]:
    """Erst pruefen, dann versenden. Nie umgekehrt."""
    bericht = await validator.pruefe(xml)
    if not bericht.ist_konform:
        # Nicht versenden, aber auch nicht still verwerfen:
        # der Bericht sagt, welche Regel verletzt wurde.
        return False, bericht.als_klartext()
    await archiv.lege_ab(xml, bericht)
    return True, "konform"

Die meiste Aufmerksamkeit liegt beim Versand, die meiste Arbeit entsteht beim Empfang. Der Grund ist einfach: Beim Versand bestimmen Sie das Format. Beim Empfang bestimmt es der Absender.

Ein Eingangsprozess muss deshalb mit allem umgehen koennen, was ankommt:

• ZUGFeRD-PDF mit eingebettetem XML in verschiedenen Profilen
• reines XRechnung-XML als Anhang
• ein gewoehnliches PDF von einem Lieferanten, der noch nicht umgestellt hat
• eine Datei, die vorgibt konform zu sein, es aber nicht ist

Der letzte Fall ist der interessante. Wenn ein Lieferant eine fehlerhafte E-Rechnung schickt, haben Sie ein Problem, das Sie nicht selbst verursacht haben — aber loesen muessen, wenn Sie den Vorsteuerabzug behalten wollen.

Ein belastbarer Eingangsprozess sieht so aus:

1. Anhang erkennen und Typ bestimmen
2. Strukturierte Daten extrahieren, falls vorhanden
3. Validieren und das Ergebnis festhalten
4. Bei Fehlern: Beleg nicht stillschweigend verbuchen, sondern zur Klaerung ausleiten
5. Ergebnis dem Lieferanten zurueckmelden, statt es intern zu reparieren

Punkt fuenf ist eine organisatorische Entscheidung, keine technische. Wer fehlerhafte Eingangsrechnungen intern glattzieht, uebernimmt dauerhaft fremde Arbeit — und verliert den Nachweis, wie der Beleg urspruenglich aussah.

Genau hier lohnt sich Automatisierung am schnellsten: Die Pruefung laeuft in Sekunden, die Rueckmeldung an den Lieferanten laesst sich als Vorlage erzeugen. Was bleibt, ist eine menschliche Entscheidung — und die soll auch dort bleiben.

Zwei Punkte, die technisch unspektakulaer sind und trotzdem regelmaessig teuer werden.

Aufbewahrt wird das Original. Nicht der Ausdruck, nicht die Darstellung, nicht ein selbst erzeugtes PDF aus den Daten. Bei ZUGFeRD ist das PDF mit dem eingebetteten XML das Original; bei XRechnung ist es das XML. Wer nur die lesbare Fassung archiviert, hat die Rechnung im Sinne der Vorschrift nicht aufbewahrt.

Die Aufbewahrungsfrist fuer Buchungsbelege und Rechnungen betraegt acht Jahre (§ 147 Abs. 3 AO, § 14b Abs. 1 UStG; verkuerzt von zehn auf acht durch das Vierte Buerokratieentlastungsgesetz). Das ist lang genug, dass es technische Entscheidungen beeinflusst: Ein Dateiformat, ein Speicherort und ein Zugriffsweg muessen acht Jahre stabil bleiben — laenger als die meisten Softwareprodukte, die Sie heute einsetzen. Das spricht fuer schlichte, offene Ablagen und gegen proprietaere Archivformate.

Ohne konforme Rechnung kein Vorsteuerabzug. Das ist der eigentliche wirtschaftliche Hebel des Themas. Eine formal fehlerhafte Eingangsrechnung kann den Abzug kosten, und zwar rueckwirkend bei einer Pruefung. Deshalb gehoert der Pruefbericht ins Archiv: Er belegt, dass die Rechnung zum Zeitpunkt des Eingangs konform war.

Was in die Ablage gehoert:

• die Originaldatei, unveraendert
• der Pruefbericht mit Zeitstempel
• die extrahierten Kerndaten fuer die Suche
• ein Protokoll, wer den Beleg wann freigegeben hat

Der letzte Punkt kostet fast nichts und beantwortet spaeter die unangenehmste Frage von allen: Wer hat das eigentlich geprueft?

Die Umstellung laesst sich in eine Reihenfolge bringen, die frueh Nutzen bringt und spaet weh tut. Wer sie umdreht, arbeitet doppelt.

1. Empfang zuerst. Er ist die Pflicht ohne Schwelle und der Teil, der ohne Sie nicht funktioniert. Erst wenn eingehende Rechnungen sicher gelesen und geprueft werden, lohnt sich der Rest.
2. Validierung als Dienst. Bevor irgendetwas erzeugt wird, muss geprueft werden koennen. Sonst entwickeln Sie blind.
3. Rechenlogik geraderuecken. Rundung, Steuerkategorien pro Position, Einheiten nach Codeliste. Das ist die eigentliche Arbeit und betrifft Ihre Fachlogik, nicht den Export.
4. Erzeugung. Erst jetzt, mit funktionierender Pruefung im Ruecken, entsteht das Ausgangsformat.
5. Archivierung. Original plus Pruefbericht, in einer Ablage, die Jahre ueberlebt.

Der haeufigste Fehler ist, mit Schritt vier zu beginnen, weil er am sichtbarsten ist. Das Ergebnis sind Rechnungen, die huebsch aussehen und die Pruefung nicht bestehen.

Wenn Sie wissen wollen, wo Ihr aktueller Stand liegt, ist der schnellste Test der ehrlichste: Nehmen Sie eine echte Rechnung aus Ihrem System und lassen Sie sie pruefen. Das dauert eine Minute und sagt mehr als jede Selbsteinschaetzung.