F: Bau-Schlussrechnung mit Zwischensummen als ZUGFeRD/XRechnung erstellen

BG-22 BG-20 BG-21 BG-25 BG-27 BT-20 BT-106 BT-107
Thema
VB6
SDK-Mitglieder
AddTradeAllowanceCharge() AddTradePaymentTerms() AddTradeTax() CreateNewInvoice() Document_Type IsKosit Licensed Licensekey MergeXMLIntoPDF() SaveXML()
Business Terms
BG-22 Gesamtsummen auf Dokumentenebene BG-20 Abschläge auf Dokumentenebene BG-21 Zuschläge auf Dokumentenebene BG-25 Rechnungsposition BG-27 Abschläge auf Ebene der Rechnungsposition BT-20 Zahlungsbedingungen BT-106 Summe der Nettobeträge aller Rechnungspositionen BT-107 Summe der Abschläge auf Dokumentenebene
Codebeispiele
VB6 / VBScript (COM)
Veröffentlicht

Kurz: Eine ZUGFeRD- bzw. XRechnung ist eine strukturierte XML-Datei im PDF/A-3, kein gedrucktes Bild – deshalb erzeugt kein Drucker eine gültige E-Rechnung, und einen „Aloaha ZUGFeRD Printer (End-User Version)“ gibt es nicht. Und: Zwischensummen, wie man sie aus einer Excel- oder Bau-Schlussrechnung kennt, gibt es im Datenmodell der EN 16931 nicht. Jede Leistung steht als eigene Position in der Rechnung; die Summen (BG-22) ergeben sich aus den Positionen. Prozent-Positionen wie „3 % Nachlass“ bilden Sie als Abschlag/Zuschlag ab, Skonto gehört in die Zahlungsbedingung.

Gesucht wird das auch als: „Bau-Schlussrechnung ZUGFeRD“, „Excel-Rechnung als XRechnung“, „Zwischensumme in XRechnung“, „Teilsumme ZUGFeRD“, „Leistungsverzeichnis E-Rechnung“, „Nachlass in Prozent XRechnung“, „Baustelleneinrichtung Zuschlag“, „gibt es einen ZUGFeRD-Drucker“ oder „virtueller Drucker E-Rechnung“.

Erzeugt ein (virtueller) Drucker eine gültige E-Rechnung?

Nein. Ein PDF-Drucker erzeugt nur das sichtbare Blatt. Eine ZUGFeRD-/XRechnung braucht zusätzlich die maschinenlesbaren Rechnungsdaten als XML (Syntax CII nach EN 16931), eingebettet in ein PDF/A-3. Diese Daten entstehen aus Ihren Feldern – Verkäufer, Käufer, Positionen, Steuer, Summen –, nicht aus dem Druckbild. Einen Aloaha „ZUGFeRD Printer“ für Endkunden gibt es nicht. Drei Wege führen zur fertigen E-Rechnung:

  • Ohne Programmierung, manuell: die Aloaha ZUGFeRD GUI – Rechnung erfassen oder laden, als XML speichern und ins PDF/A einbetten.
  • Ohne Programmierung, aus Excel: die Rechnung als CSV exportieren und mit zugcmd umwandeln – siehe E-Rechnungen per CSV und zugcmd.
  • Programmgesteuert: mit dem Aloaha ZUGFeRD SDK direkt aus Ihrer Anwendung (Beispiel unten).

Zwischensummen gibt es in EN 16931 nicht

Das Datenmodell der E-Rechnung kennt nur Positionen (BG-25) und die Gesamtsummen der Rechnung (BG-22): Summe der Positionsnetto­beträge (BT-106), Abschläge (BT-107), Steuerbasis (BT-109), Steuer (BT-110) und Gesamtbetrag (BT-112). Eine Zwischensumme mitten in der Rechnung – etwa pro Titel oder Abschnitt eines Leistungsverzeichnisses – ist im XML nicht vorgesehen; der Empfänger rechnet alle Summen aus den Positionen selbst aus. Ein Validator (auch der KoSIT-Validator) lehnt eine Rechnung nicht ab, weil eine Zwischensumme fehlt – es gibt schlicht kein Feld dafür.

So gehen Sie damit um:

  • Zwischensummen sind reine Darstellung. Im lesbaren PDF (Ihre Word-Vorlage oder das Layout der GUI) dürfen Titel und Teilsummen natürlich erscheinen – sie betreffen nur die Optik, nicht das XML.
  • Abschnitte kennzeichnen: Wollen Sie Positionen gruppieren, können Sie jeder Position eine Positions-Notiz (BT-127) mit dem Titel geben (z. B. „Titel 1 – Balkonsanierung“).
  • Getrennte Rechnungen: Sollen Titel wirklich eigene Summen tragen, sind es fachlich eigene (Teil-/Abschlags-)Rechnungen – dann je Titel eine Rechnung.

Prozent-Positionen: Nachlass und Zuschlag

Zeilen wie „3 % Nachlass auf die Gesamtleistung“ oder „5 % Baustelleneinrichtung“ sind keine normale Position mit Menge und Einzelpreis. Zwei saubere Wege:

  • Als Abschlag/Zuschlag auf Dokumentebene (BG-20 Abschläge, BG-21 Zuschläge) mit Betrag und Prozentsatz samt Grundbetrag – Methode AddTradeAllowanceCharge. Details: Abschläge und Zuschläge mit Prozentsatz und Grundcode.
  • Als ausgerechneter Betrag: Sie rechnen den Prozentwert selbst aus und setzen ihn als festen Betrag (Positionsrabatt auf Positionsebene über BG-27).

