E-Rechnungspflicht 2027: Was Ihre Symfony-Anwendung bis 31.12. können muss

In vielen Unternehmen entstehen Rechnungen nicht in der Buchhaltungssoftware, sondern in einer Individualanwendung: im Kundenportal, in der Abo-Verwaltung, im Buchungssystem oder in einer Plattform, die Leistungen nach Verbrauch abrechnet. Die Diskussion zur E-Rechnungspflicht dreht sich fast ausschließlich um ERP-Systeme und Buchhaltungsprogramme. Wer seine Rechnungen aus Symfony heraus erzeugt, findet dazu kaum Orientierung. Dieser Artikel ordnet ein, was Ihre Anwendung bis zum 31.12.2026 können muss und welche Wege dorthin realistisch sind.

Die Ausgangslage: Welche Frist für wen gilt

Der Empfang von E-Rechnungen ist im inländischen B2B-Geschäft bereits seit dem 01.01.2025 Pflicht. Jedes Unternehmen muss also strukturierte Rechnungen annehmen und verarbeiten können. Für die Ausstellung gelten gestaffelte Übergangsfristen.

Der Zentralverband des Deutschen Handwerks fordert, die Frist für 2027 auf den 01.01.2028 zu verschieben. Grundlage ist eine Umfrage unter knapp 2.000 Betrieben, von denen rund zwei Drittel bereits beim Empfang Schwierigkeiten melden. Das ist eine Forderung, kein Beschluss. Wer seine Planung darauf aufbaut, plant gegen die geltende Rechtslage.

Für die Technik entscheidend ist die Definition: Eine E-Rechnung ist ein strukturierter elektronischer Datensatz, der der europäischen Norm EN 16931 entspricht. Die gängigen Formate sind XRechnung als reines XML und ZUGFeRD ab Version 2.0.1 als hybrides PDF/A-3 mit eingebettetem XML. Ein PDF, das Ihre Anwendung heute per Twig und einer PDF-Bibliothek erzeugt, erfüllt diese Anforderung nicht, so sauber es auch aussieht.

Was Ihre Symfony-Anwendung können muss

Aus der Norm ergeben sich fünf technische Fähigkeiten. Nicht jede davon ist für jedes Projekt gleich aufwendig, aber keine lässt sich überspringen.

1. Ein vollständiges Rechnungsdatenmodell

EN 16931 verlangt Pflichtfelder, die in gewachsenen Anwendungen oft fehlen oder nur als Freitext existieren: strukturierte Adressen von Verkäufer und Käufer, Umsatzsteuer-Identifikationsnummern, Steuerkategorien pro Position, Einheitencodes nach UN/ECE, Zahlungsbedingungen und Bankverbindung als eigene Felder. Wenn Ihre Doctrine-Entities eine Rechnung heute als Kopfzeile mit HTML-Positionstext speichern, liegt hier der größte Teil der Arbeit.

2. Erzeugung von XRechnung oder ZUGFeRD

Für die Formaterzeugung gibt es im PHP-Umfeld etablierte Bibliotheken, etwa horstoeko/zugferd für ZUGFeRD und Factur-X sowie Bibliotheken für UBL-basierte XRechnung. Ob Sie ein reines XML oder ein hybrides PDF ausliefern, hängt von Ihren Kunden ab: Buchhaltungen mit automatisierter Verarbeitung bevorzugen oft XRechnung, viele mittelständische Empfänger kommen mit ZUGFeRD besser zurecht, weil sie das PDF weiterhin lesen können.

Das folgende Beispiel zeigt das Prinzip einer schmalen Kapselung. Die Bibliothek bleibt austauschbar, Ihre Anwendung kennt nur das eigene Interface.

interface EInvoiceGenerator
{
    /** Liefert den strukturierten Rechnungsdatensatz (XML oder PDF/A-3). */
    public function generate(Invoice $invoice): GeneratedDocument;
}

final class ZugferdGenerator implements EInvoiceGenerator
{
    public function generate(Invoice $invoice): GeneratedDocument
    {
        // Mapping der eigenen Entity auf das EN-16931-Modell der Bibliothek.
        // Fehlende Pflichtfelder fallen hier auf, nicht erst beim Empfänger.
    }
}

3. Validierung vor dem Versand

Eine Rechnung, die formal nicht der Norm entspricht, kann der Empfänger zurückweisen. Prüfen Sie deshalb jede erzeugte Datei gegen die offiziellen Validierungsregeln, bevor sie Ihre Anwendung verlässt. Der KoSIT-Validator lässt sich als Java-Prozess oder Container in die CI-Pipeline einbinden. So scheitert ein fehlerhaftes Mapping im Build und nicht erst beim Kunden.

4. Versand und Übergabe

Die meisten Unternehmen versenden E-Rechnungen schlicht per E-Mail mit Anhang. Das ist zulässig. Wer Rechnungen an Behörden stellt, braucht zusätzlich die Leitweg-ID des Empfängers und gegebenenfalls eine Anbindung an Peppol. Für die Übergabe an ein ERP oder eine Buchhaltung bietet sich der Symfony Messenger an, weil Rechnungserzeugung und Übermittlung dann entkoppelt laufen und fehlgeschlagene Übergaben wiederholt werden können. Das Outbox-Muster, das Symfony 8.2 im Messenger einführt, ist dafür interessant, befindet sich aber noch in Entwicklung.

