E-Rechnung Beispiel: XRechnung & ZUGFeRD in der Praxis

Seit dem 01. Januar 2025 gilt im deutschen B2B-Kontext die E-Rechnungspflicht. Unternehmen müssen E-Rechnungen empfangen können, und für die Ausstellung gelten Übergangsregelungen, die je nach Unternehmensgröße und technischem Setup unterschiedlich wirken. Viele Unternehmen haben bisher elektronische Rechnungen als PDF verschickt – doch für B2B ist seit 01.01.2025 der strukturierte Datensatz der entscheidende Punkt. Eine einfache PDF-Rechnung ohne eingebettete XML-Daten erfüllt die gesetzlichen Anforderungen nicht mehr.

Typische Unsicherheiten betreffen die Frage, was überhaupt als E-Rechnung gilt und was lediglich digital verschickt wurde. Praxisfragen lauten: Wie sieht eine XRechnung im XML aus? Was steckt bei ZUGFeRD im PDF? Welche Felder sind Pflicht? Wie werden Fehler erkannt? Wie läuft das in ERP, P2P und O2C wirklich? Entscheiderinnen und Entscheider fragen sich, was organisatorisch und technisch minimal erfüllt sein muss, um Rechnungen zu empfangen, was mittelfristig sauber umgesetzt werden muss, um Rechnungen zu versenden, und wie Audit- und GoBD-Risiken reduziert werden können.

Dieser Guide zeigt Ihnen an konkreten Beispielen, was eine E-Rechnung ist, wie sie strukturiert ist, welche Formate relevant sind und wie die Umsetzung in O2C und P2P inklusive Governance, Betrieb und Compliance gelingt. Sie erfahren, welche Pflichtfelder erforderlich sind, wie Validierung funktioniert, wie Archivierung GoBD-konform erfolgt und wie Sie die Prozessintegration belastbar gestalten.

Hinweis: Stand 2026. Keine Rechtsberatung. Anforderungen können je nach Einzelfall, Branche, ERP-System und Übertragungsweg abweichen.

Was ist eine E-Rechnung und was nicht?

Eine E-Rechnung ist eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt, empfangen und verarbeitet werden kann. Sie basiert in der Regel auf der europäischen Norm EN 16931. Der entscheidende Unterschied zu bisherigen elektronischen Rechnungen liegt im strukturierten Datensatz, der maschinenlesbar ist.

Eine PDF-Rechnung ohne strukturierten Datensatz ist keine E-Rechnung im Sinne der gesetzlichen Vorgaben. Auch Scans, Word- oder Excel-Dateien erfüllen die Anforderungen nicht. Elektronisch versendet bedeutet nicht automatisch E-Rechnung. Der XML-Datensatz ermöglicht es Buchhaltungsprogrammen, alle Daten automatisch auszulesen, was eine große Zeitersparnis mit sich bringt und Fehler bei der manuellen Übertragung minimiert.

Abgrenzung zu EDI und weiteren Geschäftsdokumenten

E-Rechnung betrifft Rechnungsdaten (Invoice). EDI kann zusätzlich Orders, Order Responses, Despatch Advice, Lieferscheine, Zahlungsavis und weitere Dokumente umfassen. Das ist ein größerer Integrationsumfang als nur E-Rechnung. Für Entscheiderinnen und Entscheider ist wichtig: E-Rechnung kann ein Einstieg sein, ersetzt aber nicht automatisch eine vollständige EDI-Prozesskette. Automatisierung, geringere Erfassungsfehler, bessere Matching-Qualität und schnellere Durchlaufzeiten sind die Hauptvorteile.

Rechtlicher Rahmen und Zeitplan seit 2025

Seit 01. Januar 2025 gilt im deutschen B2B-Kontext die E-Rechnungspflicht. Unternehmen müssen seit diesem Datum E-Rechnungen empfangen können. Die Empfangsfähigkeit bedeutet nicht nur, die Datei zu öffnen, sondern diese kontrolliert anzunehmen, zu validieren, in Workflows zu integrieren und GoBD-konform zu archivieren.

Für die Ausstellung gelten Übergangsregelungen, die in der Praxis je nach Konstellation, Unternehmensgröße und technischem Setup unterschiedlich wirken können. Unternehmen sollten 2026 bereits in der Umsetzung oder Skalierung sein und die Roadmap bis zum Ende der Übergangsphasen abgesichert haben.

Deutschland folgt dem europäischen Trend zu nahezu flächendeckendem E-Invoicing und nachgelagerten Meldesystemen. Ein elektronisches Meldesystem im Umsatzsteuerkontext ist politisch und strategisch vorgesehen. E-Rechnung ist dafür ein zentraler Baustein. Termine und Ausgestaltung können sich ändern, weshalb Unternehmen ihre Prozesse flexibel und auditfähig gestalten sollten.

