PEPPOL-EN16931-R010: Die elektronische Adresse des Käufers ergänzen

Die kurze Antwort

PEPPOL-EN16931-R010 schlägt fehl, wenn das Party-Element des Käufers, cac:AccountingCustomerParty/cac:Party, kein cbc:EndpointID enthält. Tragen Sie dort die elektronische Adresse des Käufers ein, als erstes Kindelement von cac:Party, mit einem Attribut schemeID für das Schema, unter dem sie vergeben ist.

Der Wert muss vom Käufer kommen. Es ist seine Adresse; sie gehört daher in die Kundenstammdaten neben seinen Namen und seine Umsatzsteuer-Identifikationsnummer, nicht in einen Standardwert, den der Absender einsetzt.

Was die Regel prüft

Geprüft wird, ob das cac:Party des Käufers ein Kindelement cbc:EndpointID hat. Sonst wird am Element nichts untersucht: weder sein Text noch sein schemeID.

Ein leeres cbc:EndpointID erfüllt diese Regel deshalb und scheitert an anderer Stelle. Mit schemeID="0088" und ohne Inhalt meldet das Dokument PEPPOL-EN16931-R008 für das leere Element und PEPPOL-COMMON-R040 für das GLN-Format, während PEPPOL-EN16931-R010 schweigt.

Die Seite des Verkäufers prüft eine eigene Regel, PEPPOL-EN16931-R020. Fehlen beide Adressen, erscheinen beide Befunde; die eine Adresse erfüllt nie die Regel für die andere.

Wie es in einer Integration dazu kommt

Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:

• Die Kundendatensätze wurden angelegt, bevor die Zustellung über Peppol eingeführt wurde, und haben kein Feld oder keinen Wert für eine elektronische Adresse.
• Der Access Point kennt die Adresse und nutzt sie für das Routing, sie wird aber nie an die Komponente übergeben, die das XML erzeugt.
• Der Käufer wird nur über cac:PartyIdentification/cbc:ID oder eine Handelsregisternummer identifiziert, und das Mapping ging davon aus, dass das genügt.
• Eine Vorlage, die auch eine reine EN 16931-Ausgabe erzeugt, lässt das Element weg, weil das Kernmodell es nicht verlangt.

So korrigieren Sie das Dokument

1. Beschaffen Sie die elektronische Adresse des Käufers und ihr Schema beim Käufer selbst oder aus dem Onboarding-Schritt, in dem festgehalten wird, wie er Dokumente empfängt.
2. Speichern Sie beide Teile, Schemacode und Kennung, im Kundendatensatz. Ein Freitextfeld, das beide vermischt, etwa 0088:7300010000001, muss aufgeteilt werden, bevor es gemappt werden kann.
3. Geben Sie cbc:EndpointID als erstes Kindelement von cac:AccountingCustomerParty/cac:Party aus, mit der Kennung als Inhalt und dem Schemacode in schemeID. Steht das Element nach cac:PostalAddress, verletzt es die UBL-Reihenfolge der Kindelemente, und der XSD-Prüfschritt weist das Dokument ab, bevor diese Regel läuft.
4. Erzeugen Sie das Dokument nicht, wenn der Käufer keine elektronische Adresse hat, statt ein leeres Element oder einen Platzhalter auszugeben.

Korrigierte Rechnung prüfen

Vorher und nachher

Dies sind Ausschnitte, keine vollständigen Dokumente. Die vollständigen synthetischen Dokumente, aus denen sie stammen, sind unten verlinkt.

Ausschnitt der fehlerhaften Rechnung: Das Party-Element des Käufers enthält kein EndpointID

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <!-- rest of the address omitted from this fragment -->
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Ausschnitt der korrigierten Rechnung: Das Party-Element des Käufers beginnt mit seinem EndpointID

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <!-- rest of the address omitted from this fragment -->
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Der einzige Unterschied ist die Zeile cbc:EndpointID im cac:Party des Käufers, die in der korrigierten Datei steht und in der fehlerhaften fehlt. Das fehlerhafte Dokument meldet nur PEPPOL-EN16931-R010, und zwar nur im Peppol-Prüfschritt: Die EN 16931-Regel zur Adresse des Käufers, BR-63, prüft das schemeID eines vorhandenen Elements und hat hier nichts zu prüfen. Der Wert im Beispiel ist eine Beispiel-GLN.

Wo die Regel gilt

• Gilt für UBL Invoice und CreditNote. Das Party-Element des Käufers hat in beiden denselben Pfad, und eine Gutschrift ohne das Element meldet denselben einzelnen Befund.
• Die Anforderung ist Peppol-spezifisch. EN 16931 lässt die elektronische Adresse des Käufers optional, daher besteht der Prüfschritt EN 16931.
• Eine wohlgeformte Adresse, die diese Regel, BR-63 und BR-CL-25 besteht, ist trotzdem nur eine Zeichenkette in einem Dokument. Der Validator fragt weder das Peppol-Verzeichnis noch einen SMP ab und kann Ihnen daher nicht sagen, ob der Käufer registriert ist oder das Dokument empfangen kann.

Verwandte Regeln

• PEPPOL-EN16931-R020 verlangt die elektronische Adresse des Verkäufers auf dieselbe Weise
• BR-63 verlangt ein Attribut schemeID am EndpointID des Käufers
• BR-CL-25 prüft den Schemacode gegen die EAS-Codeliste
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): How Peppol invoice validation actually works

Umfang und Quelle

Geschrieben für Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, angewendet auf Invoice- und CreditNote-Dokumente in UBL 2.1. Andere Profile, Syntaxen und Releases können diese Kennung anders definieren. Version des Hinweiskatalogs 2026-09-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-20.

Die offizielle Definition von PEPPOL-EN16931-R010 (auf Englisch) enthält den normativen Wortlaut und den Test. Diese Seite ist unsere Erklärung dazu, keine Kopie.

Die Erklärung ändert das Urteil der Engine nicht. Dass Sie diesen Befund beheben, heißt nicht, dass das Dokument jeden Prüfschritt besteht. Die Validierung bescheinigt keine rechtliche oder steuerliche Konformität und überträgt kein Dokument über Peppol.