Bestellnummer in der E-Rechnung: BT-13 im XML prüfen

Veröffentlicht und geprüft am 9. Oktober 2026

Die Bestellnummer des Kunden gehört in das strukturierte Feld BT-13, wenn Sie diese Bestellung in der E-Rechnung referenzieren. Verwenden Sie dafür das vom Hersteller ausdrücklich zugeordnete Bestellreferenzfeld. Ein Text im PDF, ein Rechnungstitel oder Ihre eigene Auftragsnummer beweist nicht, dass BT-13 befüllt ist. Kontrollieren Sie die tatsächlich exportierte Datei und gleichen Sie den Wert mit der Kundenbestellung ab.

Vor dem ersten echten Versand

Fragen Sie den Kunden nach seiner Bestellreferenz und einer gegebenenfalls zusätzlich verlangten Käuferreferenz. Erfassen Sie beide getrennt, exportieren Sie einen Testbeleg und kontrollieren Sie die Felder. Eine technisch gültige Datei kann trotzdem auf die falsche Bestellung zeigen.

Dieser Leitfaden richtet sich an kleine Dienstleistungs- und Lieferbetriebe, deren Kunden einen Bestellbezug für die Rechnungsprüfung verlangen. Er erklärt die Feldzuordnung und einen eigenen Software-Abnahmetest. Für den vollständigen Behördenprozess gibt es den getrennten Leitfaden zu Leitweg-ID und Einreichung einer XRechnung an Bundesbehörden.

Bestellnummer, Auftragsnummer und Käuferreferenz unterscheiden

Entscheidend ist zunächst, wer die Nummer vergeben hat. Ihre Auftragsbestätigung kann einen internen Vorgang identifizieren, während der Kunde dieselbe Leistung unter seiner eigenen Einkaufsnummer führt. Eine ähnlich aussehende Nummer ist nicht automatisch dieselbe Referenz. Übernehmen Sie den bestätigten Wert vollständig, einschließlich Buchstaben, Trennzeichen und führender Nullen.

Angabe	Bedeutung	Kontrolle im Auftrag
AngabeBT-13: Bestellreferenz	BedeutungKennung der Bestellung, vom Käufer vergeben	Kontrolle im AuftragWelche Nummer nennt die Einkaufsbestellung des Kunden?
AngabeBT-14: Verkaufsauftragsreferenz	BedeutungKennung eines Verkaufsauftrags, vom Verkäufer vergeben	Kontrolle im AuftragIst dies Ihre eigene Auftragsnummer statt der Kundenbestellung?
AngabeBT-10: Käuferreferenz	BedeutungVom Käufer vorgegebene Referenz für interne Weiterleitung	Kontrolle im AuftragWelche Zuordnungsangabe erwartet die Empfangsstelle zusätzlich?

Die offizielle Peppol-Beschreibung von BT-13 ordnet die Bestellkennung dem Käufer zu. BT-14 hat einen anderen Aussteller; BT-10 dient der internen Zuordnung beim Käufer. Bei einem öffentlichen Empfänger wird für BT-10 die mitgeteilte Leitweg-ID verwendet. Diese Felder sollten nicht allein wegen des allgemeinen Etiketts „Referenz“ zusammengelegt werden.

Eine Kundennummer aus Ihrem Adressbuch ist ebenfalls kein Ersatz für eine konkrete Bestellung. Notieren Sie bei unklaren Anforderungen nicht bloß „Nummer fehlt“, sondern die offene Frage: Bestellkennung des Einkaufs, interne Empfangsreferenz oder Ihre eigene Vorgangsnummer? Damit kann der Ansprechpartner gezielt antworten.

Ist die Bestellnummer in jeder E-Rechnung Pflicht?

Es gibt keine sinnvolle Pauschalantwort ohne das vereinbarte Format und den Empfänger. BT-13 ist ein optionaler Bestellbezug im Datenmodell; eine konkrete Kundenanforderung oder zusätzliche Regel kann seine Angabe dennoch nötig machen. Klären Sie die Anforderung vor der Abrechnung, nicht erst nach einer Rückweisung. Der Empfänger kann eine vorhandene Bestellung prüfen wollen, obwohl eine rein technische Prüfung ohne deren Inhalt auskommt.