Welche Angaben gehören auf eine E-Rechnung?

Klassische Pflichtangaben nach UStG (§ 14 und § 14a je nach Fall) umfassen in der Praxis unter anderem: Name und Anschrift von Rechnungsaussteller und -empfänger, Leistungsbeschreibung, Leistungszeitpunkt, Entgelt, Steuersatz, Steuerbetrag, Bruttobetrag, Rechnungsdatum und Rechnungsnummer.

Für Automatisierung, Matching und Cashflow sind zusätzlich prozessrelevante Informationen wichtig: Bestellnummer oder PO-Referenz, Lieferantennummer, Vertrags- oder Projektbezug, Fälligkeit, Zahlungsbedingungen wie Skonto und Zahlungsziel sowie Bank- und Zahlungsinformationen, wo erforderlich.

Für E-Rechnungen an öffentliche Auftraggeber des Bundes sind nach ERechV außerdem die E-Mail-Adresse des Rechnungsausstellers und die Leitweg-Identifikationsnummer notwendig. Diese Zusatzangaben sorgen dafür, dass Rechnungen nicht nur formal korrekt sind, sondern auch automatisiert verarbeitet werden können.

XRechnung vs. ZUGFeRD: Formate und Entscheidungshilfe

In Deutschland sind zwei Hauptformate für E-Rechnungen etabliert: XRechnung und ZUGFeRD. Beide basieren auf der europäischen Norm EN 16931 und transportieren fachlich ähnliche Inhalte. Der Unterschied liegt in der Verpackung und der Art, wie die Daten für Mensch und Maschine zugänglich gemacht werden.

XRechnung

XRechnung ist ein rein maschinenlesbares Format. Es wird als XML-Datensatz bereitgestellt. Öffnen Sie eine XRechnung, sehen Sie auf Ihrem Bildschirm kryptische Verschlüsselungen, die an Computercode erinnern. Doch in diesem Code befinden sich alle Informationen, die für die Rechnungsstellung benötigt werden. Das Format ist sehr klar validierbar und stark standardisiert. XRechnung wird häufig im Public Sector verwendet und ist typisch für hohe Automatisierungsgrade.

ZUGFeRD

ZUGFeRD ist ein hybrides Modell. Es kombiniert ein PDF/A-3-Dokument mit einem eingebetteten XML-Datensatz. Das bedeutet: Der Fachbereich kann die Rechnung wie gewohnt visuell prüfen, während das Buchhaltungsprogramm den XML-Datensatz ausliest. ZUGFeRD wird häufig im B2B-Kontext eingesetzt, wenn visuelle Prüfung und Kommunikation über PDF weiterhin wichtig sind. Ein erstes Indiz für ein ZUGFeRD-Dokument ist, dass das Dateiformat größer ist als bei einer reinen PDF-Rechnung.

Entscheidungskriterien

Die Wahl des Formats hängt von mehreren Faktoren ab:

• Empfängeranforderungen und Kundenpräferenz (Format, Profil, Kanal)
• Prozesszielbild (Dunkelverarbeitung vs. Sichtprüfung und Workflow)
• Systemlandschaft und Tooling (ERP, DMS, Invoice Processing, Schnittstellen)
• Multi-Format-Strategie (ein Format standardisieren vs. Gateways und Mapping)
• Betriebsfähigkeit (Monitoring, Fehlerhandling, Support)

Voraussetzungen für die Umsetzung

Bevor Sie E-Rechnungen erstellen oder empfangen, sollten Sie folgende Voraussetzungen prüfen:

• Software, die E-Rechnungen erzeugen oder verarbeiten kann (ERP, Faktura, Invoice Processing)
• Klärung des gewünschten Formats mit Geschäftspartnern (XRechnung oder ZUGFeRD)
• Definierte Eingangskanäle (E-Mail, Portal, Schnittstelle, Netzwerk wie Peppol)
• Validierungsmechanismen (technisch und fachlich)
• Workflow für Prüfung, Freigabe und Kontierung
• GoBD-konforme Archivierung (XML und gegebenenfalls PDF)
• Berechtigungskonzepte und Rollen (Finance, IT, Shared Services)
• Monitoring und Fehlerhandling (Backlogs, Rückweisungen, Korrekturen)

Schritt-für-Schritt-Anleitung: E-Rechnung erstellen und versenden

Schritt 1: Passende Software auswählen

Wählen Sie eine Software, die in der Lage ist, E-Rechnungen im gewünschten Format zu erzeugen. Das kann Ihr bestehendes ERP-System sein, eine Fakturierungslösung oder eine Middleware, die Konvertierung und Mapping übernimmt. Prüfen Sie, ob die Software XRechnung, ZUGFeRD oder beide Formate unterstützt. Stellen Sie sicher, dass die Software die Anforderungen der EN 16931 erfüllt und Validierung sowie Fehlerhandling integriert hat.

