E-Rechnung ohne Rückläufer: Warum wir jede Rechnung prüfen lassen, bevor sie überhaupt entstehen darf

Eine Rechnung, die gut aussieht, ist noch keine gültige E-Rechnung

Seit Anfang 2025 muss jedes Unternehmen in Deutschland E-Rechnungen empfangen können, die Pflicht zum Ausstellen folgt schrittweise. Die meisten beschäftigen sich damit erst, wenn der erste Rückläufer kommt: Der Kunde, sein Steuerbüro oder dessen Software meldet, die Rechnung sei „formal fehlerhaft“ – obwohl das PDF auf dem Bildschirm tadellos aussieht.

Wir haben unsere eigene Rechnungsstellung auf das ZUGFeRD-Format umgestellt und uns dabei eine Regel gegeben: Geprüft wird nicht beim Empfänger, sondern bei uns – und zwar bevor die Rechnung überhaupt entstehen darf. Dieser Beitrag zeigt aus eigener Praxis, wie das aussieht und wo die Norm strenger ist als das Auge.

Die Herausforderung

Eine E-Rechnung im ZUGFeRD-Format – in Frankreich heißt dasselbe Format Factur-X – besteht aus zwei Teilen: einem PDF, das ein Mensch lesen kann, und einem darin eingebetteten Datensatz, den die Buchhaltungssoftware des Empfängers liest. Maßgeblich für die Verarbeitung ist der Datensatz. Daraus ergeben sich Fehlerquellen, die man einer Rechnung nicht ansieht:

• Zwei Teile, die dasselbe sagen müssen. Steht im sichtbaren PDF etwas anderes als im Datensatz, bemerkt das beim Durchlesen niemand. Der Empfänger bucht trotzdem, was im Datensatz steht.
• Eine Norm mit vielen Einzelregeln. Die europäische Norm EN 16931 legt fest, welche Angaben in welcher Kombination zulässig sind. Wer nur Inlandsrechnungen mit 19 % schreibt, stolpert selten. Sobald Steuerschuldumkehr, Drittland, Rabatte oder Gutschriften dazukommen, wird es eng.
• Fälle, die von Hand niemand testet. Die Standardrechnung probiert jeder aus. Die Teilgutschrift zu einer Rechnung aus dem Vorjahr eher nicht.
• Pflichtangaben, die leicht leer bleiben. Das Leistungsdatum zum Beispiel – dazu weiter unten mehr.
• Rechnungen lassen sich nicht reparieren. Eine abgeschlossene Rechnung ist unveränderlich und trägt eine fortlaufende Nummer. Ein Fehler, der erst danach auffällt, kostet eine Korrektur über eine Gutschrift.
• Die Gegenrichtung. Lieferanten schicken ihre Rechnungen inzwischen in drei Spielarten: als gewöhnliches PDF, als ZUGFeRD-PDF und als reine XRechnung, also eine Datei ganz ohne lesbares Bild.

Unsere Lösung

1. Die Prüfung läuft bei jedem Softwarestand mit

Für die Prüfung nach EN 16931 gibt es frei verfügbare Werkzeuge. Wir setzen den quelloffenen Validator des Mustang-Projekts ein. Entscheidend ist nicht das Werkzeug, sondern der Zeitpunkt: Die Prüfung ist Teil der automatischen Tests, die bei jeder Änderung an der Software laufen.

Dafür erzeugt die Software Musterbelege, die unsere tatsächlichen Fälle abdecken:

• Inland mit 19 % Umsatzsteuer
• EU-Ausland mit Steuerschuldumkehr (Reverse Charge)
• Drittland, in Deutschland nicht steuerbar
• gemischte Steuersätze mit Rabatten
• Empfänger mit Sonderzeichen im Namen
• Rechnung, die aus einem Angebot entstanden ist
• Teilgutschrift
• Storno

Jeder dieser acht Belege wird als fertiges PDF erzeugt und dem Validator vorgelegt. Fällt einer durch, schlägt der Test fehl, und der Softwarestand wird nicht ausgeliefert. Angebote laufen ebenfalls mit – für sie wird geprüft, dass sie gerade keinen Rechnungsdatensatz enthalten.

Ein Detail, auf das wir Wert gelegt haben: Fehlt der Validator in der Testumgebung, gilt der Test als fehlgeschlagen und wird nicht stillschweigend übersprungen. Eine Prüfung, die sich unbemerkt abschalten kann, schützt genau an dem Tag nicht, an dem man sie braucht.

