Kurz gesagt

  • E-Rechnungen empfangen müssen Unternehmen seit 2025. Ausstellen müssen sie sie ab 2027 bei mehr als 800.000 Euro Vorjahresumsatz, ab 2028 alle.
  • Das alte System rechnet weiter wie bisher. Ein separater Dienst prüft die Werte und bettet die E-Rechnung in das gewohnte PDF ein.
  • Der Dienst korrigiert nichts. Passt ein Betrag nicht auf den Cent, wird die Rechnung abgelehnt, bevor sie jemand bucht.
  • Die Brücke verschafft Zeit. Das Altsystem ersetzt sie nicht.

Die Ausgangslage

Der Kunde ist ein Dienstleister mit zwei Firmen, die beide über dieselbe Anwendung Angebote, Projekte und Rechnungen führen. Die Anwendung ist über viele Jahre gewachsen, in PHP geschrieben und läuft im internen Netz auf einem Server, dessen Betriebssystem und PHP-Version seit Jahren keine Sicherheitsupdates mehr erhalten. Eine Nachfolgeversion ist in Arbeit, die E-Rechnung ist dort eingeplant. Bis sie fertig ist, vergeht aber noch Zeit.

Wer auf die neue Software wartet, wettet darauf, dass sie vor der Pflicht fertig wird. Wer die alte Anwendung um eine vollständige E-Rechnung erweitert, baut Aufwand in ein System, das bald abgelöst wird. Und auf der alten PHP-Version laufen aktuelle ZUGFeRD-Bibliotheken ohnehin nicht. Deshalb haben wir einen dritten Weg gewählt.

Die Aufteilung: Wer rechnet, wer prüft

Eine ZUGFeRD-Rechnung ist ein normales PDF, in das die Rechnungsdaten zusätzlich als XML eingebettet sind. Empfänger ohne E-Rechnungssoftware sehen die gewohnte Rechnung, Buchhaltungssysteme lesen die Daten maschinell. Wir erzeugen das Profil EN 16931, das die Finanzverwaltung als E-Rechnung anerkennt. Die einfachen Profile MINIMUM und BASIC-WL zählen ausdrücklich nicht.

Die Arbeit ist klar verteilt:

  • Das Altsystem berechnet die Rechnung wie bisher, erstellt das PDF und übergibt alle Werte vollständig: Positionen, Rabatte und Aufschläge, Steuersätze, Summen, Zahlungsbedingungen.
  • Der E-Rechnungsdienst läuft auf einem eigenen, aktuellen Server. Er prüft jeden Wert, bildet daraus die XML-Daten nach EN 16931, prüft sie gegen das offizielle Schema und das Regelwerk und bettet sie in das PDF ein.

Der Dienst rechnet nichts nach und liest nichts aus dem PDF. Liegt die Rechnungslogik an zwei Stellen, rechnen früher oder später zwei Systeme unterschiedlich, und niemand weiß, welche Rechnung stimmt. Hier gibt es genau eine Quelle: das Altsystem. Der Dienst prüft nur, ob deren Angaben in sich stimmig sind.

Derselbe Dienst arbeitet bereits für eine zweite, ganz andere Fakturierung. Er kennt kein bestimmtes Quellsystem, sondern eine dokumentierte Schnittstelle. Wird das Altsystem abgelöst, kann die neue Software ihn weiter nutzen oder die E-Rechnung selbst erzeugen. Beides geht ohne Datenumzug.

Abgelehnt statt repariert

Der Dienst gleicht jede Rechnung auf den Cent ab: Menge mal Preis plus Aufschläge minus Rabatte ergibt den Positionsbetrag, die Positionen ergeben die Nettosumme, die Steueraufteilung ergibt die Steuer, und am Ende muss der Zahlbetrag stimmen. Weicht etwas ab, gibt es keine stille Korrektur, sondern eine Ablehnung mit der genauen Regel, die verletzt ist.