Schritt 2: Format und Profil mit Partnern abstimmen

Besprechen Sie mit Ihren Kunden oder Lieferanten, in welchem Format die E-Rechnung bevorzugt wird. Klären Sie, ob XRechnung oder ZUGFeRD genutzt werden soll. Fragen Sie nach spezifischen Profilanforderungen oder zusätzlichen Feldern, die für die automatisierte Verarbeitung beim Empfänger wichtig sind. Dokumentieren Sie diese Anforderungen und pflegen Sie Partnerprofile, damit Ihre Software die Rechnungen entsprechend erzeugt.

Schritt 3: Rechnung im System erstellen

Erfassen Sie die Rechnungsdaten in Ihrem führenden System (ERP, Faktura). Achten Sie darauf, dass alle Pflichtfelder ausgefüllt sind: Rechnungsnummer, Datum, Name und Anschrift von Aussteller und Empfänger, Leistungsbeschreibung, Entgelt, Steuersatz, Steuerbetrag, Bruttobetrag. Ergänzen Sie prozessrelevante Felder wie Bestellnummer, Lieferantennummer, Fälligkeit und Zahlungsbedingungen. Wenn Sie an öffentliche Auftraggeber versenden, fügen Sie E-Mail-Adresse und Leitweg-ID hinzu.

Schritt 4: Validierung durchführen

Lassen Sie die erzeugte E-Rechnung durch eine Validierungssoftware prüfen. Die Validierung umfasst technische Prüfung (XML-Struktur korrekt) und fachliche Prüfung (Summenlogik, Pflichtfelder, Steuercodes, Referenzen). Beheben Sie Fehler, bevor Sie die Rechnung versenden. Validierungsfehler führen beim Empfänger zu Rückweisungen und verzögern den Zahlungsprozess.

Schritt 5: Rechnung versenden

Verschicken Sie die E-Rechnung über den mit dem Empfänger vereinbarten Kanal. Das kann E-Mail (mit Anhang), ein Portal, eine Schnittstelle oder ein Netzwerk wie Peppol sein. Laden Sie die Rechnung herunter oder lassen Sie sie automatisiert vom System versenden. Stellen Sie sicher, dass Sie einen Nachweis über den Versand erhalten (Audit-Trail). Protokollieren Sie Versandzeitpunkt, Empfänger und verwendetes Format.

Schritt 6: Fehlerhandling und Resend

Überwachen Sie, ob die Rechnung erfolgreich beim Empfänger angekommen ist. Falls eine Rückweisung oder ein Reject erfolgt, prüfen Sie die Fehlermeldung. Korrigieren Sie die Rechnung im System, validieren Sie erneut und versenden Sie die Rechnung neu. Richten Sie ein klares Fehlerhandling ein: Wer ist verantwortlich? Wie werden Fehler eskaliert? Welche SLAs gelten?

Schritt-für-Schritt-Anleitung: E-Rechnung empfangen und verarbeiten

Schritt 1: Eingangskanäle standardisieren

Definieren Sie, über welche Kanäle Ihr Unternehmen E-Rechnungen empfängt. Typische Kanäle sind E-Mail, Portale, Schnittstellen oder Netzwerke. Vermeiden Sie Wildwuchs, da sonst Schattenprozesse und Compliance-Risiken entstehen. Kommunizieren Sie Ihren Lieferanten die zugelassenen Kanäle klar und verbindlich.

Schritt 2: Automatisierte Annahme und Validierung

Richten Sie in Ihrem Invoice-Processing-System oder ERP eine automatisierte Annahme ein. Jede eingehende E-Rechnung wird technisch und fachlich validiert. Prüfen Sie XML-Struktur, Summenlogik, Pflichtfelder, Steuercodes und Referenzen. Fehlerhafte Rechnungen landen in einer Queue und werden an Verantwortliche zur Klärung weitergeleitet.

Schritt 3: Matching und Workflow

Führen Sie ein Matching durch: Vergleichen Sie die Rechnungsdaten mit Bestellungen (2-Way-Match) oder zusätzlich mit Wareneingangsdaten (3-Way-Match). Bei erfolgreicher Übereinstimmung wird die Rechnung automatisch zur Kontierung und Zahlung freigegeben (Dunkelverarbeitung). Bei Abweichungen oder fehlenden Referenzen startet ein Klärungsworkflow mit manueller Prüfung und Freigabe.

Schritt 4: Kontierung und Buchung

