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.
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.
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.
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.
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.
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 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 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.
Die Wahl des Formats hängt von mehreren Faktoren ab:
Bevor Sie E-Rechnungen erstellen oder empfangen, sollten Sie folgende Voraussetzungen prüfen:
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.
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.
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.
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.
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.
Ü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?
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.
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.
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.
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.
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.
Ü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.
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.
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.
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.
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.
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.
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:
| Fehlerart | Ursache | Konsequenz |
|---|---|---|
| Fehlerhafte Summenlogik | Summe der Positionen stimmt nicht mit Nettobetrag überein | Validierung schlägt fehl, Rechnung wird zurückgewiesen |
| Fehlende PO-Referenz | Bestellnummer nicht angegeben oder falsch | Automatisches Matching scheitert, manueller Klärfall |
| Ungültiger Steuersatz | Falscher oder veralteter Steuersatz verwendet | Fachliche Validierung schlägt fehl, Korrektur erforderlich |
| Fehlende Leitweg-ID | Pflichtfeld für öffentliche Auftraggeber nicht ausgefüllt | Rechnung wird sofort vom System zurückgewiesen |
| Fehlerhafte XML-Struktur | XML-Schema nicht eingehalten oder Tags falsch | Technische Validierung schlägt fehl, Verarbeitung unmöglich |
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:
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 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:
| Validierungsebene | Prüfkriterium | Konsequenz bei Fehler |
|---|---|---|
| Technische Validierung | XML-Struktur korrekt, Schema eingehalten | Rechnung kann nicht verarbeitet werden, Rückweisung |
| Fachliche Validierung | Summenlogik, Pflichtfelder, Steuercodes, Referenzen | Klärfall, manuelle Prüfung, Korrektur nötig |
| Prozessvalidierung | PO-Referenz vorhanden und korrekt, Matching möglich | Keine Dunkelverarbeitung, Workflow startet |
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.
Ein belastbares E-Rechnungssystem besteht aus mehreren Bausteinen, die nahtlos ineinandergreifen müssen:
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).
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.
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:
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.
Die Einführung von E-Rechnungen verursacht einmalige und laufende Kosten. Typische Kostenblöcke sind:
Nutzenhebel (messbar):
Beispielhafte Kennzahlen und Annahmen (als Rechenrahmen):
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.
Aus der Praxis kennen wir typische Fehlerbilder, die Sie vermeiden sollten:
Vermeiden Sie diese Anti-Pattern durch klare Prozesse, saubere Stammdaten, Validierung und Fehlerhandling.
In der Praxis werden oft Vorlagen, Muster und Beispiele gesucht. Hier eine Einordnung:
Checkliste für eine prozessfähige Rechnung:
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.
E-Rechnung ist Teil größerer Prozesse: Order-to-Cash (O2C) auf der Verkaufsseite und Purchase to Pay (P2P) auf der Einkaufsseite.
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.
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.
Damit E-Rechnung skaliert, müssen Rollen, Verantwortlichkeiten und Governance klar definiert sein:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Führen Sie einen Quick-Check durch:
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.