UBL-SR-47: In jedem PaymentMeans denselben Code für die Zahlungsart verwenden

Die kurze Antwort

UBL-SR-47 schlägt fehl, wenn die Werte von cbc:PaymentMeansCode in einem Dokument nicht alle gleich sind. Das aufgezeichnete Beispiel bietet ein Konto unter 30, Überweisung, und ein zweites unter 58, SEPA-Überweisung, an. Wählen Sie den einen Code, der beschreibt, wie die Rechnung bezahlt werden soll, und verwenden Sie ihn in jedem cac:PaymentMeans.

Das Wiederholen von cac:PaymentMeans ist der Weg, auf dem UBL mehrere Konten für dieselbe Zahlungsart aufführt. Es ist kein Weg, verschiedene Zahlungsarten anzubieten, denn das Modell hat einen einzigen Code für die Zahlungsart je Rechnung.

Was die Regel prüft

Die Regel läuft einmal an der Wurzel des Dokuments, sammelt jeden cbc:PaymentMeansCode und schlägt fehl, wenn mehr als ein unterschiedlicher Wert gefunden wird. Beliebig viele Zahlungsarten mit demselben Code bestehen, wie die korrigierte Rechnung mit zweien unter 30 zeigt.

Codes werden so verglichen, wie sie geschrieben sind, ohne Kürzen. Im Versuch ließ 30 mit einem führenden Leerzeichen neben 30 diese Regel scheitern, obwohl BR-CL-16 beide als den Code 30 akzeptierte.

Jede Mischung von Zahlungsarten scheitert auf dieselbe Weise. Im Versuch meldete eine Kartenzahlung unter 48 mit den letzten vier Ziffern der Karte neben einer Überweisung unter 30 diese Regel und sonst nichts.

Das optionale Attribut name am Code wird nicht verglichen. Im Versuch bestand es alle Prüfschritte, als der erste Code name="Credit transfer" erhielt und der zweite keines.

Wie es in einer Integration dazu kommt

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

• Die Rechnung führt jeden Weg, auf dem der Lieferant Zahlungen annimmt, etwa eine Überweisung und eine Karte, als eigene Zahlungsart auf.
• Inländische Konten und Eurokonten werden mit dem Code ihres eigenen Verfahrens exportiert, 30 für das eine und 58 für das SEPA-Konto.
• Zahlungsarten werden aus einem Lieferantenprofil kopiert, in dem jedes Konto seinen eigenen Code hat, und jedes Konto landet in jeder Rechnung.
• Ein Code wird nur an einer Stelle aufgefüllt oder aus einem Feld fester Breite gelesen, sodass eine Kopie ein Leerzeichen trägt.

So korrigieren Sie das Dokument

1. Legen Sie die eine Zahlungsart für diese Rechnung fest. Darf der Käufer für eine Überweisung eines von zwei Konten verwenden, deckt ein einziger Überweisungscode beide ab; 30 ist der allgemeine Code für die Überweisung.
2. Schreiben Sie diesen Code gekürzt und identisch in jedes cac:PaymentMeans.
3. Lassen Sie Zahlungsarten für andere Verfahren, etwa eine Karte, aus der Rechnung weg. Muss der Käufer davon wissen, beschreiben Sie sie in der Bemerkung zu den Zahlungsbedingungen.
4. Behalten Sie in jeder Zahlungsart ein cac:PayeeFinancialAccount mit seiner Kennung, wie BR-61 es für Überweisungen verlangt.

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 zweite Konto wird als SEPA-Überweisung angeboten, Code 58

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <!-- first payee account omitted from this fragment -->
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Ausschnitt der korrigierten Rechnung: Beide Konten werden unter Code 30 angeboten

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <!-- first payee account omitted from this fragment -->
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

In der fehlerhaften Rechnung verwendet das zweite cac:PaymentMeans den Code 58, in der korrigierten 30, wie das erste. Konto und Zahlungsreferenz sind in beiden gleich. Gemeldet wird nur UBL-SR-47, an der Wurzel des Dokuments: 58 ist ein zulässiger Code, und jede Zahlungsart erfüllt die Anforderungen an eine Überweisung für sich.

Wo die Regel gilt

• Gilt für Invoice und CreditNote. Im Versuch meldete auch eine Gutschrift mit Zahlungsarten unter 30 und 58 diese Regel.
• Gemeldet vom Prüfschritt EN 16931 als Teil der UBL-Syntaxbindung.
• Eine einzelne Zahlungsart unter 58 ist in Ordnung. Im Versuch bestand die Beispielrechnung mit einem Konto, deren Code von 30 auf 58 geändert wurde, alle Prüfschritte.
• Die Zahlungsreferenz wird auf dieselbe Weise auf einen Wert beschränkt, durch UBL-SR-44.

Verwandte Regeln

• UBL-SR-44 lässt über alle Zahlungsarten hinweg nur eine unterschiedliche Zahlungsreferenz zu
• BR-CL-16 prüft, dass jeder Code für die Zahlungsart in der zulässigen Liste steht
• BR-61 verlangt das Empfängerkonto in jeder Zahlungsart, die als Überweisung codiert ist
• UBL-SR-48 ist eine weitere UBL-Syntaxregel, die ein wiederholbares Element auf das beschränkt, was das Modell erlaubt: eine Steuerkategorie je Position
• 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-28.1: Quelle geprüft am 2026-09-28, Erklärung zuletzt aktualisiert am 2026-09-28.

Die offizielle Definition von UBL-SR-47 (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.