F: Leistungszeitraum oder Rechnungsdatum als 01.01.0001 – welches Datumsformat erwartet das SDK?

Thema

VB6

SDK-Mitglieder

Document_Date LastError Licensekey SaveXML() WriteBillingPeriod()

Business Terms

BT-2 Rechnungsdatum BT-73 Anfangsdatum des Rechnungszeitraums BT-74 Enddatum des Rechnungszeitraums BG-14 Rechnungszeitraum BT-9 Fälligkeitsdatum der Zahlung BT-72 Tatsächliches Lieferdatum BT-134 Anfangsdatum des Rechnungspositionszeitraums BT-135 Enddatum des Rechnungspositionszeitraums

Codebeispiele

XML, VB6 / VBScript (COM), VB.NET

Veröffentlicht

2. November 2026

Kurz: Das Aloaha ZUGFeRD SDK erwartet alle Datumswerte im Format 102, also JJJJMMTT (z. B. 20261020 für den 20.10.2026) – das Rechnungsdatum (BT-2, Invoice issue date), den Leistungs- bzw. Abrechnungszeitraum (BG-14 mit BT-73 Invoicing period start date und BT-74 Invoicing period end date, Methode WriteBillingPeriod), das Lieferdatum (BT-72) und das Fälligkeitsdatum (BT-9). Wer stattdessen 20.10.2026 übergibt – in Access typisch über Format(Datum, "dd.mm.yyyy") –, bekommt eine ungültige E-Rechnung, und in der Word-Vorlage erscheint 01.01.0001 statt des Datums. Die Lösung: in VBA Format(Datum, "yyyymmdd"), in VB.NET Datum.ToString("yyyyMMdd").

Gesucht wird das Problem auch als: „Leistungszeitraum wird falsch angezeigt“, „Rechnungsperiode 01.01.0001“, „Leistungsdatum fehlt in der PDF“, „Abrechnungszeitraum leer“, „billing period shows 01/01/0001“, „DateTimeString format 102 ungültig“ oder „Datumsformat ZUGFeRD XRechnung“.

Warum erscheint 01.01.0001?

Die Kennung 102 (Codeliste UNTDID 2379) bedeutet in ZUGFeRD, Factur-X und XRechnung immer: acht Ziffern, Jahr – Monat – Tag, ohne Punkte. Das SDK schreibt den übergebenen Text in das Element udt:DateTimeString. Mit 20.10.2026 entsteht dieses XML:

<ram:BillingSpecifiedPeriod>
  <ram:StartDateTime>
    <udt:DateTimeString format="102">20.10.2026</udt:DateTimeString>
  </ram:StartDateTime>
</ram:BillingSpecifiedPeriod>

Das verletzt das Schema; jeder Validator – auch der KoSIT-Validator für die XRechnung – lehnt die Rechnung ab. Beim Befüllen der Word-Vorlage liest das SDK das Datum als JJJJMMTT und gibt es als TT.MM.JJJJ aus; ein Wert wie 20.10.2026 lässt sich so nicht lesen, und der Platzhalter [BillingPeriodStart] zeigt das leere Datum 01.01.0001. Richtig ist:

<udt:DateTimeString format="102">20261020</udt:DateTimeString>

Auf einen Blick: alle Datumsangaben

Der Text der Zahlungsbedingung darf das Datum ganz normal als 16.11.2026 enthalten – nur die Datumsfelder selbst brauchen JJJJMMTT.

Access und VBA

Public Sub SetzeDaten(alo As Object)
    Dim Beginn As String, Ende As String

    ' BT-2 Rechnungsdatum
    alo.Document_Date = Format(Date, "yyyymmdd")

    ' BT-73 / BT-74 Leistungszeitraum: leere Felder abfangen
    If Not IsNull(Forms!Rechnung!Leistungsbeginn) Then
        Beginn = Format(Forms!Rechnung!Leistungsbeginn, "yyyymmdd")
    Else
        Beginn = Format(Forms!Rechnung!Auftragsdatum, "yyyymmdd")
    End If
    If Not IsNull(Forms!Rechnung!Leistungsende) Then
        Ende = Format(Forms!Rechnung!Leistungsende, "yyyymmdd")
    Else
        Ende = Format(Date, "yyyymmdd")
    End If
    Call alo.WriteBillingPeriod(Beginn, Ende, "102")

    Debug.Print "Leistungszeitraum: "; Beginn; " - "; Ende   ' im Direktfenster: 20261001 - 20261031
End Sub

Public Sub ERechnungErstellen()
    Dim alo As Object
    Set alo = CreateObject("Aloaha_ZUGFeRD.XML")
    alo.Licensekey = "IHR-LIZENZSCHLUESSEL"
    Call SetzeDaten(alo)
    ' ... Verkäufer, Käufer, Positionen, Summen
    If alo.SaveXML("C:\Rechnungen\RE-2026-0815.xml") = False Then MsgBox alo.LastError
End Sub

In VBA steht mm in Format für den Monat und nn für die Minuten – "yyyymmdd" ist also richtig.

VB.NET

Dim alo As New Aloaha_ZUGFeRD.XML(Aloaha_ZUGFeRD.iXML.ZUGFeRDProfile.comfort, False, "IHR-LIZENZSCHLUESSEL")
Dim Beginn As Date = New Date(2026, 10, 1)
Dim Ende As Date = New Date(2026, 10, 31)
alo.Document_Date = Date.Today.ToString("yyyyMMdd", Globalization.CultureInfo.InvariantCulture)
alo.WriteBillingPeriod(Beginn.ToString("yyyyMMdd", Globalization.CultureInfo.InvariantCulture), _
                       Ende.ToString("yyyyMMdd", Globalization.CultureInfo.InvariantCulture), "102")

In .NET heißt der Monat MM (groß); mm sind Minuten. ToString("yyyymmdd") liefert deshalb ein falsches Datum wie 20260001.

Typische Fehler

• Deutsches Format übergeben: Format(Datum, "dd.mm.yyyy"), CStr(Datum) oder eine Date-Variable direkt an den Text-Parameter – VBA wandelt ein Datum dann nach den Windows-Ländereinstellungen in 20.10.2026 um.
• Zweistelliges Jahr: Format(Datum, "dd.mm.yy") ergibt 02.11.26 – ebenfalls ungültig.
• mm statt MM in .NET: Minuten statt Monat (siehe oben).
• Kontrolle an der falschen Stelle: Eine MsgBox mit dem Formularfeld zeigt das Datum richtig an, obwohl der übergebene Wert falsch ist. Prüfen Sie die Variable, die Sie übergeben (Debug.Print), oder das erzeugte XML.
• Variable im Else-Zweig nicht gesetzt: Bleibt Ende leer, übernimmt das SDK keinen Zeitraum – BT-74 fehlt.
• Andere Formatkennung: Für Rechnungen gilt nur 102. Der Parameter DateFormat kann weggelassen werden; leer bedeutet ebenfalls 102.

Weitere Stolpersteine in Access – „Prozedur zu groß“, typografische Anführungszeichen, Null-Werte – zeigt Access oder VBA meldet „Prozedur zu groß“. Wie Rechnungsdatum und Zeitraum in der Word-Vorlage erscheinen, steht in der Platzhalter-Referenz; den Zeitraum einer einzelnen Position beschreibt Preis, Menge, Steuer und Zeitraum einer Position.

Business Terms in diesem Artikel: BT-2 BT-73 BT-74 BG-14 BT-9 BT-72 BT-134 BT-135