Nach erfolgreicher Prüfung und Freigabe wird die Rechnung im ERP-System kontiert und gebucht. Die strukturierten Daten aus dem XML-Datensatz werden automatisch übernommen, sodass keine manuelle Erfassung mehr nötig ist. Das reduziert Fehler und beschleunigt den Prozess erheblich.

Schritt 5: Archivierung

Archivieren Sie die E-Rechnung GoBD-konform. Bei ZUGFeRD müssen Sie sowohl das PDF als auch den eingebetteten XML-Datensatz archivieren. Bei XRechnung archivieren Sie den XML-Datensatz. Stellen Sie sicher, dass die Archivierung unveränderbar, vollständig und nachvollziehbar erfolgt. Dokumentieren Sie den Archivierungsprozess in Ihrer Verfahrensdokumentation.

Schritt 6: Monitoring und Reporting

Überwachen Sie kontinuierlich Status, Fehlerraten, Durchlaufzeiten und Dunkelverarbeitungsquote. Nutzen Sie Kennzahlen wie Invoice Cycle Time, Klärfallquote, Kosten pro Rechnung und Skontoquote. Richten Sie Alerts ein, damit Sie bei Backlogs oder Validierungsfehlern schnell reagieren können.

Beispiele: So sehen E-Rechnungen in der Praxis aus

In diesem Abschnitt zeigen wir Ihnen konkrete Beispiele, wie XRechnung und ZUGFeRD in der Praxis aussehen. Sie erfahren, welche Informationen in den strukturierten Daten enthalten sind und wie Sie erkennen, ob eine Rechnung den Anforderungen entspricht.

Beispiel 1: XRechnung – XML-Ausschnitt

Eine XRechnung ist ein reiner XML-Datensatz. Hier ein vereinfachter Ausschnitt, der die wichtigsten Elemente zeigt:

Dokumentkopf: Die Rechnung beginnt mit einer eindeutigen ID und einem Datum. Diese Informationen identifizieren das Dokument eindeutig.

Parteien: Angaben zu Rechnungsaussteller (Seller) und Rechnungsempfänger (Buyer) mit Name, Anschrift und gegebenenfalls USt-ID.

Positionen: Jede Rechnungsposition enthält Beschreibung, Menge, Preis und Steuersatz. Die Summen werden automatisch berechnet und validiert.

Summen und Steuern: Nettobetrag, Steuerbetrag und Bruttobetrag werden strukturiert ausgewiesen. Die Summenlogik wird fachlich geprüft.

Zahlungsbedingungen: Fälligkeit, Zahlungsziel, Skonto und Bankverbindung werden im XML angegeben.

Das XML ist für das menschliche Auge schwer zu entziffern, aber Maschinen können es problemlos auslesen, da alle Informationen ihren vorgeschriebenen Platz haben.

Beispiel 2: ZUGFeRD – PDF mit eingebettetem XML

ZUGFeRD kombiniert ein PDF/A-3-Dokument mit einem eingebetteten XML-Datensatz. Wenn Sie eine ZUGFeRD-Rechnung öffnen, sehen Sie eine normale PDF-Rechnung mit allen gewohnten visuellen Informationen. Im Anhang des PDFs ist jedoch ein XML-Datensatz eingebettet, der dieselben Informationen maschinenlesbar enthält.

Sie erkennen ein ZUGFeRD-Dokument daran, dass die Dateigröße größer ist als bei einer reinen PDF-Rechnung. Mit einem geeigneten Viewer oder einem ERP-Import können Sie prüfen, ob ein XML eingebettet ist. Viele PDF-Reader zeigen unter „Anhänge" oder „Dateien" den eingebetteten XML-Datensatz an.

Beispiel 3: Bestellbezogene Rechnung (PO-Flows)

In der Praxis sind viele Rechnungen bestellbezogen. Das bedeutet, die Rechnung referenziert eine Bestellnummer (Purchase Order, PO). Im XML-Datensatz wird die PO-Referenz in einem dedizierten Feld angegeben. Das ermöglicht ein automatisiertes Matching: Das System vergleicht die Rechnungsdaten mit der Bestellung und gibt die Rechnung bei Übereinstimmung automatisch frei. Fehlt die PO-Referenz oder stimmt sie nicht überein, entsteht ein Klärfall.

Beispiel 4: Öffentlicher Auftraggeber (Leitweg-ID)

Wenn Sie an öffentliche Auftraggeber des Bundes in Deutschland eine Rechnung senden, benötigen Sie zusätzlich zur E-Mail-Adresse eine Leitweg-Identifikationsnummer. Diese wird im XML-Datensatz angegeben. Fehlt die Leitweg-ID oder ist sie falsch, wird die Rechnung vom System des öffentlichen Auftraggebers zurückgewiesen. Die Rückweisungslogik ist strikt, weshalb eine saubere Validierung vor dem Versand unerlässlich ist.

