Warum warnt der Validator vor einem leeren ApplicableHeaderTradeDelivery (PEPPOL-EN16931-R008)?

Kurz: Die Warnung PEPPOL-EN16931-R008 („Document MUST not contain empty elements“) beim Element bedeutet: Der Lieferblock ist vorhanden, aber leer. Der Block ist im Schema Pflicht und muss im XML stehen – leer ist er gültig, erzeugt aber diese Warnung. Sie verschwindet, sobald Sie auf Rechnungsebene eine Lieferanschrift ( BG-13 ) oder ein Liefer- bzw. Leistungsdatum ( BT-72 ) angeben. Warum der Block leer im XML steht In ZUGFeRD 2.x, Factur-X und XRechnung (CII) muss immer vorkommen. Fehlt er, lehnt der Validator die Rechnung mit einem Schemafehler ab (siehe „One of ApplicableHeaderTradeDelivery is expected“ ). Ab Version 11 schreibt das Aloaha ZUGFeRD SDK den Block deshalb immer – auch wenn keine Lieferangaben auf Rechnungsebene gemacht wurden. Dann steht im XML nur: Das ist schemakonform. Die Regel PEPPOL-EN16931-R008 meldet leere Elemente aber als Warnung. Die Rechnung bleibt gültig…

Leeres ApplicableHeaderTradeDelivery: Warnung R008 beheben

Thema: Fragen und Antworten
SDK-Mitglieder: ActualDeliveryDate_102 AddProduct_Comfort() WriteBillingPeriod() WriteShipFromTradeParty() WriteShipToTradeParty() WriteShipToTradePartyItem()
Business Terms: BG-13 Lieferinformationen BT-72 Tatsächliches Lieferdatum BT-70 Name des Waren- oder Dienstleistungsempfängers BT-75 Zeile 1 der Lieferanschrift BT-77 Stadt der Lieferanschrift BT-78 Postleitzahl der Lieferanschrift BT-80 Ländercode der Lieferanschrift BG-14 Rechnungszeitraum
Codebeispiele: XML, VB.NET
Veröffentlicht: 14. Oktober 2026

Kurz: Die Warnung PEPPOL-EN16931-R008 („Document MUST not contain empty elements“) beim Element ApplicableHeaderTradeDelivery bedeutet: Der Lieferblock ist vorhanden, aber leer. Der Block ist im Schema Pflicht und muss im XML stehen – leer ist er gültig, erzeugt aber diese Warnung. Sie verschwindet, sobald Sie auf Rechnungsebene eine Lieferanschrift (BG-13) oder ein Liefer- bzw. Leistungsdatum (BT-72) angeben.

Warum der Block leer im XML steht

In ZUGFeRD 2.x, Factur-X und XRechnung (CII) muss ram:ApplicableHeaderTradeDelivery immer vorkommen. Fehlt er, lehnt der Validator die Rechnung mit einem Schemafehler ab (siehe „One of ApplicableHeaderTradeDelivery is expected“). Ab Version 11 schreibt das Aloaha ZUGFeRD SDK den Block deshalb immer – auch wenn keine Lieferangaben auf Rechnungsebene gemacht wurden. Dann steht im XML nur:

<ram:ApplicableHeaderTradeDelivery />

Das ist schemakonform. Die Regel PEPPOL-EN16931-R008 meldet leere Elemente aber als Warnung. Die Rechnung bleibt gültig, die Warnung lässt sich jedoch leicht vermeiden.

Typischer Fall: Lieferscheine und Lieferdaten stehen nur in den Positionen, auf Rechnungsebene fehlt jede Lieferangabe.

Lösung: den Lieferblock füllen

1. Lieferanschrift angeben (BG-13) – etwa die Baustelle oder das Lager, an das geliefert wurde:

alo.WriteShipToTradeParty("Baustelle 4711", "12345", "Musterstadt", "Bahnhofstraße 1", "", "DE")   ' BT-70, BT-78, BT-77, BT-75, BT-80

2. oder ein Liefer- bzw. Leistungsdatum angeben (BT-72):

alo.ActualDeliveryDate_102 = "20261013"   ' Format JJJJMMTT

Eines von beiden genügt. Bei Sammelrechnungen über mehrere Baustellen siehe den Abschnitt Sammelrechnung unten. Ein Abrechnungszeitraum (BG-14, WriteBillingPeriod) steht dagegen im Abrechnungsblock und füllt den Lieferblock nicht.

Wir haben eine Rechnung mit leerem Lieferblock mit dem Mustang-Validator geprüft: gültig, eine Warnung PEPPOL-EN16931-R008. Mit Lieferanschrift auf Rechnungsebene: gültig, ohne Warnung (Stand 14.10.2026).

Wann ist was sinnvoll?

