# 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)

> **Wo CII-SR-465 geprüft wird**
>
> 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“.

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

- [XML validieren](/de/xrechnung-validator?source=resource&rule=CII-SR-465)
- [Rechnung konvertieren](/de/pdf-to-xrechnung?source=resource&rule=CII-SR-465)

## 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](/resources/xrechnung/bt-41-seller-contact-point)
- [BG-6 Verkäuferkontakt](/resources/xrechnung/bt-41-seller-contact-point)

## Verwandte Regeln

- [BR-DE-2](/resources/kosit-validator-errors/br-de-2-seller-contact-required)
- [BR-DE-5](/resources/kosit-validator-errors/br-de-5-seller-contact-point-required)
- [CII-SR-466](/resources/kosit-validator-errors/cii-sr-466-buyer-contact-person-or-department-name)

## Validierungstools

- [Offizieller KoSIT Validator](https://github.com/itplr-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](/pdf-to-xrechnung): Validierungsfehler beim Konvertieren erkennen, prüfen und gezielt beheben.

## Verwandte Ressourcen

- [Offizielle Spezifikation](https://github.com/ConnectingEurope/eInvoicing-EN16931)
- [Testsuite](https://github.com/itplr-kosit/xrechnung-testsuite)
- [Alle Validierungsfehler](/resources/kosit-validator-errors): Übersicht der hier erklärten Validierungsregeln aus EN 16931, XRechnung und Peppol.