Zum Hauptinhalt springen

Referenz

Markdown-Export

PEPPOL-EN16931-R008 Das Dokument darf keine leeren Elemente enthalten

PEPPOL-EN16931-R008 meldet jedes XML-Element, das weder Text noch Unterelemente enthält, zum Beispiel <cbc:Note/> oder <cbc:Telephone> </cbc:Telephone>. Attribute zählen nicht als Inhalt, daher ist auch <cbc:EndpointID schemeID="EM"/> leer. Die KoSIT-Konfiguration für XRechnung 3.0.2 prüft die Regel für UBL und CII als fatalen Fehler. Ausgenommen sind nur ein leeres cbc:ID in cac:OrderReference (UBL) und ram:ApplicableHeaderTradeDelivery, das das CII-Schema verlangt.

Problembeschreibung

FEHLER

Regel von Peppol BIS Billing 3.0 (OpenPeppol)

Interaktive Prüfkette

Klicken Sie auf eine Stufe, um zu sehen, was sie prüft, oder geben Sie eine Regel-ID ein, um die meldende Stufe zu finden.

Beispiele:

PEPPOL-EN16931-R008 Regel von Peppol BIS Billing

Gemeldet in Stufe 3: Nationale Regeln (CIUS).

Stufe Fehler: Der Bericht empfiehlt, die Rechnung abzulehnen.

Stufe 3 · Was geprüft wird

  • Die Spezifikationskennung in BT-24 wählt das Regelwerk, etwa XRechnung 3.0 oder Peppol BIS Billing 3.0.
  • XRechnung ergänzt die deutschen BR-DE-Regeln: Käuferreferenz (BT-10), Verkäuferkontakt, Zahlungsanweisungen.
  • Peppol ergänzt PEPPOL-EN16931- und Länderregeln. Auch XRechnung wendet einige PEPPOL-EN16931-Regeln an.

Beispielcodes

Typische Korrektur

Pflegen Sie die vom Regelwerk verlangten Felder in den Stammdaten, etwa die Leitweg-ID in BT-10 oder den Verkäuferkontakt.

Ein Validator prüft eine E-Rechnung in Stufen. Zuerst muss die Datei wohlgeformtes XML sein und zum UBL- oder CII-Schema (XSD) passen. Dann laufen die Geschäftsregeln der EN 16931: BR-Kernregeln, BR-CO-Berechnungen, BR-CL-Codelisten, BR-DEC-Nachkommastellen und Regeln je Umsatzsteuerkategorie wie BR-S. Danach folgen die nationalen oder Netzwerk-Regeln, die BT-24 auswählt: BR-DE für XRechnung, PEPPOL-EN16931 für Peppol BIS Billing. Der Bericht nennt jede verletzte Regel: Ein Fehler bedeutet Ablehnung, nur Warnungen bedeuten weiterhin Annahme. PEPPOL-EN16931-R008: Regel von Peppol BIS Billing, gemeldet in der Stufe „Nationale Regeln (CIUS)“. Regelwerke: KoSIT-Validator 1.6.3 mit der XRechnung-Konfiguration vom 31. Aug. 2026 (EN-16931-Artefakte 1.3.16), Peppol BIS Billing 3.0.21.

Kontext und Bedeutung

Leere Elemente stammen meist aus Exportvorlagen, die jedes Feld schreiben, auch wenn die Quelle keinen Wert hat: eine leere Bemerkung, ein Kontaktfeld, eine Adresszeile oder ein Parteiblock. Ein Platzhalter verdeckt den Strukturfehler, schreibt aber falsche Daten in die Rechnung.

Lösung

Entfernen Sie das leere Element. Enthält die übergeordnete Gruppe danach keine Daten mehr, entfernen Sie auch die Gruppe. Ist das Feld Pflicht, tragen Sie den echten Wert aus dem Quelldokument ein. Füllen Sie das Element nicht mit Platzhaltern wie „-“ oder „n/a“. Die Position im Validator-Bericht (ein XPath) nennt das Element.

Schnellzugriff

XML validierenRechnung konvertieren

Gültige Beispiele

  • <cbc:Telephone>+49 30 1234567</cbc:Telephone>
  • Kein cbc:Note-Element, wenn die Rechnung keine Bemerkung hat

Ungültige Beispiele

  • <cbc:Note/>
  • <cbc:Telephone></cbc:Telephone>
  • <cbc:EndpointID schemeID="EM"/>

Code-Beispiele

Gültiges XML
<cac:Contact>
  <cbc:Name>Accounts receivable</cbc:Name>
  <cbc:Telephone>+49 30 1234567</cbc:Telephone>
  <cbc:ElectronicMail>billing@example.com</cbc:ElectronicMail>
</cac:Contact>
Ungültiges XML
<cac:Contact>
  <cbc:Name>Accounts receivable</cbc:Name>
  <cbc:Telephone/>
  <cbc:ElectronicMail>billing@example.com</cbc:ElectronicMail>
</cac:Contact>

Betroffene Felder

BT-22 Bemerkung zur Rechnung
BT-34 Elektronische Adresse des Verkäufers
BT-42 Telefonnummer des Verkäuferkontakts

Validierungstools

Offizieller KoSIT Validator

Führen Sie den offiziellen KoSIT-Validator mit der XRechnung-Konfiguration aus, um EN-16931- und XRechnung-Regeln zu prüfen.

PDF zu XRechnung konvertieren

Validierungsfehler beim Konvertieren erkennen, prüfen und gezielt beheben.