5. GoBD-konforme Archivierung

Archiviert werden muss der strukturierte Datensatz, nicht nur eine PDF-Ansicht davon. Die Datei muss unveränderbar, auffindbar und über die gesetzliche Frist hinweg lesbar bleiben. Ein Ordner auf dem Webserver erfüllt das nicht. Hier lohnt der Blick auf ein revisionssicheres Archiv oder die Übergabe an ein System, das diese Anforderung bereits abdeckt.

Wie viel davon in Ihrem Projekt tatsächlich fehlt, entscheidet über den Aufwand. In manchen Anwendungen sind die Daten vollständig vorhanden und es fehlt nur die Ausgabe. In anderen steckt die eigentliche Arbeit im Datenmodell und in der Migration bestehender Kunden- und Artikeldaten.

Drei Wege zur E-Rechnung

Grundsätzlich gibt es drei Varianten, die sich in Aufwand, Abhängigkeit und Kontrolle unterscheiden.

Eigene Erzeugung in der Anwendung. Ihre Symfony-Anwendung erzeugt XRechnung oder ZUGFeRD selbst über eine Bibliothek. Sie behalten die volle Kontrolle und haben keine laufenden Kosten pro Rechnung. Dafür liegen Pflege, Validierung und Anpassung an künftige Normversionen bei Ihnen.

Übergabe an einen externen Dienst. Ihre Anwendung liefert die Rechnungsdaten per API an einen spezialisierten Anbieter, der Format, Validierung, Versand und oft auch die Archivierung übernimmt. Das verlagert die Formatpflege nach außen. Sie binden sich allerdings an einen Anbieter und dessen Datenmodell.

Rechnungsstellung ins ERP verlagern. Ihre Anwendung erzeugt keine Rechnungen mehr, sondern übergibt abrechenbare Vorgänge an die Buchhaltungssoftware, die bereits E-Rechnungen beherrscht. Das ist oft der sauberste Schnitt, setzt aber eine verlässliche Schnittstelle voraus und verändert interne Abläufe.

Entscheidungskriterien für Ihr Projekt

Welcher Weg passt, hängt weniger von der Technik ab als von Ihrer Situation. Die folgenden Fragen helfen bei der Einordnung.

1. Rechnungsvolumen: Bei wenigen hundert Rechnungen im Jahr rechnet sich ein externer Dienst schneller als bei mehreren zehntausend.
2. Vorhandenes ERP: Wenn Ihre Buchhaltung ohnehin ein System mit E-Rechnungsfunktion nutzt, prüfen Sie zuerst, ob die Übergabe dorthin genügt.
3. Datenqualität: Fehlen strukturierte Adressen oder Steuerkennzeichen, müssen Sie diese Lücke unabhängig vom gewählten Weg schließen.
4. Empfängerkreis: Stellen Sie Rechnungen an öffentliche Auftraggeber, kommen Leitweg-ID und gegebenenfalls Peppol hinzu.
5. Wartungskapazität: Eigene Erzeugung bedeutet, dass jemand die Bibliothek und die Validierungsregeln aktuell hält.

An dieser Stelle ein offenes Wort, auch wenn es nicht in meinem wirtschaftlichen Interesse liegt: Wenn Ihr Unternehmen bereits eine Buchhaltungssoftware mit E-Rechnungsfunktion nutzt und Ihre Anwendung nur eine überschaubare Zahl an Rechnungen erzeugt, ist die Übergabe an dieses System oft günstiger als jede Eigenentwicklung. Eine eigene Formaterzeugung lohnt sich vor allem dann, wenn die Rechnung eng mit der Fachlogik verwoben ist, etwa bei verbrauchsabhängiger Abrechnung oder komplexen Rabattmodellen.

Zeitlich ist Oktober kein komfortabler Startpunkt mehr. Zwischen Analyse, Datenmodellanpassung, Migration, Tests und dem ersten echten Rechnungslauf liegen mehrere Arbeitsschritte, die sich nicht beliebig parallelisieren lassen. Wer die 800.000-€-Grenze überschreitet, sollte die Analyse jetzt angehen und nicht erst nach dem Jahresabschluss.

Unabhängig vom Weg gilt: Die Datenbasis muss stimmen. Ein externer Dienst kann keine Umsatzsteuer-ID übermitteln, die Ihre Anwendung nie gespeichert hat.

Wer jetzt beginnt, sollte deshalb nicht mit der Bibliothek starten, sondern mit einem Export der vorhandenen Rechnungsdaten und einem ehrlichen Abgleich gegen die Pflichtfelder. Erst danach lässt sich seriös sagen, welcher der drei Wege für Ihr Projekt der richtige ist. Mehr zur Arbeit an bestehenden Anwendungen finden Sie auf meiner Seite als Symfony-Entwickler. Wenn die Rechnungsfunktion Teil einer älteren Codebasis ist, hilft auch der Artikel zu Legacy-PHP modernisieren bei der Einordnung.

Bei den Projekten, die ich gerade betreue, steht der Abgleich der Stammdaten in diesem Monat an erster Stelle. Die Formatfrage klären wir, sobald feststeht, wie viel Bereinigung nötig ist.

Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler und unterstützt Unternehmen und Agenturen im DACH-Raum bei der Weiterentwicklung bestehender Anwendungen.