Dabei zeigten sich die Eigenheiten, die jedes gewachsene System hat:

  • Aufschläge und Rabatte je Position waren in der Anwendung anders abgebildet als in der E-Rechnung und mussten einzeln zugeordnet werden.
  • Abschlagsrechnungen über einen Prozentsatz des Auftrags brauchten eine eigene Abbildung.
  • Einzelpreise mit mehr als zwei Nachkommastellen führten bei der Summe zu Cent-Differenzen. Erst als der Dienst bis zu sechs Nachkommastellen beim Einzelpreis annahm, ging die Rechnung exakt auf.
  • Freie Mengeneinheiten wie „Std.“ oder „Pauschale“ mussten auf die genormten Einheiten-Codes der E-Rechnung abgebildet werden.
  • Rechnungen mit Reverse Charge, bei denen der Kunde die Umsatzsteuer schuldet, verlangen die Umsatzsteuer-Identifikationsnummer des Kunden. Sie stand in der Anwendung in einem Feld für Kundenreferenzen. Das Regelwerk hat die fehlende Angabe erkannt, bevor eine solche Rechnung hinausging.

Jeder dieser Punkte wäre bei einem Dienst, der fehlende Werte „sinnvoll ergänzt“, unbemerkt geblieben. Eine E-Rechnung, die nicht zum PDF passt, fällt erst beim Empfänger oder in der Betriebsprüfung auf.

Vorsichtig eingeführt

Ein System ohne Herstellerunterstützung verändert man in kleinen, umkehrbaren Schritten:

  1. Erst unter Versionskontrolle: Der Programmcode auf dem Server lag nicht in einer Versionsverwaltung. Wir haben den Ist-Stand zuerst festgehalten, damit jede Änderung nachvollziehbar und umkehrbar ist.
  2. Wenige, geprüfte Eingriffe: Die Änderungen am Altsystem beschränken sich auf wenige Stellen in Rechnungsformular und PDF-Erstellung. Sie liegen als Änderungssatz vor, der vor dem Einspielen gegen eine Prüfsumme des Ausgangsstands geprüft wird.
  3. Getestet auf der alten PHP-Version: Über 120 automatische Prüfungen laufen auf genau der PHP-Version des Servers, nicht nur auf einer aktuellen Entwicklungsumgebung.
  4. Je Firma einschaltbar: Die E-Rechnung wird für jede der beiden Firmen getrennt ab einer festgelegten Rechnungsnummer aktiviert. Ausgeschaltet läuft der alte Rechnungsweg unverändert weiter.
  5. Vorschau vor der Buchung: Vor dem endgültigen Buchen zeigt eine E-Rechnungs-Vorschau, ob die Prüfung bestanden ist. Erst dann wird gebucht und die Rechnung versendet.
  6. Rückweg bereit: Vor der Installation wurde der Ausgangsstand gesichert; der Weg zurück ist dokumentiert.

Inzwischen gehen die Rechnungen beider Firmen im Echtbetrieb als ZUGFeRD-Rechnung hinaus, aus dem gewohnten Formular heraus.

Was die Brücke nicht löst

Das Altsystem bleibt ein Altsystem. Ein Server ohne Sicherheitsupdates wird mit jedem Monat angreifbarer, daran ändert die E-Rechnung nichts. Bis zur Ablösung gilt deshalb: Die Anwendung ist nur im internen Netz erreichbar, und der E-Rechnungsdienst nimmt Anfragen nur vom Rechnungsserver und aus dem Wartungszugang an. Die Ablösung bleibt die Priorität. Die Brücke sorgt nur dafür, dass sie nicht unter dem Druck einer gesetzlichen Frist überstürzt werden muss.

Auch der Empfang ist ein eigenes Thema. Seit 2025 müssen Unternehmen E-Rechnungen annehmen und lesbar archivieren können, unabhängig davon, womit sie ihre eigenen Rechnungen schreiben.

Was Sie prüfen sollten

  • Lag Ihr Umsatz im Vorjahr über 800.000 Euro? Dann müssen Sie ab dem 1. Januar 2027 E-Rechnungen ausstellen.
  • Erzeugt Ihr System heute schon ZUGFeRD oder XRechnung, und in welchem Profil? MINIMUM und BASIC-WL reichen nicht.
  • Sind Rabatte, Aufschläge, Abschlagsrechnungen, Gutschriften und Rechnungen mit Reverse Charge abgedeckt, nicht nur die einfache Rechnung?
  • Wird eine E-Rechnung vor dem Versand geprüft, oder merkt das erst der Empfänger?
  • Ist die neue Software sicher vor Ihrer Frist fertig, oder brauchen Sie eine Brücke?

Wenn eine dieser Fragen offen ist, sehen wir uns Ihre Fakturierung gerne an. Schnittstellen und E-Rechnung ›