Die 5 häufigsten EN-16931-Fallstricke bei Handwerker-Rechnungen und woran man sie erkennt

Anfang 2026 hat der Zentralverband des Deutschen Handwerks 1.926 Betriebe gefragt, wie weit sie mit der E-Rechnung sind. Das Ergebnis war ernüchternd: 15 Monate nach dem Start der Empfangspflicht ist die E-Rechnung in vielen Handwerksbetrieben noch immer kein Thema. Hoher Aufwand bei der Einrichtung, technische Probleme, Mehrkosten. Und am 1. Januar 2028 endet die letzte Übergangsfrist. Dann muss jeder inländische B2B-Umsatz als strukturierte E-Rechnung nach EN 16931 laufen, ganz egal ob der Betrieb 800.000 Euro Vorjahresumsatz hatte oder 80.000.

Das Problem ist nicht der Wille. Das Problem ist, dass die Norm an einigen Stellen unangenehm rigide ist. Eine Rechnung kann steuerlich völlig korrekt sein, in Word sauber formatiert, vom Empfänger akzeptiert worden und trotzdem nach EN 16931 fehlerhaft. Wenn das passiert und der Empfänger seinen Validator scharf geschaltet hat, wird die Rechnung zurückgewiesen. Kein Skonto, kein Zahlungseingang, Diskussion mit der Buchhaltung des Kunden.

Wir bauen mit Belegschmiede einen Dienst, der genau diese Lücke schließt: Handwerker schreiben ihre Rechnungen weiter in Word oder ihrer Branchensoftware, wir wandeln die PDF in eine konforme ZUGFeRD-Rechnung um und prüfen sie vor dem Versand. Dabei sehen wir tausende echte Rechnungen aus dem Handwerk. Die folgenden fünf Fallstricke tauchen darin immer wieder auf. Vier davon sind reine Formatfragen, die in Word-Vorlagen praktisch unvermeidbar sind. Einer ist ein steuerlicher Sonderfall, der speziell Bauleistungs-Betriebe trifft.

Fallstrick 1: Skonto im Freitext statt strukturiert

Das ist der mit Abstand häufigste Fehler in unserer Validierung. Etwa 32% aller eingehenden PDFs die ein Skonto ausweisen haben den Skontohinweis im falschen Format.

Die EN-16931-Norm hat ursprünglich gar kein eigenes Feld für Skonto vorgesehen. Deutschland hat das Thema nachträglich über eine nationale CIUS-Regel reingeflickt. Skonto wird im Feld BT-20 (Payment terms) abgelegt, aber nicht als Fließtext, sondern in einem sehr starren Format. Die Regel heißt BR-DE-18.

So muss es aussehen:

#SKONTO#TAGE=14#PROZENT=2.50#

Klingt einfach. Ist es nicht. Großbuchstaben sind Pflicht. Die Prozentzahl braucht zwei Nachkommastellen, getrennt mit einem Punkt, ohne Prozentzeichen. Jeder Eintrag beginnt mit #, die Segmente sind durch # getrennt, am Ende steht ein #, dann ein Zeilenumbruch. Kein zusätzliches Leerzeichen, kein Tab, keine ausgeschriebene Erläuterung.

Was Handwerker in Word schreiben, klingt eher so:

Zahlbar binnen 14 Tagen mit 2 % Skonto, danach 30 Tage netto.

Steuerlich völlig in Ordnung. Aus EN-16931-Sicht: ungültig. Der KoSIT-Validator wirft BR-DE-18, die Rechnung wird beim Empfänger abgelehnt.

Wenn auf Teilbeträge skontiert wird, etwa weil nur das Material skontofähig ist, nicht aber die Arbeitsleistung, kommt noch ein viertes Segment dazu:

#SKONTO#TAGE=14#PROZENT=2.50#BASISBETRAG=485.98#

Das ist ein Fall, der im Handwerk häufig vorkommt und in den allermeisten Word-Vorlagen schlicht nicht abbildbar ist.

Fallstrick 2: Summen, die rechnerisch nicht aufgehen

Der zweithäufigste Fehler hat einen unschuldigen Namen: BR-CO-17. Die Regel besagt, dass die Nettosumme plus die Umsatzsteuersumme exakt den Bruttobetrag ergeben muss. Auch nicht durch Rundung darf da ein Cent Unterschied sein.

Klingt selbstverständlich. Ist es in Excel und Word nicht. Drei Positionen zu je 33,33 Euro netto sehen in der Anzeige sauber aus: 3 × 33,33 = 99,99. Intern hat Excel aber vielleicht mit 33,3333 gerechnet, die Summe ist 100,00, die ausgewiesenen 19% Umsatzsteuer ergeben einmal 18,9981, einmal 19,00. Beim Konvertieren in die strukturierte E-Rechnung schlägt der Validator zu, weil 99,99 + 19,00 nicht 119,00 ergibt.

