BR-DE-17: Die Rechnungsart (BT-3) ist für XRechnung nicht vorgesehen

Was die Regel prüft

• UBL: Kontext Invoice bzw. CreditNote, Test: cbc:InvoiceTypeCode oder cbc:CreditNoteTypeCode (nach normalize-space) ist einer der Werte 326, 380, 384, 389, 381, 875, 876, 877.
• CII: Kontext rsm:CrossIndustryInvoice, Test: rsm:ExchangedDocument/ram:TypeCode ist einer dieser Werte.
• Die Regel hat im Schematron die Stufe warning, nicht fatal. Die Datei verstößt damit nicht gegen eine Pflichtregel, weicht aber von der Vorgabe der Spezifikation ab.

Die Hinweise zu 384, 381 und 389 stammen aus Abschnitt 13.1 der Spezifikation („Umgang mit (Rechnungs)Berichtigungen und Gutschriften“). Die Bau-Codes 875 bis 877 kamen mit XRechnung 1.2.2 hinzu, Code 389 mit 1.2.0.

Typische Ursachen

• Anzahlungsrechnung als 386. UNTDID 1001 kennt 386 „Prepayment invoice“. Für XRechnung ist der Code nicht vorgesehen. Welcher vorgesehene Code passt, hängt vom Geschäftsfall ab; die Liste enthält 326 für Teilrechnungen und 875 für Abschläge bei Bauleistungen.
• Belastung als 383. Eine Nachbelastung wird mit 383 „Debit note“ exportiert, der ebenfalls nicht in der Liste steht.
• Code-Zuordnung aus einem anderen Format. Die Software verwendet für alle E-Rechnungsformate dieselbe Zuordnung von Belegarten zu Codes, die für XRechnung nicht passt.
• Eigene Belegarten. In der Software wurden eigene Belegarten angelegt, etwa „Storno“ oder „Nachberechnung“, ohne ihnen einen der vorgesehenen Codes zuzuordnen.

Beispiel aus der KoSIT-Testsuite

Testdatei 01.18 ist eine Rechnungsberichtigung mit Code 384. Sie verweist in cac:BillingReference auf die ursprüngliche Rechnung PRG1502168.

<cbc:ID>PRG1502112</cbc:ID>
<cbc:IssueDate>2015-04-24</cbc:IssueDate>
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
<cbc:Note>#ADU#Trainer: Herr […]</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>99000000-18188-18</cbc:BuyerReference>
<cac:InvoicePeriod>
  <cbc:StartDate>2015-04-20</cbc:StartDate>
  <cbc:EndDate>2015-04-24</cbc:EndDate>
</cac:InvoicePeriod>
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>PRG1502168</cbc:ID>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

<rsm:ExchangedDocument>
  <ram:ID>PRG1502112</ram:ID>
  <ram:TypeCode>384</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20150424</udt:DateTimeString>
  </ram:IssueDateTime>
  <ram:IncludedNote>
    <ram:Content>Trainer: Herr […]</ram:Content>
    <ram:SubjectCode>ADU</ram:SubjectCode>
  </ram:IncludedNote>
</rsm:ExchangedDocument>

In CII steht der Bezug auf die Vorrechnung weiter hinten in ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument. Weitere Codes zeigt die Testsuite in Datei 01.20 (389, Gutschrift nach UStG) und extension/04.03a-INVOICE_ubl.xml (877, Schlussrechnung Bau). Stünde in cbc:InvoiceTypeCode etwa 386, meldete die Prüfung BR-DE-17 als Warnung.

Lösung

In der Rechnungssoftware

1. Prüfen Sie, welche Belegart Sie gewählt haben, und ordnen Sie sie einem der acht Codes zu. Die Zuordnung steht meist in den Einstellungen für Belegarten oder für den E-Rechnungs-Export.
2. Für Korrekturen verwenden Sie 384 und geben die Nummer der ursprünglichen Rechnung an. Ohne diesen Bezug folgt die Warnung BR-DE-26.
3. Erstellt Ihr Kunde die Abrechnung für Sie (Gutschriftverfahren), gehört 389 in die Datei, nicht 381.

Im XML

1. UBL: Ändern Sie den Wert in cbc:InvoiceTypeCode. Bei einem CreditNote-Dokument steht der Code in cbc:CreditNoteTypeCode.
2. CII: Ändern Sie den Wert in rsm:ExchangedDocument/ram:TypeCode.
3. Validieren Sie die Datei mit XRechnung prüfen. Bei Code 384 achten Sie im Bericht zusätzlich auf BR-DE-26.

XRechnung prüfen