2. Was nicht gültig wäre, lässt sich nicht abschließen

Die Tests sichern die Software ab, nicht die einzelne Rechnung. Deshalb gibt es eine zweite Stufe: Beim Abschließen einer Rechnung prüft die Software, ob aus diesem Beleg eine gültige E-Rechnung werden kann. Wenn nicht, wird der Abschluss verweigert, mit dem Grund in einem verständlichen Satz.

Wichtig ist die Reihenfolge. Die Ablehnung kommt, bevor eine Rechnungsnummer vergeben wird. Der Entwurf bleibt ein Entwurf, im Nummernkreis entsteht keine Lücke, und es muss nichts storniert werden.

Eine Rechnung, die die Prüfung nicht bestehen würde, bekommt bei uns gar nicht erst eine Nummer.

3. Wo die Norm strenger ist als das Auge: 0 % im Inland

Das beste Beispiel dafür stammt aus unserer eigenen Qualitätssicherung. Die erste Fassung ließ bei Inlandsrechnungen neben 19 % und 7 % auch eine Position mit 0 % zu. Auf dem PDF sieht das völlig unauffällig aus: eine Zeile, ein Betrag, null Euro Steuer.

Im Datensatz ist es ein Fehler. Eine Inlandsposition trägt dort die Steuerkategorie „Standardsatz“, und die Norm verlangt für diese Kategorie einen Steuersatz über null (Regel BR-S-05). Wer 0 % berechnen will, braucht eine andere Kategorie – und je nach Fall eine Begründung. Steuerbefreit, zum Nullsatz besteuert und Steuerschuldumkehr sind drei verschiedene Dinge und nicht austauschbar.

Im Review fiel auf, dass die Software eine solche Rechnung abgeschlossen hätte – als E-Rechnung, die beim Empfänger durchfällt und sich nachträglich nicht mehr reparieren lässt. Seither wird sie beim Abschluss abgelehnt.

Die Folgefrage kam gleich hinterher, und sie ist der Fall, den von Hand niemand getestet hätte: Was ist mit der Gutschrift zu einer älteren Rechnung aus dem Vorgängersystem, die eine solche Position enthält? Eine Gutschrift muss ihre Rechnung exakt spiegeln, also ließe sie sich ebenfalls nicht abschließen. Wir haben nicht geschätzt, sondern im eigenen Bestand nachgezählt: Keine einzige Inlandsrechnung enthält eine Position mit 0 %. Die Entscheidung fiel deshalb bewusst klein aus. Der Fall wird nicht unterstützt, ist dokumentiert, und ein eigener Test hält die Ablehnung samt Meldung fest.

4. PDF und Datensatz aus derselben Quelle

Dasselbe Review fand eine zweite Stelle, an der beide Teile der Rechnung auseinanderlaufen konnten. Bei einer Gutschrift nahm der Datensatz die Umsatzsteuer-Identnummern aus der ursprünglichen Rechnung, das sichtbare PDF dagegen den heutigen Stand der Stammdaten. Hätte sich die Nummer zwischen Rechnung und Gutschrift geändert, hätten Seite und Datensatz derselben Datei zwei verschiedene Nummern genannt.

Kein Validator findet so etwas, denn jede Hälfte für sich ist formal in Ordnung. Die Korrektur ist deshalb grundsätzlicher Art: PDF und Datensatz beziehen diese Angaben aus derselben Stelle im Programm. Ein Test ändert die Nummern nach dem Abschluss der Rechnung, erzeugt die Gutschrift und vergleicht den Text des PDFs mit dem Datensatz.

5. Das Leistungsdatum: ein Hinweis vom Kunden, eine Regel für alle

Nicht jeder Fehler kommt aus der Norm. Ein Kunde wies uns darauf hin, dass eine Rechnung von Anfang Oktober Arbeiten aus dem September abrechnete, ohne das zu sagen. Er hatte recht: Der Zeitpunkt der Leistung ist nach § 14 Abs. 4 Nr. 6 UStG eine Pflichtangabe jeder Rechnung. Als Angabe genügt der Kalendermonat (§ 31 Abs. 4 UStDV).

Die Felder dafür gab es. Sie blieben nur leer, weil niemand sie ausfüllen musste. Daraus sind drei Regeln entstanden:

