BR-17: Den Zahlungsempfänger benennen oder einen Zahlungsempfänger entfernen, der der Verkäufer ist

Die kurze Antwort

BR-17 schlägt bei einer cac:PayeeParty fehl, die kein cac:PartyName/cbc:Name hat oder deren Name oder Kennung mit der des Verkäufers übereinstimmt. Soll jemand anderes als der Verkäufer bezahlt werden, etwa eine Factoring-Gesellschaft, geben Sie diesem Zahlungsempfänger einen eigenen Namen in cac:PayeeParty/cac:PartyName/cbc:Name. Soll der Verkäufer bezahlt werden, entfernen Sie cac:PayeeParty vollständig.

Ein Zahlungsempfänger ohne Namen bringt außerdem UBL-SR-19, UBL-SR-20 und UBL-SR-21 am selben Element mit sich, obwohl sich darin nichts wiederholt. Jede dieser Regeln verbindet eine Begrenzung auf ein Vorkommen mit einer Prüfung, dass sich der Name des Zahlungsempfängers vom rechtlichen Namen des Verkäufers unterscheidet, und ohne Namen des Zahlungsempfängers kann diese Prüfung nicht bestehen. Den Namen zu ergänzen behebt alle vier Befunde.

Was die Regel prüft

Die Regel läuft auf jeder cac:PayeeParty und ist nur erfüllt, wenn drei Bedingungen gelten: Es gibt ein cac:PartyName/cbc:Name; es entspricht keinem Handelsnamen des Verkäufers in cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name; und keine cac:PartyIdentification/cbc:ID des Zahlungsempfängers entspricht einer cac:PartyIdentification/cbc:ID des Verkäufers.

Beide Vergleiche sind exakte Zeichenkettenvergleiche. Im Versuch schlug ein Zahlungsempfänger namens Example Trading, der Handelsname des Verkäufers, allein bei BR-17 fehl, ebenso ein anders benannter Zahlungsempfänger mit der Kennung des Verkäufers 7300010000001. Ein Zahlungsempfänger namens EXAMPLE TRADING bestand, weil sich die Groß- und Kleinschreibung unterscheidet, obwohl er dasselbe Unternehmen bezeichnet.

Beim Namen zählt das Vorhandensein. Im Versuch erfüllte ein leeres cbc:Name des Zahlungsempfängers BR-17 und wurde nur von PEPPOL-EN16931-R008 gemeldet.

Den rechtlichen Namen des Verkäufers vergleichen die Begleitregeln, nicht diese Regel. Im Versuch bestand ein Zahlungsempfänger namens Example Supplier Ltd, das cbc:RegistrationName des Verkäufers, BR-17 und schlug bei UBL-SR-19, UBL-SR-20 und UBL-SR-21 fehl.

Die Kennung des Zahlungsempfängers ist optional: Im Versuch bestand ein Zahlungsempfänger, der nur den Namen Example Factoring Ltd trug, jeden Prüfschritt.

Wie es in einer Integration dazu kommt

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

• Der Export schreibt immer cac:PayeeParty, gefüllt aus dem Datensatz des Verkäufers, weil das Quellsystem den Verkäufer als Standard-Zahlungsempfänger behandelt.
• Der Zahlungsempfänger ist nur als Referenz oder Kontonummer ohne Parteinamen gespeichert, sodass der Builder cac:PartyIdentification schreiben kann, aber nicht cac:PartyName.
• Für die Rechnung ist eine Factoring- oder Abtretungsvereinbarung erfasst, und der Block des Zahlungsempfängers wird aus der Vertragsreferenz aufgebaut, ohne den Namen der Factoring-Gesellschaft nachzuschlagen.
• Der Handelsname des Verkäufers wird als Platzhalter in den Namen des Zahlungsempfängers kopiert, wenn der tatsächliche Zahlungsempfänger nicht bekannt ist.

So korrigieren Sie das Dokument