Peppol BIS Billing: Die allgemeine Regel PEPPOL-EN16931-R003 verlangt Käuferreferenz oder Bestellreferenz. Daraus folgt aber nicht, dass BT-13 in jedem Fall BT-10 ersetzen darf.
Deutscher Inlandsfall im Peppol-Regelwerk: Sind Lieferant und Kunde in Deutschland ansässig, verlangt DE-R-015 zusätzlich BT-10. Eine vorhandene Bestellnummer hebt diese Zusatzanforderung nicht auf.
XRechnung: Die KoSIT-Regel BR-DE-15 fordert eine nicht leere Käuferreferenz. BT-13 und BT-10 sind deshalb separat zu kontrollieren.
Bundesauftrag: Nach § 5 Absatz 2 ERechV ist eine Bestellnummer zusätzlich aufzunehmen, wenn sie bereits bei Beauftragung übermittelt wurde. Diese Regel für den Bund sollte nicht als allgemeine B2B-Pflicht dargestellt werden.

Erfinden Sie weder eine Bestellnummer noch eine Leitweg-ID, um eine Fehlermeldung verschwinden zu lassen. Lassen Sie sich den vorgesehenen Referenzwert bestätigen. Der aktuelle technische Prüfbericht und die Auftragsunterlagen beantworten unterschiedliche Fragen: Formatkonformität einerseits, tatsächliche Zuordnung andererseits.

Das richtige Feld in der Rechnungssoftware einrichten

Suchen Sie in der offiziellen Hilfe nach „Bestellnummer“, „Bestellreferenz“, „Purchase Order“ oder „BT-13“. Ein frei benanntes Zusatzfeld ist erst dann ausreichend, wenn dessen Zuordnung zum strukturierten Export dokumentiert ist. Der Feldname in der Eingabemaske allein ist kein Nachweis. Fragen Sie den Support im Zweifel: „Welches Eingabefeld wird in meinem gewählten Format nach BT-13 exportiert?“

Quelle festhalten: Legen Sie die bestätigte Kundenbestellung zum Vorgang und markieren Sie den exakt zu übernehmenden Wert.
Ebene wählen: Prüfen Sie, ob der Wert beim Projekt, beim Auftrag oder direkt im Rechnungsentwurf gepflegt wird. Eine bestellbezogene Nummer sollte nicht ungeprüft als dauerhafter Kundenstandard dienen.
Mapping bestätigen: Stellen Sie fest, ob das Feld wirklich BT-13 befüllt oder nur im Rechnungslayout erscheint.
Vorbelegung kontrollieren: Erzeugen Sie einen neuen Entwurf. Prüfen Sie, ob die richtige Nummer übernommen wurde und ob eine manuelle Änderung im Entwurf Vorrang hat.
Alte Felder prüfen: Vergleichen Sie bisherige Zusatzfelder und das neue Standardfeld. Zwei sichtbare Bestellnummern mit unterschiedlichen Werten sind ein Warnsignal.
Export testen: Laden Sie genau das Format herunter, das später an den Kunden geht. Prüfen Sie den exportierten Wert und nicht nur die Bildschirmvorschau.

Auch eine Schnittstelle benötigt diese Kontrolle. Notieren Sie für einen CSV-Import oder eine API-Anbindung Quellfeld, Zielfeld und Beispielwert. Prüfen Sie insbesondere, ob eine Tabellenkalkulation führende Nullen entfernt oder ob ein Import mit leerem Wert eine vorhandene Nummer überschreibt. Das sind Testfragen an Ihre konkrete Verbindung, keine behaupteten Eigenschaften jedes Produkts.

BT-13 im XML finden: das UBL-Beispiel

In einer UBL-Rechnung wird BT-13 über cac:OrderReference und dessen Kind cbc:ID abgebildet. BT-14 ist dort cbc:SalesOrderID; BT-10 steht getrennt als cbc:BuyerReference. Der folgende unvollständige UBL-Ausschnitt zeigt nur die Zuordnung mit erfundenen Werten. Er ist keine versandfertige oder vollständig validierte Rechnung:

<cbc:BuyerReference>EINKAUF-WEST</cbc:BuyerReference>
<cac:OrderReference>
  <cbc:ID>PO-00841</cbc:ID>
  <cbc:SalesOrderID>AUF-26109</cbc:SalesOrderID>
</cac:OrderReference>

Die Kundenbestellung lautet hier PO-00841; AUF-26109 ist die eigene Verkaufsauftragsreferenz. Die Käuferreferenz ist ein gesonderter, im Muster vereinbarter Zuordnungswert. Für eine echte Rechnung übernehmen Sie ausschließlich die zum Auftrag gehörenden Angaben.

Andere Syntaxen, etwa CII, verwenden andere Elementnamen. Suchen Sie dort nicht blind nach einem UBL-Tag. Lassen Sie die Datei in einem geeigneten Werkzeug anzeigen und suchen Sie nach dem fachlichen Feld BT-13. Bei einer hybriden Datei müssen die eingebetteten strukturierten Daten geprüft werden; nur den sichtbaren PDF-Text zu lesen reicht nicht. Der Ablauf zum Öffnen und technischen Prüfen einer XRechnung hilft beim nächsten Schritt.

