E-Rechnung im Gerüstbau: Warum Standardsoftware an der Vorhaltung scheitert

Kurz gesagt: Für die meisten Betriebe ist die E-Rechnung eine Formalie – Update einspielen, ZUGFeRD-Haken setzen, fertig. Für den Gerüstbau nicht. Nicht weil das Format schwieriger wäre, sondern weil eine Gerüstrechnung etwas abbildet, das im Kopf der meisten Rechnungsprogramme nicht vorkommt: eine Leistung, die über Wochen weiterläuft, während schon abgerechnet wird.

Vier Stellen klemmen in der Praxis. Drei davon kosten Geld, eine davon lässt die Rechnung schlicht abprallen.

---

Ab wann gilt die Pflicht für wen?

Die E-Rechnungspflicht kommt aus dem Wachstumschancengesetz und gilt für inländische B2B-Umsätze. Sie greift gestaffelt:

Für einen typischen Gerüstbaubetrieb heißt das: Liegt Ihr Jahresumsatz über 800.000 €, ist der 1. Januar 2027 Ihr Stichtag – also die kommende Saison.

Wichtig dabei: Ein PDF im Anhang ist keine E-Rechnung. Gefordert ist ein strukturierter Datensatz nach EN 16931 – in der Praxis XRechnung (reines XML, Pflicht gegenüber öffentlichen Auftraggebern) oder ZUGFeRD ab Profil EN 16931/Comfort (PDF mit eingebettetem XML, im B2B-Alltag meist die bessere Wahl, weil der Empfänger weiterhin eine lesbare Seite sieht).

Und weil Kommunen, Landesbauämter und Wohnungsbaugesellschaften die XRechnung schon länger verlangen, ist das Thema für viele Gerüstbauer ohnehin keine Zukunftsfrage mehr.

---

1. Vorhaltung: m²·Woche ist eine echte Einheit, kein Text

Ein Gerüstbauer rechnet Vorhaltung in m²·Woche ab. 500 m² Gerüst, vier Wochen, 0,45 € – das sind 2.000 m²·Wochen.

In einer normalen Rechnungssoftware landet diese Einheit als Freitext im Feld „Einheit". Auf dem Papier sieht das gut aus. In der E-Rechnung ist es ein Problem: Das Feld BT-130 (Mengeneinheit) ist kein Freitext, sondern ein Code aus einer amtlichen Liste – UN/ECE Empfehlung 20. Wer dort „m²Wo" hineinschreibt, produziert eine Rechnung, die der Prüfdienst des Empfängers ablehnt.

Die gute Nachricht: Die Einheit existiert. In Rec 20 Revision 17, gegen die der offizielle KoSIT-Validator prüft, stehen genau die Codes, die der Gerüstbau braucht:

Die verbreitete Notlösung – die Vorhaltung im XML „aufzulösen" und statt 2.000 MKW schlicht 500 m² zu schreiben – ist keine gute Idee. § 14 Abs. 4 Nr. 5 UStG verlangt Menge und Art der Leistung. Wenn die lesbare PDF-Seite 2.000 m²·Wochen nennt und der maschinenlesbare Datensatz 500 m², nennen zwei Teile derselben Rechnung zwei verschiedene Mengen. Vermeidbar: Die Einheit gibt es, also benutzt man sie.

---

2. Angefangene Wochen: der Fehler, der zweimal kassiert

Der praktisch teuerste Fehler steckt nicht im Format, sondern in der Zeitrechnung.

DIN 18451 rechnet Vorhaltung in angefangenen Wochen. Eine „Woche" ist dabei ein Zeitraum von sieben Tagen ab Beginn der Gebrauchsüberlassung – keine Kalenderwoche. Und der entscheidende Punkt: Dieser Rhythmus läuft durch. Er startet nicht bei jeder Rechnung neu.

Ein Beispiel, das jeder mit seiner aktuellen Software nachrechnen kann:

Gerüst gestellt am 2. März. Abgerechnet wird zum 29. März, 30. April und 31. Mai.

Rechnet man jeden Abrechnungszeitraum für sich, kommt man auf 4 + 5 + 5 = 14 Wochen. Richtig sind 13. Der Unterschied: Eine Woche, die über eine Rechnungsgrenze läuft, wird in der falschen Rechenweise zweimal berechnet – einmal am Ende der ersten Rechnung, einmal am Anfang der zweiten.

Bei drei Rechnungen ist das eine Woche zu viel. Bei einem Jahresprojekt mit monatlicher Vorhaltungsrechnung sind es elf. Das fällt entweder dem Auftraggeber auf – unangenehm – oder niemandem, was ein anderes Problem ist.

Die Lösung ist konzeptionell einfach und in Software erstaunlich selten umgesetzt: Die Rechnung braucht ein Feld für den Beginn der Gebrauchsüberlassung, das über die gesamte Rechnungskette hinweg festgehalten wird. Die Wochen eines Zeitraums ergeben sich dann als Differenz – angefangene Wochen bis zum Ende, minus angefangene Wochen bis zum Vortag des Beginns.

---

3. Abschlagsrechnungen: brutto abziehen kostet die Steuer zweimal