Verwandt damit: BR-CO-10, die Summe der einzelnen Positionsbeträge muss dem Rechnungsbetrag entsprechen. Auch hier sind Rundungsdifferenzen tödlich.

In unserer Auswertung schlägt BR-CO-17 bei etwa 3% der konvertierten Word-Rechnungen an. Die Ursache ist fast immer dieselbe: Positionen werden auf zwei Stellen angezeigt, aber mit mehr Stellen gerechnet, oder Skonto-Beträge werden brutto abgezogen und netto neu aufgerechnet.

Praktischer Tipp, der auch ohne externe Software hilft: In Word oder Excel die Umsatzsteuer auf den gerundeten Positionssummen berechnen, nicht auf den ungerundeten Originalwerten. Und nie die Brutto-Werte aus angezeigten Netto-Werten rückrechnen, sondern immer netto multipliziert mit 1,19 (oder 1,07).

Fallstrick 3: Falscher Steuerkategorie-Code, besonders bei Bauleistungen

EN 16931 will für jede Position einen Code aus einer festen Liste wissen, der die umsatzsteuerliche Behandlung beschreibt. Die wichtigsten:

• S für Standardsteuersatz (19% oder 7%)
• Z für Nullsteuersatz
• E für Steuerbefreiung
• AE für Reverse Charge nach §13b UStG
• K für innergemeinschaftliche Lieferung
• G für Ausfuhrlieferung

Der Code-Fehler trifft Handwerker an genau zwei Stellen besonders hart.

Bauleistung an Bauunternehmer, der klassische §13b-Fall. Ein Dachdecker, der für einen Generalunternehmer arbeitet, stellt die Rechnung ohne Umsatzsteuer aus, der Empfänger schuldet die Steuer selbst. Was viele Word-Vorlagen machen: Sie setzen den Steuersatz auf 0% und Code S. Das ist falsch. Der korrekte Code ist AE. Ohne diesen Code erkennt das Empfänger-System nicht, dass es um Reverse Charge geht, der Vorsteuerabzug beim Empfänger funktioniert nicht sauber, und der Pflichthinweis "Steuerschuldnerschaft des Leistungsempfängers gemäß §13b UStG" muss zusätzlich im Feld BT-20 oder als Notiz vorhanden sein.

Kleinunternehmer nach §19 UStG, das zweite Minenfeld. Hier ist der korrekte Code E (steuerbefreit), nicht Z (Nullsteuersatz) und schon gar nicht S mit 0%. Wir sehen das oft bei Betrieben, die gerade frisch über die Kleinunternehmer-Grenze gewachsen sind oder umgekehrt: Stammdaten in der Branchensoftware sind nicht angepasst, die alte Vorlage wird weiter benutzt.

In unseren Validierungslogs ist der Code-Fehler nicht der häufigste, aber er ist der mit den größten Folgen. Bei Skonto-Format kann der Empfänger noch manuell korrigieren. Beim falschen Steuercode wird die Rechnung umsatzsteuerlich falsch verbucht, mit echten Konsequenzen in der Voranmeldung.

Fallstrick 4: Leistungszeitraum fehlt

Nach §14 UStG gehört das Lieferdatum oder der Leistungszeitraum auf jede Rechnung, wenn er vom Rechnungsdatum abweicht. In der EN 16931 heißen die Felder BT-72 (Lieferdatum) und BG-14 mit BT-73/BT-74 (Leistungszeitraum von/bis). Bei reinen Warenverkäufen ist das Lieferdatum oft identisch mit dem Rechnungsdatum, dann kann man das Feld weglassen. Im Handwerk ist das fast nie der Fall.

Ein Elektriker schließt am 12. März die Installation ab und schreibt am 28. März die Rechnung. Ein Heizungsbauer ist zwei Wochen auf einer Baustelle, vom 5. bis 19. Februar, und rechnet im März ab. In beiden Fällen muss der Leistungszeitraum in die strukturierte Rechnung. In Word-Vorlagen steht das oft nur als Fließtext am Ende ("Leistungszeitraum: 05.02. bis 19.02.2026"), oder gar nicht.

Beim Konvertieren ist das Pech: Wir können den Zeitraum aus einem freien Text durchaus extrahieren, aber wenn der ganze Hinweis fehlt, müssen wir entweder beim Handwerker nachfragen oder das Rechnungsdatum als Lieferdatum eintragen. Letzteres ist nicht immer korrekt und im Zweifelsfall sogar steuerlich problematisch.