Beispiel 5: Fehlerhaftes Beispiel und Konsequenz

Angenommen, eine Rechnung enthält eine fehlerhafte Summenlogik: Die Summe der Positionen stimmt nicht mit dem ausgewiesenen Nettobetrag überein. Bei der Validierung wird dieser Fehler erkannt. Das System gibt eine Fehlermeldung aus, die Rechnung wird zurückgewiesen (Reject). Der Aussteller muss die Rechnung korrigieren, erneut validieren und neu versenden. Ohne sauberes Fehlerhandling führt das zu Verzögerungen, Klärfällen und Zahlungsverzug.

Diese Tabelle zeigt typische Fehlerarten und ihre Auswirkungen auf den E-Rechnungsprozess:

Strukturierte Daten und Business Terms (BT) nach EN 16931

Die europäische Norm EN 16931 basiert auf standardisierten Datenfeldern, den sogenannten Business Terms (BT). Diese Felder ermöglichen Interoperabilität und Automatisierung. Sowohl XRechnung als auch ZUGFeRD transportieren fachlich ähnliche Inhalte, der Unterschied liegt in der Verpackung.

Typische Feldgruppen sind:

• Parteien: Seller, Buyer, Identifikatoren, Anschriften
• Dokumentdaten: Rechnungsnummer, Datum, Fälligkeit
• Referenzen: PO, Lieferantennummer, Vertrag, Projekt
• Positionen: Menge, Preis, Steuern pro Position
• Summen: Netto, Steuer, Brutto, Rundung
• Zahlungsdaten: Zahlungsbedingungen, IBAN, Skonto

Die Business Terms sind das Rückgrat der E-Rechnung. Sie sorgen dafür, dass Daten systemübergreifend verstanden und verarbeitet werden können. Für Entscheiderinnen und Entscheider bedeutet das: Investitionen in saubere Stammdaten und Mapping zahlen sich durch höhere Automatisierung und weniger Klärfälle aus.

Validierung und Regelwerke: Qualitätsgate statt Hoffnung

Validierung ist ein zentraler Bestandteil des E-Rechnungsprozesses. Sie umfasst zwei Ebenen:

Technische Validierung: Prüfung, ob das XML korrekt aufgebaut ist, das Schema eingehalten wird und alle erforderlichen Tags vorhanden sind.

Fachliche Validierung: Prüfung der Business Rules, Summenlogik, Pflichtfelder, Steuercodes und Referenzen. Beispielsweise muss die Summe der Positionen mit dem Nettobetrag übereinstimmen, und Steuersätze müssen plausibel sein.

Validierungsfehler müssen in einem klaren Fehlerhandling landen. Das bedeutet: Fehlerhafte Rechnungen werden in eine Queue verschoben, Verantwortliche werden benachrichtigt, der Fehler wird korrigiert und die Rechnung wird erneut validiert und versendet. Ohne dieses Qualitätsgate entstehen Rückweisungen, Verzögerungen und Frustration auf Kundenseite.

Diese Übersicht zeigt die wichtigsten Validierungsebenen und ihre Bedeutung:

Übermittlung und Empfang: Kanäle und Governance

E-Rechnungen können über verschiedene Kanäle übermittelt werden. Typische Kanäle sind E-Mail (Anhang), Portale, Schnittstellen oder Netzwerke wie Peppol. Die Wahl des Kanals hängt von den Anforderungen der Geschäftspartner, der Systemlandschaft und der gewünschten Automatisierung ab.

Governance-Grundsatz: Standardisieren Sie Ihre Eingangskanäle, sonst entstehen Schattenprozesse und Compliance-Risiken. Seit 01.01.2025 bedeutet Empfangsfähigkeit nicht nur, die Datei zu öffnen, sondern kontrolliert anzunehmen, zu validieren, in Workflows zu integrieren und GoBD-konform zu archivieren.

Für den Versand gilt: Definieren Sie den Versandweg klar (E-Mail, Netzwerk, Portal, API) und sorgen Sie für Nachweise und Audit-Trails. Nur so können Sie im Audit belegen, dass und wann die Rechnung versendet wurde.

End-to-End-Zielbild: Architektur und Betrieb

Ein belastbares E-Rechnungssystem besteht aus mehreren Bausteinen, die nahtlos ineinandergreifen müssen:

• Quelle: ERP oder Faktura (AR) bzw. Eingangskanal und Invoice-Processing (AP)
• Format- und Mapping-Schicht: Validierung, Konvertierung, Partnerprofile, Versionen
• Workflow: Prüfung, Freigabe, Kontierung (AP) bzw. Fehlerhandling und Resend (AR)
• Archiv und DMS: GoBD-konforme Aufbewahrung inkl. strukturierter Daten (XML) plus Sichtbeleg (bei ZUGFeRD/PDF)
• Reporting und Monitoring: Status, Fehlerraten, Durchlaufzeiten, Dunkelverarbeitung