Eine Volltextsuche nach PO-00841 kann den Wert auch in einer Bemerkung finden. Kontrollieren Sie deshalb zusätzlich das Feld beziehungsweise den XML-Kontext. Ändern Sie die endgültige Datei nicht von Hand, nur damit die Suche einen Treffer liefert: Korrigieren Sie die Quelle im Programm und exportieren Sie neu.

MOCO: ein dokumentiertes Beispiel für ein BT-13-Standardfeld

MOCO beschreibt in seiner offiziellen Hilfe ein aktivierbares Feld Bestellnummer (BT-13) unter Einstellungen → Account → Eigene Felder. Laut Hersteller kann der Wert im Projekt und auf der Rechnung gepflegt werden; eine Projektrechnung wird mit der im Projekt gespeicherten Bestellnummer vorausgefüllt. Die interne Projekt-ID ist damit nicht gemeint.

Für Rechnungen auf Kundenebene ohne Projekt oder über mehrere Projekte beschreibt MOCO keine automatische Vorbelegung einer Bestellnummer. Prüfen Sie den Entwurf daher ausdrücklich. Beim Umstieg von einem bisherigen eigenen Feld bietet der Hersteller eine Übernahme an; dabei wird das alte Feld gelöscht. Sichern und vergleichen Sie Ihre Angaben, bevor Sie diesen Schritt bestätigen. Die aktuelle Hilfe warnt außerdem, dass nicht einem BT-Feld zugeordnete Texte als Bemerkungen ausgegeben werden. Ein gleich beschriftetes Freitextfeld darf deshalb nicht ungeprüft als BT-13-Ersatz gelten.

Dies ist eine Zusammenfassung der Dokumentation, kein eigener Produkttest und keine Kaufempfehlung. Bei einer anderen Software muss derselbe Test zum tatsächlichen Export passen; Menüpfad, Tarifumfang und Übernahmeverhalten können anders sein.

Ein Abnahmetest, den Sie vor dem ersten Versand durchführen können

Arbeiten Sie in einer vorgesehenen Testumgebung oder mit Entwürfen ohne echten Versand. Verwenden Sie erfundene Kundendaten und eine klar markierte Musterbestellung. Wenn das Programm bereits beim Test eine produktive Rechnungsnummer oder Versandaktion auslöst, klären Sie den sicheren Testweg zuerst mit dem Anbieter.

Testfall	Erwartete Kontrolle	Warnsignal
TestfallKunde bestellt unter PO-00841; eigener Auftrag AUF-26109	Erwartete KontrolleBT-13 enthält PO-00841, nicht die eigene Nummer	WarnsignalNur AUF-26109 wird als Bestellreferenz exportiert
TestfallZweite Bestellung desselben Kunden: PO-00842	Erwartete KontrolleNeuer Entwurf und Export tragen die neue Bestellkennung	WarnsignalDer alte Wert aus Kundenstandard oder kopierter Rechnung bleibt stehen
TestfallBestellnummer steht nur im Einleitungstext	Erwartete KontrollePrüfen, ob BT-13 tatsächlich fehlt oder über eine dokumentierte Zuordnung befüllt wird	WarnsignalNummer ist sichtbar, aber nur in einer Bemerkung auffindbar
TestfallBT-13 vorhanden, BT-10 leer	Erwartete KontrolleMit dem tatsächlichen Profil und dessen Länderregeln validieren	WarnsignalBestellnummer wird fälschlich als Freigabe aller Referenzanforderungen behandelt

Halten Sie für jeden Test Format, Programmstand, Eingabefeld, erwarteten Wert und Ergebnis fest. Speichern Sie die erzeugte Testdatei und den Prüfbericht zusammen. Eine Aussage „funktioniert“ ist ohne den dazugehörigen Export schwer nachvollziehbar. Wiederholen Sie den kleinen Test nach einer wesentlichen Änderung an Feldzuordnung, Schnittstelle oder Rechnungsvorlage.

Fehlende Referenz, mehrere Bestellungen oder Ablehnung

Keine Bestellnummer erhalten: Fragen Sie nach, ob es tatsächlich eine Einkaufsvorgangsnummer gibt und welches Feld der Kunde erwartet. Eine vorhandene Käuferreferenz ist nicht automatisch eine Bestellnummer. Halten Sie die Antwort beim Auftrag fest; übernehmen Sie keinen geratenen Wert aus einer alten Rechnung.