In etwa 17% der eingehenden Rechnungen aus dem Handwerk fehlt der Leistungszeitraum komplett.

Fallstrick 5: USt-ID und Steuernummer

Die Regel BR-DE-13 verlangt: Bei bestimmten Steuercodes muss entweder die Umsatzsteuer-Identifikationsnummer (BT-31) oder die Steuernummer (BT-32) auf der Rechnung stehen, oder bei einem Steuervertreter dessen Daten in BG-11. Klingt trivial, ist es nicht.

Die typischen Fehler:

1. Beides fehlt. Bei kleinen Betrieben, die keine USt-ID haben, weil sie nie ins Ausland verkaufen, steht oft nur eine sehr alte Steuernummer in der Word-Vorlage. Wird die irgendwann ungültig (Finanzamtswechsel, Strukturreform), bemerkt das niemand, bis der Validator schreit.
2. Formatprobleme bei der USt-ID. Die deutsche USt-IdNr. muss ohne Leerzeichen geschrieben werden, also DE123456789, nicht DE 123 456 789. In Word-Templates wird das gerne mit Leerzeichen für die Optik aufgehübscht. Das ist auf dem Papier okay, im strukturierten Datensatz nicht.
3. Vermischung in einem Feld. Manche Betriebe schreiben beides in dasselbe Feld, getrennt durch Slash oder Komma. Im strukturierten Format gehören die in unterschiedliche BT-Felder.

Wo das besonders schmerzt: Bei Wechsel des Kleinunternehmer-Status. Wer als Kleinunternehmer keine USt-ID brauchte und jetzt regelbesteuert wird, vergisst gerne, die neue Umsatzsteuer-ID auch in die Rechnungsvorlage einzutragen. Sechs Monate später kommt die erste abgelehnte Rechnung.

Wenn die Validierung den Computer vor sich selbst schützt

Eine letzte Kategorie ist erwähnenswert, auch wenn sie streng genommen kein EN-16931-Fehler ist. Wenn aus einer PDF-Rechnung automatisch eine strukturierte Rechnung gebaut wird, passieren OCR-Fehler. Die häufigsten, die wir in unserer Pipeline sehen:

• Ziffer 1 und Kleinbuchstabe l werden in vielen Schriftarten praktisch identisch dargestellt. Eine IBAN, die DE89370400440532013100 heißen sollte, wird als DE89370400440532013l00 erkannt. Die IBAN-Prüfsumme nach ISO 13616 schlägt sofort an, aber nur, wenn überhaupt jemand prüft.
• Ziffer 0 und Großbuchstabe O.
• Ziffer 5 und Buchstabe S.

Solche Verwechslungen produzieren keine EN-16931-Fehler, aber eine Rechnung mit kaputter IBAN ist wirtschaftlich genauso ungültig wie eine, die der Validator ablehnt. Wir prüfen IBAN-Prüfsummen, deutsche Steuernummern-Formate und USt-ID-Prüfziffern deshalb zusätzlich zur reinen Schema-Validierung. Wie weit man mit LLM-basierter PDF-Extraktion bei echten Handwerker-Rechnungen kommt, ist ein Thema für sich. Dazu schreiben wir demnächst einen eigenen Artikel mit konkreten Genauigkeits-Messungen.

Was Betriebe konkret tun können

Wer heute schon prüfen will, ob die eigenen Rechnungen EN-16931-tauglich sind, kann den Belegschmiede Validator kostenlos verwenden.

Wer eine erste konvertierte E-Rechnung aus einer Word-Vorlage durch einen dieser Validatoren jagt, sieht meistens auf einen Blick, welche der oben genannten Fallstricke greifen. Die häufigste Reaktion in unseren Gesprächen mit Handwerksbetrieben: "Ach, das auch noch?"

Genau dafür haben wir Belegschmiede gebaut. Stammdaten wie USt-ID, Steuernummer, korrekte Steuerkategorie für den jeweiligen Kundentyp und Standard-Zahlungsbedingungen werden einmal hinterlegt und dann bei jeder ausgehenden Rechnung automatisch im richtigen Format eingesetzt. Die Validierung läuft vor dem Versand, nicht erst beim Empfänger. Der Handwerker schreibt seine Rechnung weiter so, wie er es kennt. Wir kümmern uns um die fünf Punkte oben, und um die paar anderen, die weniger oft, aber genauso teuer auftreten.

Bis zum 1. Januar 2028 sind es noch knapp 19 Monate. Wer die eigenen Vorlagen jetzt einmal durchgeht und die fünf Fallstricke entschärft, hat eine deutlich entspanntere zweite Jahreshälfte 2027.