Betrieb und Controls sind oft der vergessene Teil. Sie müssen Monitoring und Alerting einrichten (Validierungsfehler, Zustellfehler, Backlogs), SLAs und Supportmodelle definieren (Finance, IT, Shared Service, Provider), Berechtigungen und Rollen festlegen (Least Privilege, Vier-Augen-Prinzip wo nötig) und Release- und Change-Management etablieren (Formatversionen, Partneranforderungen, Testfenster).

Security, Datenschutz und internes Kontrollsystem

E-Rechnungen enthalten sensible Daten. Sicherheitsaspekte entlang des Flows umfassen Transportverschlüsselung und gesicherte Kanäle (je nach Übertragungsweg), Schutz vor Manipulation und Spoofing (z. B. falsche IBAN oder Supplier Fraud) sowie Malware-Risiko bei Dateieingängen (insbesondere E-Mail). Setzen Sie technische Schutzmaßnahmen ein.

Datenschutz und Vertraulichkeit: Rechnungen enthalten häufig personenbezogene Daten oder leistungsbezogene Details. Zugriffskonzepte, Protokollierung und gegebenenfalls Auftragsverarbeitungsverträge mit Providern sind zu prüfen.

IKS-Kontrollen (praxisnah): Kontrollpunkte sind Stammdatenänderungen (Bankdaten), Rechnungseingangskanäle, Freigabegrenzen und Zahlungsfreigabe. Der Audit-Trail dokumentiert, wer was wann validiert, freigegeben, gebucht oder verändert hat.

Compliance und GoBD: konkret und operativ

GoBD-Leitplanken sind Nachvollziehbarkeit und Nachprüfbarkeit (Prozess und Daten), Vollständigkeit (keine verlorenen Rechnungen), Unveränderbarkeit und Versionierung im Archiv sowie Verfahrensdokumentation als Klammer (wer, was, womit, welche Kontrollen).

Typische Audit-Risiken, die Sie vermeiden sollten:

• Medienbrüche (PDF plus manuelle Nacherfassung ohne konsistente Nachweise)
• Archivierung nur des PDFs bei ZUGFeRD (XML fehlt)
• Unklare Zuständigkeiten bei Fehlern oder Rückweisungen
• Fehlende oder ungelebte Verfahrensdokumentation

Stellen Sie sicher, dass Ihr Archivierungsprozess sowohl das PDF als auch den XML-Datensatz (bei ZUGFeRD) oder den XML-Datensatz allein (bei XRechnung) GoBD-konform archiviert. Dokumentieren Sie den gesamten Prozess in Ihrer Verfahrensdokumentation.

Business Case und ROI-Rahmen

Die Einführung von E-Rechnungen verursacht einmalige und laufende Kosten. Typische Kostenblöcke sind:

• Software, Lizenzen, Provider (Invoice Processing, Gateway, Validierung)
• Implementierung und Integration (Mapping, Schnittstellen, Tests)
• Prozessdesign und Change (Schulung, Rollen, Arbeitsanweisungen)
• Betrieb (Monitoring, Support, Updates, Partner-Onboarding)

Nutzenhebel (messbar):

• Reduktion manueller Erfassung und OCR, weniger Klärfälle
• Schnellere Durchlaufzeiten, bessere Skontoausnutzung, weniger Mahn- und Zinskosten
• Geringere Fehlerkosten (Korrekturen, Rückweisungen, Rework)
• Höhere Transparenz (Spend, Cash-Planung)

Beispielhafte Kennzahlen und Annahmen (als Rechenrahmen):

• Kosten pro Rechnung heute vs. Ziel
• Automatisierungsquote (Dunkelverarbeitung) als Haupttreiber
• Klärfallquote und Zeit pro Klärfall
• Skonto-Potenzial vs. Realisierungsquote

Für Entscheiderinnen und Entscheider: Welche drei bis fünf Parameter müssen Sie kennen, um den Business Case intern freizugeben? Diese Frage sollten Sie mit konkreten Zahlen aus Ihrer Organisation beantworten können.

Typische Fehlerbilder und Anti-Pattern

Aus der Praxis kennen wir typische Fehlerbilder, die Sie vermeiden sollten:

• PDF als E-Rechnung versenden: Führt zu Ablehnung oder Reject, manuellem Aufwand und Kundenunzufriedenheit
• Fehlende oder inkonsistente Bestellnummern: Matching scheitert, Klärfälle entstehen
• Schlechte Stammdaten: Adressen, USt-ID, Lieferantennummern falsch oder unvollständig führen zu Validierungsproblemen oder Fehlrouting
• Zu viele Kanäle ohne Governance: Kontrollverlust, Audit-Risiko
• Format erzeugt, aber kein Fehlerhandling: Backlogs, Cashflow- oder Zahlungsverzug
• ZUGFeRD: PDF archiviert, XML nicht: Nachvollziehbarkeit gefährdet, GoBD-Risiko