• Der Leistungszeitraum wird automatisch übernommen. Unsere Rechnungsentwürfe entstehen aus den abgerechneten Arbeiten. Aus den Tagen, an denen die Zeiten gebucht wurden, ergibt sich der Kalendermonat – oder über mehrere Monate hinweg ein zusammenhängender Zeitraum. Maßgeblich ist, wann gearbeitet wurde, nicht wann ein Vorgang abgenommen oder geschlossen wurde.
• Ohne Leistungsdatum kein Abschluss. Eine Rechnung lässt sich nur abschließen, wenn ein Leistungszeitraum gesetzt ist oder ausdrücklich vermerkt wird, dass das Leistungsdatum dem Rechnungsdatum entspricht. Beides zugleich geht nicht.
• Gutschriften erben den Zeitraum ihrer Rechnung.

Auf dem PDF steht der Zeitraum als eine Zeile mit ausgeschriebenem Monat, im Datensatz in den dafür vorgesehenen Feldern. Dass beides übereinstimmt, ist wiederum ein Test.

6. Die Gegenrichtung: ein Postfach für Eingangsrechnungen

Wer E-Rechnungen verschickt, bekommt auch welche. Lieferantenrechnungen gehen bei uns an eine eigene E-Mail-Adresse, die die Software regelmäßig abruft. Jeder Anhang wird nach seiner Art behandelt:

• Gewöhnliches PDF: wird ins Dokumentenarchiv übernommen, die Beträge liest der bestehende Import aus.
• ZUGFeRD-PDF: wie ein PDF, aber mit den Beträgen aus dem Datensatz statt aus dem Bild.
• Reine XRechnung: bekommt ein lesbares PDF, das jede Angabe der Datei zeigt. Die Originaldatei wird unverändert darin eingebettet.

Kommt dieselbe Rechnung ein zweites Mal, wird sie erkannt und nicht doppelt abgelegt. Und eine Mail ohne brauchbaren Anhang verschwindet nicht: Sie wandert in einen eigenen Ordner und wird gemeldet. Gelöscht wird nichts.

Auch hier hat die Qualitätssicherung den entscheidenden Punkt gefunden. In der ersten Fassung konnte eine einzige Datei, die das Archiv schon beim Hochladen zurückwies – etwa ein zu großer Scan –, das gesamte Postfach blockieren: Die Verarbeitung blieb bei jedem Durchlauf an derselben Mail hängen, alle späteren Rechnungen blieben liegen. Jetzt gilt eine abgewiesene Datei als Problem dieser einen Mail. Sie wird zur Prüfung aussortiert und gemeldet, die übrigen laufen durch. Nur wenn das Archiv selbst nicht erreichbar ist, hält der Durchlauf an.

Das Ergebnis

• Jeder Softwarestand wird gegen die Norm geprüft – acht Musterbelege vom Inlandsfall bis zum Storno, bevor irgendetwas ausgeliefert wird.
• Keine Rechnung ohne gültigen Datensatz: Was die Prüfung nicht bestehen würde, lässt sich nicht abschließen und verbraucht keine Rechnungsnummer.
• PDF und Datensatz sagen dasselbe, weil beide aus derselben Quelle gespeist und gegeneinander getestet werden.
• Das Leistungsdatum fehlt nicht mehr: Es wird aus den abgerechneten Arbeiten übernommen und ist Voraussetzung für den Abschluss.
• Eingangsrechnungen landen von selbst am richtigen Platz – als PDF, ZUGFeRD oder XRechnung, ohne Dubletten und ohne stillschweigend verworfene Mails.

Die Grenzen gehören dazu: Eine Inlandsposition mit 0 % unterstützt unsere Rechnungsstellung bewusst nicht, und der Leistungszeitraum gilt für die ganze Rechnung, nicht je Position. Beides ist dokumentiert und wird ergänzt, sobald ein echter Fall es verlangt.

Fazit

Das Muster ist nicht auf unsere eigene Buchhaltung beschränkt. Es gilt überall dort, wo Software selbst Rechnungen erzeugt: im Shop, im Kundenportal, in der Fachanwendung. Die Formatfrage – ZUGFeRD oder XRechnung – ist dabei der kleinere Teil. Den Unterschied macht, wo die Prüfung sitzt.

Eine E-Rechnung ist erst dann fertig, wenn eine Maschine sie gelesen hat. Wer diese Maschine in die eigene Entwicklung holt und eine Rechnung, die sie nicht besteht, gar nicht erst entstehen lässt, erfährt von Formfehlern vor dem Versand – und nicht durch den Rückläufer vom Kunden.