Auf dieser Seite
Die kurze Antwort
PEPPOL-EN16931-R020 schlägt fehl, wenn cac:AccountingSupplierParty/cac:Party kein Kindelement cbc:EndpointID hat. Fügen Sie das Element als erstes Kindelement des cac:Party des Verkäufers ein, mit der elektronischen Adresse des Verkäufers und einem Attribut schemeID, das das Schema der Adresse benennt.
EN 16931 behandelt die elektronische Adresse des Verkäufers als optional, daher besteht der Prüfschritt EN 16931 auch ohne sie. Die Anforderung stammt von Peppol; deshalb erscheint der Befund nur im Peppol-Prüfschritt.
Was die Regel prüft
Die Regel läuft einmal für das cac:Party des Verkäufers und stellt eine einzige Frage: Gibt es ein Kindelement cbc:EndpointID? Sie liest weder den Inhalt noch das Attribut schemeID.
Da sie nur das Vorhandensein prüft, erfüllt ein vorhandenes, aber leeres cbc:EndpointID sie. Das leere Element meldet stattdessen PEPPOL-EN16931-R008, und wenn es ein Schema trägt, dessen Wertformat Peppol prüft, zusätzlich die zugehörige Formatregel: Ein leeres Element mit schemeID="0088" meldet PEPPOL-EN16931-R008 und PEPPOL-COMMON-R040, nicht diese Regel.
Ein cbc:EndpointID an anderer Stelle im Dokument zählt nicht. Die Adresse des Käufers prüft gesondert PEPPOL-EN16931-R010, und ein Dokument, dem beide fehlen, meldet beide Regeln.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BT-34 | Elektronische Adresse des Verkäufers | cac:AccountingSupplierParty/cac:Party/cbc:EndpointID |
Wie es in einer Integration dazu kommt
Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:
- Das Mapping wurde für EN 16931 geschrieben, wo die elektronische Adresse des Verkäufers optional ist, und nie für Peppol erweitert.
- Der Endpunkt des Verkäufers liegt in der Konfiguration des Access Points oder des Mandanten statt in den Rechnungsdaten, sodass der Dokumentgenerator nichts auszugeben hat.
- Der Generator lässt Elemente weg, deren Quellwert null ist, und im Datensatz des Verkäufers ist keine elektronische Adresse eingetragen.
- Die Adresse wurde in
cac:PartyIdentification/cbc:IDoder incac:Contact/cbc:ElectronicMailgeschrieben, in der Annahme, dass beides als elektronische Adresse dient.
So korrigieren Sie das Dokument
- Ermitteln Sie die elektronische Adresse des Verkäufers und das Schema, unter dem sie vergeben ist, zum Beispiel eine GLN unter
0088. Verwenden Sie die Kennung, die der Verkäufer tatsächlich besitzt; entleihen Sie keine von einer anderen Partei und erfinden Sie keine, nur um die Regel zu erfüllen. - Geben Sie
cbc:EndpointIDals erstes Kindelement voncac:AccountingSupplierParty/cac:Partyaus, vorcac:PartyIdentification,cac:PartyNameundcac:PostalAddress. UBL legt die Reihenfolge der Kindelemente voncac:Partyfest: Steht das Element nachcac:PostalAddress, weist der XSD-Prüfschritt das Dokument ab, und die Prüfschritte EN 16931 und Peppol werden übersprungen. - Setzen Sie das Attribut
schemeIDauf den Schemacode.BR-62verlangt das Attribut, undBR-CL-25prüft den Code. - Machen Sie den Endpunkt des Verkäufers dort zum Pflichtfeld, wo der Verkäufer eingerichtet wird, damit die Lücke auffällt, bevor ein Dokument erzeugt wird.
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 Verkäufers beginnt mit seiner Postanschrift und enthält kein EndpointID
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PostalAddress>
<cbc:StreetName>1 Example Street</cbc:StreetName>
<!-- rest of the address omitted from this fragment -->
</cac:PostalAddress>
<!-- tax scheme and legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>Ausschnitt der korrigierten Rechnung: EndpointID ist das erste Kindelement des Party-Elements des Verkäufers
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<cac:PostalAddress>
<cbc:StreetName>1 Example Street</cbc:StreetName>
<!-- rest of the address omitted from this fragment -->
</cac:PostalAddress>
<!-- tax scheme and legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>Das korrigierte Dokument fügt eine Zeile hinzu, das cbc:EndpointID mit schemeID="0088" am Anfang des cac:Party des Verkäufers. Sonst unterscheidet sich nichts. Das fehlerhafte Dokument meldet nur PEPPOL-EN16931-R020; sein Prüfschritt EN 16931 besteht, weil BR-62 nichts zu prüfen hat, wenn das Element fehlt. Die Kennung im Beispiel ist ein Beispielwert, kein registrierter Teilnehmer.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet PEPPOL-EN16931-R020. Das korrigierte Dokument besteht jeden Prüfschritt ohne Befunde.Fehlerhaftes XML herunterladenKorrigiertes XML herunterladen
Aufgezeichnet mit phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, der Engine hinter dem kostenlosen Validator, mit synthetischen Daten. Ein aufgezeichnetes Ergebnis ist ein Regressionsnachweis für diese Dokumente, keine Zertifizierung.
Wo die Regel gilt
- Gilt gleichermaßen für UBL
InvoiceundCreditNote. Eine Gutschrift ohne dascbc:EndpointIDdes Verkäufers meldet denselben einzelnen Befund. - Dies ist eine Regel von Peppol BIS Billing 3.0. Sie meldet im Peppol-Prüfschritt und hat kein Gegenstück in EN 16931.
- Wer diese Regel und die nachfolgenden Schemaregeln besteht, hat eine wohlgeformte Adresse. Der Validator schlägt den Teilnehmer nicht nach und sagt daher nichts darüber, ob der Verkäufer im Peppol-Netzwerk registriert oder erreichbar ist.
Verwandte Regeln
- PEPPOL-EN16931-R010 ist dieselbe Vorhandenseinsprüfung für die elektronische Adresse des Käufers
- BR-62 verlangt das Attribut schemeID, sobald das EndpointID des Verkäufers vorhanden ist
- BR-CL-25 prüft, ob der Schemacode in der EAS-Codeliste steht
- PEPPOL-EN16931-R008 meldet ein EndpointID, das vorhanden, aber leer ist
- 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-R020 (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.

