UBL-SR-44: Für alle Zahlungsarten der Rechnung einen einzigen Verwendungszweck verwenden

Die kurze Antwort

UBL-SR-44 schlägt fehl, wenn das Dokument Elemente cbc:PaymentID mit mehr als einem unterschiedlichen Wert enthält. Im aufgezeichneten Beispiel verlangt das zweite cac:PaymentMeans PAYMENT-002, wo das erste PAYMENT-001 verlangt. Wählen Sie die eine Referenz, die der Käufer angeben soll, und schreiben Sie genau diesen Wert in jede Zahlungsart.

Mehrere Zahlungsarten sind erlaubt, etwa eine für jedes Bankkonto, auf das der Käufer zahlen darf, und jede darf die Referenz wiederholen. Was das Modell nicht abbilden kann, ist eine zweite, abweichende Referenz: Es hat ein einziges Feld für den Verwendungszweck der ganzen Rechnung.

Was die Regel prüft

Die Regel läuft einmal je Dokument und sammelt jedes cbc:PaymentID, wo immer es steht. Sie zählt die unterschiedlichen Werte und schlägt bei zwei oder mehr fehl; der Befund verweist auf die Wurzel des Dokuments, und im Versuch mit drei Zahlungsarten, die drei verschiedene Referenzen verlangten, gab es trotzdem nur einen Befund.

Wiederholungen und Lücken sind erlaubt. Im Versuch bestand das Dokument, als cbc:PaymentID aus der zweiten Zahlungsart entfernt wurde, und die korrigierte Rechnung gibt in beiden PAYMENT-001 an.

Werte werden genau so verglichen, wie sie geschrieben sind. Im Versuch zählten PAYMENT-001 mit einem Leerzeichen am Ende und payment-001 in Kleinbuchstaben jeweils als zweite Referenz und ließen die Regel scheitern.

Zwei verschiedene Referenzen in einer einzigen Zahlungsart scheitern doppelt. Im Versuch meldete ein einzelnes cac:PaymentMeans mit PAYMENT-001 und PAYMENT-002 diese Regel und UBL-SR-26, das ein cbc:PaymentID je Zahlungsart zulässt; derselbe Wert zweimal geschrieben meldete dort nur UBL-SR-26.

Wie es in einer Integration dazu kommt

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

• Die Zahlungsreferenz wird je Bankkonto oder je Zahlungskanal erzeugt, sodass jedes cac:PaymentMeans eine eigene erhält.
• Raten werden als getrennte Zahlungsarten abgebildet, jede mit der Referenz ihrer Rate.
• Eine Referenz wird an einer Stelle normalisiert und an einer anderen nicht, sodass eine Kopie ein Leerzeichen am Ende oder eine andere Groß- und Kleinschreibung trägt.

So korrigieren Sie das Dokument

1. Legen Sie fest, welche Referenz der Käufer bei der Zahlung angeben muss, etwa die Rechnungsnummer oder eine strukturierte Gläubigerreferenz.
2. Schreiben Sie genau diesen Wert, Zeichen für Zeichen, in das cbc:PaymentID jedes cac:PaymentMeans, das eines trägt, oder lassen Sie es in allen bis auf eines weg.
3. Brauchen Sie unterschiedliche Referenzen für verschiedene Konten oder Raten, hat das Modell dafür keinen Platz. Behalten Sie eine Referenz und beschreiben Sie die Vereinbarung in den Zahlungsbedingungen, cac:PaymentTerms/cbc:Note.
4. Kürzen und normalisieren Sie die Referenz einmal, bevor sie in die einzelnen Zahlungsarten kopiert wird.

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: zwei Konten, jedes mit eigener Zahlungsreferenz

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-002</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 verlangen PAYMENT-001

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</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>

Das zweite cac:PaymentMeans trägt in der fehlerhaften Rechnung PAYMENT-002 und in der korrigierten PAYMENT-001; beide Dokumente bieten dieselben zwei Konten unter dem Code 30 an. Das fehlerhafte Dokument meldet nur UBL-SR-44, an der Wurzel des Dokuments, da jede Zahlungsart für sich vollständig und gültig ist.

Wo die Regel gilt

• Gilt für Invoice und CreditNote. Im Versuch meldete eine Gutschrift mit zwei Zahlungsarten, die unterschiedliche Referenzen verlangten, diese Regel.
• Teil der UBL-Syntaxbindung, gemeldet im Prüfschritt EN 16931; der Peppol-Prüfschritt bestand die aufgezeichnete fehlerhafte Rechnung.
• Für den Code der Zahlungsart gilt dieselbe Beschränkung auf einen Wert, durchgesetzt von UBL-SR-47. Im Versuch meldete die Änderung von Code und Referenz der zweiten Zahlungsart beide Regeln.
• Auch ein leeres cbc:PaymentID zählt als Wert. Im Versuch meldete das Leeren des zweiten diese Regel und PEPPOL-EN16931-R008.

Verwandte Regeln

• UBL-SR-47 verlangt in jeder Zahlungsart denselben Code für die Zahlungsart
• BR-61 verlangt in jeder Zahlungsart für eine Überweisung eine Kontokennung
• PEPPOL-EN16931-R008 meldet ein leer gelassenes Element für die Zahlungsreferenz
• UBL-SR-45 lässt ein Fälligkeitsdatum nur in einer Zahlungsart zu, auch wenn die Daten übereinstimmen
• 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-44 (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.