Skonto

Skonto ist kein eigenes Datenfeld, sondern Teil der Zahlungsbedingung (BT-20). Das SDK erwartet dafür das feste Format #SKONTO#TAGE=14#PROZENT=2.00# (optional zusätzlich #BASISBETRAG=…#). So verstehen es die Prüfprogramme maschinell. Einzelheiten: Skonto in der XRechnung richtig angeben.

Beispiel: Schlussrechnung mit Nachlass und Skonto (Access/VBA)

Zwei Positionen (zusammen 300,00 € netto), 3 % Nachlass auf die Gesamtleistung und 2 % Skonto bei Zahlung innerhalb von 14 Tagen. Die Steuer wird auf den reduzierten Betrag (291,00 €) gerechnet.

Dim alo As Object
Set alo = CreateObject("Aloaha_ZUGFeRD.XML")

If alo.Licensed(LicenseKey) = False Then MsgBox "Nicht lizenziert": Exit Sub
alo.LicenseKey = LicenseKey
alo.ZUGFeRD_Profile = 1          ' comfort (EN 16931)
alo.ZUGfeRDStandard = 2          ' XRechnung
alo.isKOSIT = True

alo.CreateNewInvoice "RE-2026-0815", "Schlussrechnung Bauvorhaben Balkon", "20261105", "102", "", "", "EUR"
alo.Document_Type = 380

' --- Positionen (jede Leistung einzeln; KEINE Zwischensumme ins XML) ---
' PositionID, Note, SellerAssignedID, Menge, Einheit, Name, Beschreibung, Bruttopreis, Waehrung, ...,
'             Nettopreis, ..., TaxTypeCode, Kategorie, Steuersatz, ..., Gesamtbetrag, Waehrung, ...
alo.AddProduct_Comfort_2 "1", "", "", "1", "C62", "Balkonsanierung", "Titel 1 - Balkon", "", "EUR", _
     "", "", False, "", "", "", "100.00", "EUR", "", "", "vat", "s", "19.00", "", "100.00", "EUR", "", ""
alo.AddProduct_Comfort_2 "2", "", "", "1", "C62", "Gelaender", "Titel 2 - Gelaender", "", "EUR", _
     "", "", False, "", "", "", "200.00", "EUR", "", "", "vat", "s", "19.00", "", "200.00", "EUR", "", ""

' --- 3 % Nachlass auf die Gesamtleistung (BG-20, Dokumentebene) ---
' ChargeIndicator=False (Abschlag), Grundbetrag 300,00, Betrag 9,00, 19 % Kategorie S, Prozentsatz 3,00
alo.AddTradeAllowanceCharge False, "300.00", "EUR", "9.00", "EUR", "95", "S", "19.00", "Nachlass 3%", "3.00"

' --- Steuer auf die reduzierte Basis 291,00 ---
alo.AddTradeTax "55.29", "EUR", "291.00", "EUR", "VAT", "S", "19.00"

' --- Skonto in die Zahlungsbedingung (BT-20) ---
alo.AddTradePaymentTerms "#SKONTO#TAGE=14#PROZENT=2.00#", "20261119", "102"

' --- Summen (BG-22): Netto 300, Steuerbasis 291, Steuer 55,29, Abschlag 9, Brutto 346,29 ---
alo.WriteTotals "300.00", "346.29", "346.29", "291.00", "55.29", "9.00", "0.00", "0.00"

alo.SaveXML "C:\Rechnungen\RE-2026-0815.xml"
' danach optional ins PDF einbetten:
' alo.MergeXMLIntoPDF "C:\Rechnungen\RE-2026-0815.xml", "C:\Rechnungen\RE-2026-0815.pdf", "C:\Rechnungen\RE-2026-0815_zugferd.pdf", True, "", LicenseKey

Im lesbaren PDF dürfen über den Positionen weiterhin Titel und Zwischensummen stehen – das XML bleibt davon unberührt und enthält die einzelnen Positionen plus die Gesamtsummen.

Häufige Fragen

Kann ich Zwischensummen in die XRechnung schreiben?

Nein. EN 16931 hat kein Feld für Zwischensummen. Jede Leistung steht als eigene Position; der Empfänger rechnet die Summen aus den Positionen. Zwischensummen gehören allein ins lesbare PDF-Layout.

Erzeugt ein PDF-Drucker eine gültige ZUGFeRD-Rechnung?

Nein. Ein Drucker liefert nur das Druckbild. Eine gültige E-Rechnung braucht die strukturierten XML-Daten im PDF/A-3. Diese erstellen Sie mit der Aloaha ZUGFeRD GUI, über zugcmd aus CSV oder programmgesteuert mit dem SDK. Einen „Aloaha ZUGFeRD Printer“ gibt es nicht.

Wie bilde ich einen Prozent-Nachlass (z. B. 3 %) ab?

Als Abschlag auf Dokumentebene (BG-20) mit AddTradeAllowanceCharge – mit Grundbetrag, Betrag und Prozentsatz. Alternativ als ausgerechneter Festbetrag oder als Positionsrabatt (BG-27).

Muss ich dafür programmieren?

Nein. Ohne Programmierung erstellen Sie E-Rechnungen mit der Aloaha ZUGFeRD GUI oder, aus Excel heraus, per CSV-Export und zugcmd. Das SDK ist nur der Weg für die direkte Einbindung in eine eigene Anwendung.

Weiterführend

Business Terms in diesem Artikel: BG-22 BG-20 BG-21 BG-25 BG-27 BT-20 BT-106 BT-107 BT-109 BT-110 BT-112 BT-127