1. Klären Sie, ob die Rechnung an jemand anderen als den Verkäufer gezahlt werden soll. Die Gruppe des Zahlungsempfängers existiert nur für diesen Fall, etwa für eine Forderung, die im Factoring verkauft oder abgetreten wurde.
2. Wird der Verkäufer bezahlt, lassen Sie cac:PayeeParty in der Ausgabe weg. Das Konto für die Zahlung bleibt in cac:PaymentMeans.
3. Wird ein Dritter bezahlt, nehmen Sie seinen Namen aus der Factoring- oder Abtretungsvereinbarung und schreiben Sie ihn in cac:PayeeParty/cac:PartyName/cbc:Name, nach einer etwaigen cac:PartyIdentification.
4. Geben Sie dem Zahlungsempfänger eine eigene Kennung, falls er eine hat. Verwenden Sie dort nie die Kennung des Verkäufers, und ändern Sie nicht den Namen des Verkäufers, damit der Vergleich besteht.
5. Übermitteln Sie höchstens einen Namen des Zahlungsempfängers, eine Kennung des Zahlungsempfängers außer einer SEPA-Gläubiger-Identifikationsnummer und eine Kennung der rechtlichen Registrierung; UBL-SR-19, UBL-SR-20 und UBL-SR-21 begrenzen jede dieser Angaben auf ein Vorkommen.

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: Der Zahlungsempfänger hat eine Kennung, aber keinen Namen

<cac:PayeeParty>
  <cac:PartyIdentification>
    <cbc:ID>PAYEE-001</cbc:ID>
  </cac:PartyIdentification>
</cac:PayeeParty>

Ausschnitt der korrigierten Rechnung: Der Zahlungsempfänger ist benannt, und der Name unterscheidet sich von dem des Verkäufers

<cac:PayeeParty>
  <cac:PartyIdentification>
    <cbc:ID>PAYEE-001</cbc:ID>
  </cac:PartyIdentification>
  <cac:PartyName>
    <cbc:Name>Example Factoring Ltd</cbc:Name>
  </cac:PartyName>
</cac:PayeeParty>

Die korrigierte Rechnung hat cac:PartyName mit Example Factoring Ltd nach der Kennung des Zahlungsempfängers; die fehlerhafte hat nur die Kennung. Neben BR-17 meldet das fehlerhafte Dokument UBL-SR-19, UBL-SR-20 und UBL-SR-21, alle an cac:PayeeParty. Keine davon hat eine Wiederholung gefunden: Jede verlangt außerdem, dass sich der Name des Zahlungsempfängers vom cbc:RegistrationName des Verkäufers, Example Supplier Ltd, unterscheidet, und ein nicht vorhandener Name besteht diesen Vergleich nicht. Mit dem ergänzten Namen verschwinden alle vier Befunde. Ein zweites aufgezeichnetes Beispiel fügt einen Zahlungsempfänger namens Example Trading hinzu, den Handelsnamen des Verkäufers, und meldet nur BR-17; dort ist der Zahlungsempfänger der Verkäufer und sollte weggelassen werden.

Wo die Regel gilt

• Gutschriften tragen den Zahlungsempfänger an derselben Stelle. Im Versuch meldete eine Gutschrift mit einem Zahlungsempfänger ohne Namen dieselben vier Regeln.
• Alle vier Befunde stammen aus dem Prüfschritt EN 16931; der Peppol-Prüfschritt der fehlerhaften Rechnung meldet nichts zum Zahlungsempfänger.
• Nur cac:PartyIdentification/cbc:ID wird mit dem Verkäufer verglichen. Die elektronische Adresse, die Umsatzsteuer-Identifikationsnummer und die Kennung der rechtlichen Registrierung des Verkäufers spielen für diese Regel keine Rolle.
• Eine SEPA-Gläubiger-Identifikationsnummer kann in der cac:PartyIdentification des Zahlungsempfängers mit schemeID="SEPA" stehen. UBL-SR-20 zählt sie nicht zu den Kennungen des Zahlungsempfängers.

Verwandte Regeln

• BR-06 verlangt das RegistrationName des Verkäufers, den Wert, mit dem UBL-SR-19 bis UBL-SR-21 den Namen des Zahlungsempfängers vergleichen
• BR-CL-10 prüft das Schema einer Kennung des Zahlungsempfängers und akzeptiert dort SEPA
• PEPPOL-EN16931-R008 meldet ein Namenselement des Zahlungsempfängers, das vorhanden, aber leer ist
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): Understanding EN 16931 validation errors

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-24.

Die offizielle Definition von BR-17 (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.