Vermeiden Sie diese Anti-Pattern durch klare Prozesse, saubere Stammdaten, Validierung und Fehlerhandling.

Vorlage, Muster und Beispiel: Erwartungsmanagement

In der Praxis werden oft Vorlagen, Muster und Beispiele gesucht. Hier eine Einordnung:

• Vorlage: Template im ERP oder Tool (Mapping, Stammdaten, Layout, Profile)
• Muster: Beispielrechnung zur Orientierung (Inhalte plus Feldlogik)
• Beispiel: Kurzer XML-Codeblock (kopierbar) plus Feldkommentar

Checkliste für eine prozessfähige Rechnung:

• Parteien (Seller, Buyer) vollständig und korrekt
• IDs (Rechnungsnummer, USt-ID, Lieferantennummer) vorhanden
• PO-Referenzen (falls bestellbezogen) korrekt
• Positionslogik (Menge, Preis, Steuersatz) konsistent
• Steuer (Steuersatz, Steuerbetrag) plausibel
• Summen (Netto, Steuer, Brutto) korrekt berechnet
• Zahlungsbedingungen (Fälligkeit, Skonto, Zahlungsziel) angegeben
• Zahlungsdaten (IBAN, BIC) wo erforderlich vorhanden
• Anhänge oder Referenzen (Lieferschein, Vertrag) falls nötig

Signatur: FAQ-taugliche Einordnung

Häufig wird gefragt: „Brauchen wir eine elektronische Signatur?" Die Antwort: Signatur ist getrennt vom strukturierten Format zu betrachten. Integrität und Authentizität werden in der Praxis häufig über Prozess, Übertragungsweg, Berechtigungen, Audit-Trails und Archivierung sichergestellt. Details sind abhängig vom Setup und den Anforderungen der Geschäftspartner. Eine elektronische Signatur kann zusätzlich eingesetzt werden, ist aber nicht generell vorgeschrieben.

System- und Prozesskontext: O2C und P2P

E-Rechnung ist Teil größerer Prozesse: Order-to-Cash (O2C) auf der Verkaufsseite und Purchase to Pay (P2P) auf der Einkaufsseite.

Order-to-Cash (AR)

Im O2C-Prozess geht es um Erzeugung und Versand der Rechnung, Validierung, Partneranforderungen sowie Reject und Resend. Auswirkungen: Debitorenprozess, Cashflow, Kundenkommunikation. KPIs: Invoice Cycle Time, Dunkelverarbeitungsquote, Kosten pro Rechnung.

Purchase-to-Pay (AP)

Im P2P-Prozess geht es um automatisiertes Einlesen und Validieren, 2-Way- oder 3-Way-Match, Workflow und Kontierung. Auswirkungen: Durchlaufzeiten, Skonto, Klärfallmanagement. KPIs: Invoice Cycle Time, Klärfallquote, Skontoquote, Kosten pro Rechnung.

Beide Prozesse profitieren von strukturierten E-Rechnungen durch höhere Automatisierung, geringere Fehlerraten und bessere Transparenz.

Rollen, Governance und Zusammenarbeit Finance/IT

Damit E-Rechnung skaliert, müssen Rollen, Verantwortlichkeiten und Governance klar definiert sein:

• Finance: Fachliche Regeln, Compliance und GoBD, Prozess und Kontrollen
• IT: Integration, Betrieb, Monitoring, Security
• Shared Services/Provider: Execution und Operations (wo zutreffend)

Partner-Onboarding-Prozess umfasst Format- und Profilabstimmung, Testfälle, Cutover und laufende Pflege. Standards für Ausnahmefälle regeln Rückweisungen und Fehler, Korrekturrechnungen, Stammdatenänderungen und Eskalationen.

Häufige Fragen (FAQ)

Ist eine PDF-Rechnung eine E-Rechnung?

Nein, eine PDF-Rechnung ohne strukturierten XML-Datensatz ist keine E-Rechnung im Sinne der gesetzlichen Vorgaben. Sie erfüllt die Anforderungen der EN 16931 nicht und kann nicht automatisiert verarbeitet werden.

Was ist der Unterschied zwischen XRechnung und ZUGFeRD?

XRechnung ist ein rein maschinenlesbares XML-Format. ZUGFeRD ist ein hybrides Format, das ein PDF/A-3-Dokument mit eingebettetem XML kombiniert. XRechnung wird häufig im Public Sector verwendet, ZUGFeRD im B2B-Kontext, wenn visuelle Prüfung wichtig ist.

