Zum Hauptinhalt springen

Referenz

Markdown-Export

CII-SR-465 Verkäuferkontakt: Personenname oder Abteilungsname, nicht beides

In CII ist die Kontaktstelle des Verkäufers (BT-41) entweder ram:PersonName oder ram:DepartmentName in ram:SellerTradeParty/ram:DefinedTradeContact. CII-SR-465 („Only one BT-41 element is allowed on an invoice“) schlägt fehl, wenn beide Elemente vorhanden sind. Die CEN-Validierungsartefakte melden die Regel als Warnung; die KoSIT-Konfiguration für XRechnung 3.0.2 vom 31.08.2026 stuft sie für XRechnung in CII-Syntax zum Fehler hoch.

Problembeschreibung

FEHLER

EN-16931-Syntaxregel für CII (CEN, CII-SR)

Interaktive Prüfkette

Klicken Sie auf eine Stufe, um zu sehen, was sie prüft, oder geben Sie eine Regel-ID ein, um die meldende Stufe zu finden.

Beispiele:

CII-SR-465 Syntaxregel der EN 16931 für UBL oder CII

Gemeldet in Stufe 2: Regeln der EN 16931.

Stufe Fehler: Der Bericht empfiehlt, die Rechnung abzulehnen.

Stufe 2 · Was geprüft wird

  • Die Kern-Geschäftsbegriffe sind vorhanden (BR-01 bis BR-65).
  • Summen gehen auf und zusammenhängende Felder passen zueinander (BR-CO); Codes und Nachkommastellen sind gültig (BR-CL, BR-DEC).
  • Jede Umsatzsteuerkategorie ist stimmig: S, Z, E, AE, K, G, O, L, M (BR-S, BR-Z, BR-AE, BR-IC …).

Beispielcodes

Typische Korrektur

Berechnen Sie Summen und Umsatzsteuer aus den Positionen neu und korrigieren Sie die Steuerkategorie in den Quelldaten.

Ein Validator prüft eine E-Rechnung in Stufen. Zuerst muss die Datei wohlgeformtes XML sein und zum UBL- oder CII-Schema (XSD) passen. Dann laufen die Geschäftsregeln der EN 16931: BR-Kernregeln, BR-CO-Berechnungen, BR-CL-Codelisten, BR-DEC-Nachkommastellen und Regeln je Umsatzsteuerkategorie wie BR-S. Danach folgen die nationalen oder Netzwerk-Regeln, die BT-24 auswählt: BR-DE für XRechnung, PEPPOL-EN16931 für Peppol BIS Billing. Der Bericht nennt jede verletzte Regel: Ein Fehler bedeutet Ablehnung, nur Warnungen bedeuten weiterhin Annahme. CII-SR-465: Syntaxregel der EN 16931 für UBL oder CII, gemeldet in der Stufe „Regeln der EN 16931“. Regelwerke: KoSIT-Validator 1.6.3 mit der XRechnung-Konfiguration vom 31. Aug. 2026 (EN-16931-Artefakte 1.3.16), Peppol BIS Billing 3.0.21.

Kontext und Bedeutung

Dateien, die eine frühere KoSIT-Konfiguration bestanden haben, können seit dem Release vom 31.08.2026 scheitern, weil die Regel vorher nur eine Warnung war. ERP-Exporte schreiben oft Ansprechpartner und Abteilung nebeneinander, weil beide auf dem PDF stehen.

Lösung

Behalten Sie einen Wert für BT-41. Verwenden Sie ram:PersonName für eine namentlich genannte Person oder ram:DepartmentName, wenn es nur eine Abteilung gibt, und entfernen Sie das andere Element. UBL ist nicht betroffen: Dort ist BT-41 das einzelne Element cac:Contact/cbc:Name.

Schnellzugriff

XML validierenRechnung konvertieren

Gültige Beispiele

  • ram:PersonName = „Anna Schmidt“
  • ram:DepartmentName = „Buchhaltung“ (ohne PersonName)

Ungültige Beispiele

  • ram:PersonName = „Anna Schmidt“ und ram:DepartmentName = „Buchhaltung“

Code-Beispiele

Gültiges XML
<ram:DefinedTradeContact>
  <ram:PersonName>Anna Schmidt</ram:PersonName>
  <ram:TelephoneUniversalCommunication>
    <ram:CompleteNumber>+49 30 1234567</ram:CompleteNumber>
  </ram:TelephoneUniversalCommunication>
  <ram:EmailURIUniversalCommunication>
    <ram:URIID>billing@example.com</ram:URIID>
  </ram:EmailURIUniversalCommunication>
</ram:DefinedTradeContact>
Ungültiges XML
<ram:DefinedTradeContact>
  <ram:PersonName>Anna Schmidt</ram:PersonName>
  <ram:DepartmentName>Accounts receivable</ram:DepartmentName>
</ram:DefinedTradeContact>

Betroffene Felder

BT-41 Kontaktstelle des Verkäufers
BG-6 Verkäuferkontakt

Validierungstools

Offizieller KoSIT Validator

Führen Sie den offiziellen KoSIT-Validator mit der XRechnung-Konfiguration aus, um EN-16931- und XRechnung-Regeln zu prüfen.

PDF zu XRechnung konvertieren

Validierungsfehler beim Konvertieren erkennen, prüfen und gezielt beheben.