Mehrere Bestellungen in einer Rechnung: Das UBL-Element für die Bestellreferenz auf Rechnungsebene ist im Peppol-Billing-Profil höchstens einmal vorgesehen. Schreiben Sie daher nicht ungeprüft eine kommaseparierte Liste in das Feld und nehmen Sie nicht an, dass der Empfänger sie zerlegt. Klären Sie, ob getrennte Rechnungen erwartet werden oder ein ausdrücklich unterstützter Zuordnungsweg vorgesehen ist.

Datei technisch gültig, Kunde lehnt trotzdem ab: Vergleichen Sie die Bestellkennung mit der tatsächlich offenen Bestellung und fragen Sie nach dem konkreten Ablehnungsgrund. Eine abgeschlossene, falsche oder dem falschen Vorgang zugeordnete Bestellung lässt sich nicht durch erneutes Validieren richtig machen. Für die allgemeine Trennung hilft der Leitfaden zu technischen und sachlichen Fehlern in E-Rechnungen.

Nummer nachträglich geändert: Prüfen Sie zuerst, ob bereits versendet wurde. Nutzen Sie den vorgesehenen Korrekturprozess und stimmen Sie eine erneute Einreichung mit dem Empfänger ab. Versenden Sie nicht zwei äußerlich gleiche Rechnungen mit unterschiedlichen Referenzen ohne nachvollziehbare Zuordnung. Der gewählte Versandweg für E-Mail, Portal oder Peppol bleibt eine eigene Kontrolle neben dem Inhalt der Datei.

Freigabe-Checkliste für den nächsten echten Auftrag

Bestellnummer direkt aus der bestätigten Kundenbestellung übernommen?
Eigene Auftragsnummer und Käuferreferenz davon getrennt?
Vom Anbieter dokumentiertes BT-13-Feld statt eines bloßen Layouttexts benutzt?
Bei kopiertem Entwurf oder neuer Bestellung alte Vorbelegung kontrolliert?
Tatsächlich zu versendende Datei geöffnet und BT-13 im richtigen Kontext gefunden?
Mit dem vorgesehenen Profil validiert und weitere BT-10-Anforderungen geprüft?
Auftragsbezug, Freigabe und Rückmeldung nachvollziehbar abgelegt?

Nächster Schritt: Nehmen Sie einen noch nicht abgerechneten Auftrag, bestätigen Sie seine Referenzdaten mit dem Kunden und testen Sie genau diesen Exportweg vor der ersten produktiven Nutzung. Erst wenn Eingabe, Datei und Auftragsunterlagen übereinstimmen, geben Sie den Versand frei.

Häufige Fragen

Ist die Bestellnummer dieselbe wie die Rechnungsnummer?

Nein. Die Bestellnummer des Käufers verweist auf dessen Bestellung; Ihre Rechnungsnummer identifiziert die ausgestellte Rechnung. Übernehmen Sie die vereinbarte Kundenbestellung in BT-13 und lassen Sie die Rechnungsnummer getrennt.

Reicht die Bestellnummer im PDF oder Einleitungstext?

Nicht als Nachweis für BT-13. Prüfen Sie, ob die Software den Wert in das strukturierte Bestellreferenzfeld überträgt. Ein sichtbarer Text kann lediglich als Bemerkung ausgegeben werden.

Kann BT-13 die Käuferreferenz BT-10 ersetzen?

Nicht pauschal. Peppol enthält neben der allgemeinen Entweder-oder-Regel eine zusätzliche BT-10-Anforderung für Lieferant und Kunde in Deutschland. Auch XRechnung verlangt eine Käuferreferenz. Prüfen Sie das tatsächliche Profil und die Vorgaben des Empfängers.

Darf ich mehrere Bestellnummern zusammen in BT-13 schreiben?

Nehmen Sie keine automatische Verarbeitung einer Nummernliste an. Die UBL-Bestellreferenz auf Rechnungsebene ist im Peppol-Billing-Profil höchstens einmal vorgesehen. Vereinbaren Sie mit dem Empfänger einen unterstützten Weg oder getrennte Rechnungen.

Quellen und Aktualität

Primärquellen am 9. Oktober 2026 geprüft. Der Beitrag behandelt Referenzdaten und den Softwareexport, keine individuelle Rechts- oder Steuerberatung. Die Testfälle und XML-Werte sind erfundene redaktionelle Prüfhilfen, keine vollständigen validierten Rechnungen. MOCO-Angaben stammen aus Herstellerdokumentation, nicht aus einem eigenen Produkttest. Das generativ erstellte Titelbild zeigt fiktive Dokumente und keine echte Produktoberfläche.