Gerüstbau läuft über Monate, also wird nach VOB/B § 16 in Abschlägen abgerechnet. Am Ende steht die Schlussrechnung, die den gesamten Leistungsstand ausweist und die bereits gestellten Abschläge abzieht.

Genau dieser Abzug ist eine umsatzsteuerliche Falle. § 14 Abs. 5 S. 2 UStG verlangt, dass in der Schlussrechnung die bereits berechneten Teilentgelte und die darauf entfallenden Steuerbeträge getrennt abgesetzt werden (siehe auch UStAE 14.8 Abs. 7–10).

Falsch:

abzgl. bereits erhaltene Abschlagszahlungen        – 35.700,00 €

Richtig:

abzgl. bereits gestellte Abschlagsrechnungen netto  – 30.000,00 €
darauf entfallende Umsatzsteuer 19 %                –  5.700,00 €

Wer nur brutto abzieht, weist rechnerisch mehr Steuer aus, als er schuldet – und schuldet den Mehrbetrag nach § 14c Abs. 1 UStG zusätzlich, bis die Rechnung berichtigt ist.

Zwei Details, die dabei gern untergehen: Die Formulierung lautet „gestellte", nicht „erhaltene" – abgezogen wird, was in Rechnung gestellt wurde, nicht was bezahlt wurde. Und im XML gibt es für diese Aufteilung kein eigenes Feld; EN 16931 kennt nur den Gesamtabzug (BT-113). Der Steueranteil gehört deshalb zusätzlich als Hinweistext ins Dokument.

---

4. Skonto: eine Zeichenkette, an der die Rechnung scheitert

Kleines Format-Detail mit großer Wirkung. Wer eine XRechnung verschickt und Skonto gewährt, muss die Vereinbarung in einer exakt vorgeschriebenen Syntax übermitteln (Regel BR-DE-18):

#SKONTO#TAGE=14#PROZENT=2.00#

Großbuchstaben. Punkt als Dezimaltrennzeichen. Genau zwei Nachkommastellen. Eigene Zeile. Ein „2,0 %" statt „2.00" ist kein Schönheitsfehler, sondern ein fataler Validierungsfehler – die Rechnung wird abgewiesen, nicht mit Hinweis durchgewunken. Daneben darf Freitext stehen, aber keine Zeile darf versehentlich mit # beginnen.

---

Was daraus für die Praxis folgt

E-Rechnung im Gerüstbau ist kein Formatproblem, sondern ein Fachproblem. Die vier Punkte oben haben eines gemeinsam: Man merkt den Fehler nicht beim Schreiben der Rechnung, sondern Wochen später – beim Prüfdienst des Auftraggebers, in der Betriebsprüfung oder gar nicht.

Der einzige verlässliche Weg ist, jede Rechnung vor dem Festschreiben maschinell gegen die amtlichen Prüfregeln laufen zu lassen – mit denselben Werkzeugen, die auch der Empfänger einsetzt (KoSIT-Validator für XRechnung, Mustang/Schematron für ZUGFeRD). Nicht „sieht gut aus", sondern grün oder rot.

Drei Fragen an Ihre Software:

1. Kennt sie MKW als Mengeneinheit – oder schreibt sie „m²Wo" als Text?
2. Zählt sie angefangene Wochen ab Gerüststellung durch – oder je Rechnung neu?
3. Trennt sie beim Abschlagsabzug Entgelt und Umsatzsteuer?

Dreimal Ja, und die E-Rechnung ist eine Formalie. Einmal Nein, und sie ist ein Risiko.

---

So löst BauByte das

Aus dem Angebot entsteht per Assistent die Teil-, Vorhaltungs-, Abschlags- oder Schlussrechnung – mit durchlaufendem Wochenrhythmus, korrekter Abschlagskette und getrenntem Steuerabzug.

Vor der Vergabe der Rechnungsnummer läuft ein Probelauf gegen den echten Validator. Erst wenn der grün ist, wird die Nummer gezogen, das PDF/A-3 mit eingebettetem XML erzeugt und revisionssicher archiviert. Rechnungsnummern bleiben lückenlos, festgeschriebene Rechnungen unveränderlich, Stornos laufen als Rechnungskorrektur – wie es § 14 UStG und die GoBD verlangen.

---

Quellen und Rechtsstand:

1. Wachstumschancengesetz vom 27.03.2024; § 14 UStG, insbesondere Abs. 4 Nr. 5 und Abs. 5 S. 2; § 14c Abs. 1 UStG
2. BMF-Schreiben zur E-Rechnung; UStAE 14.8 Abs. 7–10
3. EN 16931; XRechnung-Standard der KoSIT, Geschäftsregel BR-DE-18; ZUGFeRD ab Profil EN 16931/Comfort
4. UN/ECE Recommendation 20, Revision 17 – Codes MKW, MRW, HWE
5. ATV DIN 18451 (Gerüstarbeiten), Abrechnung in angefangenen Wochen; VOB/B § 16

Hinweis: Dieser Beitrag gibt die Rechtslage in allgemeiner Form wieder und ersetzt keine Steuer- oder Rechtsberatung. Lassen Sie Ihre Rechnungsvorlagen einmalig fachlich prüfen.