XRechnung aus JTL-Wawi: BT-13 (Bestellreferenz des Käufers) richtig füllen – z. B. für Conrad

Eine XRechnung kann formal valide sein und trotzdem vom Empfänger zurückkommen. Ein typischer Fall bei Marktplätzen wie Conrad: Die Rechnung wird abgewiesen, weil die Bestellreferenz des Käufers (BT-13) fehlt – oder weil dort eine Nummer steht, mit der der Empfänger nichts anfangen kann.

Die Ursache liegt meist nicht in den Auftragsdaten, sondern in der XRechnung-Vorlage: BT-13 wird gar nicht ausgegeben oder mit der falschen Nummer befüllt. Wir zeigen, wie Sie das in einer Liquid-Vorlage der JTL-Wawi sauber lösen.

Worum es bei BT-13 geht

Die europäische Norm EN 16931 beschreibt jedes Feld einer E-Rechnung mit einer Nummer, dem sogenannten Business Term (BT). Für die Zuordnung einer Rechnung zur Bestellung gibt es mehrere Referenzen, die leicht verwechselt werden:

BT-13 ist in der Norm mit der Kardinalität [0..1] definiert – also optional. Ein Rechnungsempfänger darf das Feld aber in seinen eigenen Anforderungen zur Pflicht machen. Marktplätze und große Händler tun das, weil sie eingehende Rechnungen automatisch über ihre eigene Bestellnummer zuordnen.

Ein Validator wie der KoSIT-Prüfer meldet bei fehlendem BT-13 keinen Fehler. Dass die Rechnung trotzdem abgelehnt wird, erfahren Sie erst vom Empfänger.

Woher die Nummer in JTL-Wawi kommt

Für die Referenzen stellt die Liquid-Vorlage zwei Werte bereit:

• Report.SalesOrderNumbers – die eigene Auftragsnummer der Wawi. Sie gehört in BT-14.
• Report.ExternalSalesOrderNumbers – die externe Auftragsnummer, also die Nummer, unter der der Käufer oder Marktplatz die Bestellung führt. Bei Conrad ist das die Bestellnummer aus dem Conrad-System. Sie gehört in BT-13.

Der häufigste Fehler: In BT-13 landet die interne Auftragsnummer – oder BT-13 fehlt ganz, weil die Vorlage das Element nur auskommentiert enthält.

Die Lösung: BT-13 aus der externen Auftragsnummer, mit Fallback

In der Vorlage gehört BT-13 in den Block ram:ApplicableHeaderTradeAgreement, direkt nach ram:SellerOrderReferencedDocument (BT-14). Die Reihenfolge der Elemente ist im CII-Schema festgelegt – an falscher Stelle schlägt die Schema-Prüfung fehl.

{%- comment -%} BT-14: Auftragsnummer des Verkäufers {%- endcomment -%}
<ram:SellerOrderReferencedDocument>
    <ram:IssuerAssignedID>
        <![CDATA[{{ Report.SalesOrderNumbers }}]]>
    </ram:IssuerAssignedID>
</ram:SellerOrderReferencedDocument>

{%- comment -%} BT-13: Bestellnummer des Käufers, Fallback auf interne Nummer {%- endcomment -%}
<ram:BuyerOrderReferencedDocument>
    <ram:IssuerAssignedID>
        {%- if Report.ExternalSalesOrderNumbers != null and Report.ExternalSalesOrderNumbers != '' -%}
        <![CDATA[{{ Report.ExternalSalesOrderNumbers | Trim }}]]>
        {%- else -%}
        <![CDATA[{{ Report.SalesOrderNumbers | Trim }}]]>
        {%- endif -%}
    </ram:IssuerAssignedID>
</ram:BuyerOrderReferencedDocument>

Was die einzelnen Teile bewirken:

• Die Bedingung prüft auf null und auf einen leeren String. Nur auf eines zu prüfen reicht nicht – je nach Auftragsherkunft ist das Feld entweder gar nicht gesetzt oder leer.
• Trim entfernt Leerzeichen am Anfang und Ende. Ein angehängtes Leerzeichen genügt, damit der automatische Abgleich beim Empfänger fehlschlägt.
• CDATA schützt den Wert, falls die Nummer Zeichen wie & oder < enthält.
• Der Fallback auf die interne Auftragsnummer sorgt dafür, dass das Element nie leer ausgegeben wird. Ein leeres IssuerAssignedID ist ungültig.

Der Fallback ist ein Sicherheitsnetz, keine Lösung für Marktplatz-Aufträge. Erwartet der Empfänger seine eigene Bestellnummer, kann er mit Ihrer internen Nummer nichts zuordnen. Fehlt bei solchen Aufträgen die externe Auftragsnummer, liegt das Problem im Import des Auftrags – nicht in der Vorlage.

Nicht verwechseln: BT-10 ist keine Bestellnummer

Manche Vorlagen versuchen, ein fehlendes BT-13 über BT-10 (ram:BuyerReference) auszugleichen. Das führt nicht zum Ziel: BT-10 ist die Käuferreferenz zur internen Lenkung – bei öffentlichen Auftraggebern die Leitweg-ID. Ein Empfänger, der BT-13 verlangt, schaut nicht in BT-10.

Ein bewährtes Muster für BT-10 ist eine Prioritätenfolge per DirectQueryScalar: zuerst ein Auftragsattribut Leitweg-ID bzw. BuyerReference, dann ein gleichnamiges eigenes Feld am Kunden, zuletzt die Kundennummer. So bleibt BT-10 sauber getrennt von BT-13.

Am Rande: Lieferantennummer in BT-29

Manche Rechnungsempfänger möchten zusätzlich Ihre Lieferantennummer aus ihrem System sehen – das ist von Empfänger zu Empfänger verschieden. Dafür ist BT-29 vorgesehen – die Kennung des Verkäufers, als ram:ID innerhalb von ram:SellerTradeParty. In der Praxis hat sich ein eigenes Kundenfeld „Lieferantennummer“ am Marktplatz-Kunden bewährt: Die Vorlage liest den Wert per DirectQueryScalar aus und lässt das Element weg, wenn das Feld leer ist. Für alle anderen Kunden ändert sich nichts.

Testen, bevor Sie die Vorlage produktiv schalten

1. Legen Sie eine Kopie der aktuellen XRechnung-Vorlage an und bearbeiten Sie nur diese.
2. Erzeugen Sie die XRechnung für einen Auftrag mit externer Auftragsnummer (z. B. einen Conrad-Auftrag) und für einen Auftrag ohne.
3. Öffnen Sie beide XML-Dateien und prüfen Sie BuyerOrderReferencedDocument: einmal die Käufer-Bestellnummer, einmal die interne Nummer – jeweils ohne Leerzeichen.
4. Lassen Sie beide Dateien durch einen XRechnung-Validator laufen.
5. Erst dann die Vorlage als Standard setzen.

Typische Fehler auf einen Blick

Wenn Ihre XRechnung von einem Marktplatz oder Großkunden abgelehnt wird und die Fehlermeldung nicht eindeutig ist, prüfen wir Ihre Vorlage gern gemeinsam mit Ihnen gegen die Anforderungen des Empfängers.

Häufige Fragen