Warenlieferung an eine abweichende Adresse (Baustelle, Filiale, Lager): Lieferanschrift mit WriteShipToTradeParty. Mehr dazu unter Lieferanschrift in der E-Rechnung (BT-75 bis BT-80).
Lieferung oder Leistung an einem Tag: Leistungsdatum mit ActualDeliveryDate_102 – das ist nach § 14 UStG ohnehin eine Pflichtangabe, sofern nicht ein Abrechnungszeitraum angegeben ist.
Innergemeinschaftliche Lieferung (Kategorie K): Hier ist das Land der Lieferanschrift (BT-80) sogar Pflicht (Regel BR-IC-12).

Sammelrechnung mit mehreren Baustellen oder Lieferorten

Bei einer Sammelrechnung über einen Abrechnungszeitraum (BG-14) mit Lieferungen an verschiedene Baustellen passt weder eine einzelne Lieferanschrift noch ein einzelnes Lieferdatum auf Rechnungsebene. Erfundene Werte sind keine Lösung. Im Profil EXTENDED gibt es eine Angabe, die trotzdem immer stimmt: den Abgangsort (Ship From), also das eigene Werk oder Lager, von dem aus geliefert wird. Die Baustellen gehören dann als Lieferanschrift in die jeweilige Position:

alo.WriteBillingPeriod("20260811", "20260813", "102")                     ' BG-14 Abrechnungszeitraum
alo.WriteShipFromTradeParty("Schotterwerk Beispiel, Werk Musterort", "92353", "Musterort", "Werkstraße 3", "", "DE")   ' Abgangsort (EXTENDED)

Dim p As Integer = alo.AddProduct_Comfort(...)                            ' Position 1
alo.WriteShipToTradePartyItem(p.ToString(), "Baustelle 4711", "12345", "Musterstadt", "Bahnhofstraße 1", "", "DE")   ' Baustelle dieser Position
alo.AddDeliveryNoteItem(p, "708805", "20260811", "102", "")               ' Lieferschein dieser Position

Eine so aufgebaute Sammelrechnung (Abrechnungszeitraum, Abgangsort auf Rechnungsebene, je Position eigene Baustelle und eigener Lieferschein) hat der Mustang-Validator als gültig ohne Fehler und ohne Warnungen bewertet. Ohne den Abgangsort erscheint die Warnung PEPPOL-EN16931-R008.

Abgangsort, Lieferanschrift je Position und Lieferschein je Position (WriteShipFromTradeParty, WriteShipToTradePartyItem, AddDeliveryNoteItem) gibt es nur im Profil EXTENDED. In EN 16931 und XRechnung bleibt der Lieferblock einer reinen Sammelrechnung ohne Lieferangaben auf Rechnungsebene leer – die Warnung ist dann hinzunehmen, die Rechnung bleibt gültig.

Häufige Fragen

Was bedeutet PEPPOL-EN16931-R008?

Die Regel meldet leere Elemente im XML („Document MUST not contain empty elements“). Sie ist eine Warnung, kein Fehler – die Rechnung bleibt gültig.

Ist ein leeres ApplicableHeaderTradeDelivery ein Fehler?

Nein. Der Block ist im Schema Pflicht und darf leer sein. Fehlt er ganz, ist das ein Schemafehler. Leer erzeugt er nur die Warnung PEPPOL-EN16931-R008.

Wie fülle ich den Lieferblock mit dem Aloaha ZUGFeRD SDK?

Mit einer Lieferanschrift über WriteShipToTradeParty (BG-13) oder einem Leistungsdatum über ActualDeliveryDate_102 (BT-72). Eines von beiden genügt.

Reichen Lieferscheine in den Positionen?

Nein. Lieferscheine und Lieferdaten in den Positionen stehen im Lieferblock der Position, nicht im Lieferblock der Rechnung. Der Block auf Rechnungsebene bleibt dann leer.

Was trage ich bei einer Sammelrechnung über mehrere Baustellen ein?

Im Profil EXTENDED den Abgangsort (eigenes Werk oder Lager) auf Rechnungsebene mit WriteShipFromTradeParty und die Baustellen als Lieferanschrift der jeweiligen Position mit WriteShipToTradePartyItem. Der Abrechnungszeitraum bleibt bei WriteBillingPeriod.

Warum schreibt das SDK den Block auch ohne Inhalt?

Weil er im ZUGFeRD-, Factur-X- und XRechnung-Schema vorgeschrieben ist. Ohne ihn würde die Rechnung mit dem Schemafehler „One of ApplicableHeaderTradeDelivery is expected“ abgelehnt.

Business Terms in diesem Artikel: BG-13 BT-72 BT-70 BT-75 BT-77 BT-78 BT-80 BG-14 BT-73 BT-74