E-Rechnung · 7 Min. Lesezeit
EN 16931 verstehen: Standards der E-Rechnung
Eine elektronische Rechnung ist kein PDF im E-Mail-Anhang. Im europäischen Rahmen ist eine E-Rechnung eine strukturierte Datennachricht, in der jeder kaufmännische Sachverhalt — wer verkauft, wer kauft, was geliefert wurde, zu welchem Datum, unter welcher Steuerbehandlung, zahlbar bis wann — in einem benannten Feld steht, das ein Empfangssystem ohne menschliches Lesen verarbeiten kann. Genau darum geht es bei EN 16931, und genau deshalb kann ein sehr schön gestaltetes PDF von einem öffentlichen Auftraggeber zurückgewiesen werden.
Dieser Leitfaden betrachtet den Standard aus Sicht von Freiberuflern und kleinen Unternehmen, die ihn einhalten müssen — nicht aus Sicht eines ERP-Herstellers. Er behandelt das semantische Modell, die nationalen Formate darüber, die häufigsten Fehlerquellen und eine kurze Prüfroutine vor jedem Versand.
Was EN 16931 tatsächlich normiert
EN 16931-1 definiert ein semantisches Datenmodell: eine Liste von Geschäftsbegriffen, jeder mit einer Kennung wie BT-1 für die Rechnungsnummer oder BT-112 für den Bruttobetrag, dazu Kardinalitäten und Geschäftsregeln. Ein Dateiformat schreibt die Norm nicht vor. Dieselbe semantische Rechnung kann als UBL 2.1 oder als UN/CEFACT Cross Industry Invoice (CII) serialisiert werden und ist in beiden Fällen konform.
Diese Trennung ist der wichtigste Punkt. Wenn die Daten korrekt modelliert sind — richtige Parteien, richtige Steuerkategorien, richtige Belegreferenzen — ist die Umwandlung in die vom Partner gewünschte Syntax ein mechanischer Schritt. Ist das Modell falsch, hilft keine Formatkonvertierung, weil das Empfangssystem an den Geschäftsregeln scheitert, nicht am Schema.
Die Prüfung läuft in zwei Schichten. Die Schemavalidierung stellt fest, ob die XML-Struktur stimmt. Die Geschäftsregelvalidierung prüft die kaufmännische Logik: dass Positionssummen den Gesamtbetrag ergeben, dass für jede verwendete Steuerkategorie eine Aufschlüsselung existiert, dass jede steuerfreie Position einen Befreiungsgrund trägt, dass das Fälligkeitsdatum nicht vor dem Rechnungsdatum liegt. Die meisten Ablehnungen sind Regelverstöße, keine Schemafehler.
Die nationalen Formate in der Praxis
XRechnung ist die deutsche CIUS — eine Core Invoice Usage Specification — die EN 16931 für die öffentliche Verwaltung verengt. Sie macht bestimmte optionale Felder verpflichtend, allen voran die Leitweg-ID als Käuferreferenz (BT-10), die die Rechnung an die richtige Stelle routet. Eine technisch gültige EN-16931-Rechnung ohne Leitweg-ID wird von einer deutschen Behörde in der Regel abgewiesen.
ZUGFeRD und Factur-X sind der deutsche und der französische Name desselben hybriden Ansatzes: ein PDF/A-3-Dokument mit eingebettetem CII-XML. Menschen öffnen das PDF und sehen eine normale Rechnung, Maschinen lesen das XML und buchen automatisch. Für den B2B-Austausch ist das der pragmatische Standardweg, weil der Empfänger nichts umstellen muss.
Peppol BIS Billing 3.0 ist weniger ein konkurrierendes Format als eine Transport- und Profilebene: EN-16931-konformes UBL plus Adressierungsschema und ein Netz von Access Points. Wer nach Ihrer Peppol-ID fragt, fragt nach dem Zustellweg, nicht nach dem XML-Dialekt.
- XRechnung — öffentliche Auftraggeber, Leitweg-ID (BT-10) verpflichtend
- ZUGFeRD / Factur-X — hybrides PDF/A-3 mit eingebettetem CII-XML
- Peppol BIS 3.0 — UBL-Profil plus Netzadressierung und Zustellung
Felder, an denen Rechnungen scheitern
Wenige Geschäftsbegriffe verursachen die Mehrzahl der Fehler. Die Käuferreferenz (BT-10) ist in mehreren CIUS-Profilen Pflicht und bleibt oft leer, weil Papierrechnungen sie nie brauchten. Umsatzsteuer-Identifikationsnummern von Verkäufer und Käufer (BT-31, BT-48) müssen bei innergemeinschaftlicher Behandlung vorhanden und formal gültig sein; beim Reverse-Charge kommt der korrekte Befreiungsgrund hinzu.
Steuerkategorien sind die zweite Falle. Jede Position trägt eine Kategorie — S für Regelsatz, AA für ermäßigt, Z für Nullsatz, E für steuerbefreit, AE für Reverse-Charge, G für Drittlandsexport, K für innergemeinschaftliche Lieferung — und die Aufschlüsselung auf Dokumentebene muss je Kombination aus Kategorie und Satz genau einen Eintrag enthalten.
Rundung ist der stille Fehler. Positionsnetto, Summe der Positionen, Nachlässe und Zuschläge, Bemessungsgrundlage je Kategorie, Steuerbetrag je Kategorie und Zahlbetrag müssen sich auf den Cent decken. Wer die Steuer einmal je Position und einmal auf die Summe rundet, produziert eine Ein-Cent-Differenz, die die Validierung mit einer schwer lesbaren Meldung ablehnt.
Prüfroutine vor jedem Versand
Machen Sie daraus eine Gewohnheit. Erstens die Pflichtangaben bestätigen: Rechnungsnummer, Ausstellungsdatum, Währung, Name und Anschrift des Verkäufers, USt-IdNr., Name und Anschrift des Käufers, Käuferreferenz falls verlangt. Zweitens prüfen, ob jede Position Menge, Einheit, Nettoeinzelpreis und Steuerkategorie hat und die Summen aufgehen. Drittens die Steueraufschlüsselung gegen die verwendeten Kategorien abgleichen, inklusive Befreiungstext.
Viertens die Datei durch einen Validator schicken, der die Geschäftsregeln prüft und nicht nur das XSD. Der Toolula E-Invoice Reader macht das lokal im Browser: Er liest UBL oder CII, ordnet die Felder ihren BT-Kennungen zu und meldet, welche Regel warum verletzt ist — ohne dass das Dokument das Gerät verlässt. Fünftens beide Artefakte archivieren, PDF und XML, für die nationale Aufbewahrungsfrist, in Deutschland grundsätzlich acht Jahre.
Wer heute ein hybrides Format nutzt und die Identifikatoren sauber hält, erlebt kommende Meldepflichten als Konfigurationsänderung statt als Migrationsprojekt.
Häufig gestellte Fragen
Ist ein PDF per E-Mail eine elektronische Rechnung?
Nach europäischer Definition nicht. Eine E-Rechnung muss in einem strukturierten Format ausgestellt, übermittelt und empfangen werden, das die automatische Verarbeitung erlaubt. Ein reines PDF ist ein Abbild, keine strukturierten Daten — deshalb betten hybride Formate wie ZUGFeRD maschinenlesbares XML in das PDF ein.
Brauche ich XRechnung oder ZUGFeRD?
Das hängt vom Empfänger ab. Öffentliche Auftraggeber in Deutschland verlangen in der Regel XRechnung mit Leitweg-ID. Im privatwirtschaftlichen B2B genügt meist ein hybrides ZUGFeRD- oder Factur-X-PDF, das auch für Empfänger ohne XML-Verarbeitung lesbar bleibt.
Geht eine konforme E-Rechnung ohne Buchhaltungssoftware?
Ja. Die Norm regelt die Daten, nicht das Werkzeug. Solange die Ausgabe die geforderten Geschäftsbegriffe enthält und die EN-16931-Regeln besteht, ist ein browserbasierter Generator genauso gültig.
Wie lange muss ich die XML-Datei aufbewahren?
Die Frist ist national geregelt; in Deutschland gelten für Rechnungen grundsätzlich acht Jahre. Bewahren Sie die strukturierte Datei auf, nicht nur die PDF-Darstellung — im strukturierten Austausch ist das XML das rechtlich maßgebliche Original.