Woran erkenne ich, ob ein ZUGFeRD-PDF ein eingebettetes XML enthält?

Ein ZUGFeRD-Dokument ist größer als eine reine PDF-Rechnung. Viele PDF-Reader zeigen unter „Anhänge" oder „Dateien" den eingebetteten XML-Datensatz an. Sie können auch ein geeignetes Tool oder einen ERP-Import nutzen, um zu prüfen, ob XML eingebettet ist.

Welche Angaben sind Pflicht und welche Felder erhöhen die Automatisierung?

Pflichtangaben nach UStG sind Name und Anschrift von Aussteller und Empfänger, Leistungsbeschreibung, Entgelt, Steuersatz, Steuerbetrag, Bruttobetrag, Rechnungsdatum und Rechnungsnummer. Zusätzlich erhöhen Bestellnummer, Lieferantennummer, Fälligkeit und Zahlungsbedingungen die Automatisierung spürbar.

Was bedeutet EN 16931 und Business Terms (BT) in der Praxis?

EN 16931 ist die europäische Norm für elektronische Rechnungen. Business Terms (BT) sind standardisierte Datenfelder, die Interoperabilität und Automatisierung ermöglichen. Sie definieren, wo welche Information im XML steht, sodass Systeme die Daten systemübergreifend verstehen können.

Wie funktionieren Validierung und Rückweisung?

Validierung prüft technisch (XML-Struktur) und fachlich (Summenlogik, Pflichtfelder, Referenzen). Bei Fehlern wird die Rechnung zurückgewiesen (Reject). Der Aussteller muss die Rechnung korrigieren, erneut validieren und neu versenden. Ein klares Fehlerhandling ist entscheidend.

Was müssen Unternehmen seit 01.01.2025 mindestens können?

Seit 01.01.2025 müssen Unternehmen E-Rechnungen empfangen können. Das bedeutet: kontrolliert annehmen, validieren, in Workflows integrieren und GoBD-konform archivieren. Für die Ausstellung gelten Übergangsregelungen. Unternehmen sollten 2026 bereits in der Umsetzung sein.

Brauche ich eine elektronische Signatur?

Signatur ist getrennt vom strukturierten Format zu betrachten. Integrität und Authentizität werden häufig über Prozess, Übertragungsweg, Berechtigungen, Audit-Trails und Archivierung sichergestellt. Eine Signatur kann zusätzlich eingesetzt werden, ist aber nicht generell vorgeschrieben. Details hängen vom Setup ab.

Was muss ich archivieren und warum?

Sie müssen den strukturierten Datensatz (XML) archivieren. Bei ZUGFeRD auch das PDF. Zusätzlich sollten Sie Protokolle (Versand, Empfang, Validierung) archivieren. Die Archivierung muss GoBD-konform erfolgen: unveränderbar, vollständig, nachvollziehbar. Das ist die Grundlage für Audit und Compliance.

Die drei Kernentscheidungen für Ihre Umsetzung

Wenn Sie E-Rechnung in Ihrer Organisation umsetzen, sollten Sie drei zentrale Entscheidungen treffen:

1. Format- und Profilstrategie: Legen Sie fest, ob Sie XRechnung, ZUGFeRD oder beide Formate unterstützen. Orientieren Sie sich an Partner- und Prozessanforderungen. Definieren Sie Profile und Mapping klar.

2. Zielarchitektur inklusive Betrieb: Bauen Sie eine End-to-End-Architektur auf, die Quelle, Mapping, Workflow, Archiv und Monitoring umfasst. Definieren Sie SLAs, Monitoring, Support, Berechtigungen und Change-Management.

3. Governance, IKS und Archivierung: Stellen Sie sicher, dass Ihre Prozesse GoBD-tauglich und auditfähig sind. Definieren Sie Kontrollen, Rollen, Fehlerhandling und Verfahrensdokumentation.

Konkreter nächster Schritt

Führen Sie einen Quick-Check durch:

• Welche Eingangskanäle nutzen Sie aktuell?
• Ist Validierung (technisch und fachlich) vorhanden?
• Sind Workflows für Prüfung, Freigabe und Kontierung definiert?
• Archivieren Sie XML und (bei ZUGFeRD) PDF GoBD-konform?
• Ist Fehlerhandling definiert (Queue, Verantwortliche, SLAs)?
• Sind Rollen und Berechtigungen klar?

Priorisieren Sie: Starten Sie mit Top-Partnern, PO-Use-Cases, Pilot und Rollout-Plan. Rechnen Sie den Business Case mit drei bis fünf Annahmen: Volumen, Automatisierung, Klärfälle, Skonto, Betriebskosten. So schaffen Sie eine belastbare Entscheidungsgrundlage für die Umsetzung.