PHP-Entwickler in Stuttgart

#PHP-Entwickler in Stuttgart: E-Rechnung aus Ihrer Anwendung

Diese Seite zeigt, wie eine PHP-Anwendung eine E-Rechnung erzeugt, vor dem Versand prüft und so ablegt, dass die Aufbewahrung hält. Das Rechtliche kommt aus den Quellen von Bundesfinanzministerium und Gesetzgeber, die Technik aus den Repositories der Bibliotheken. Ich bin Mariusz Szatkowski, ein einzelner PHP-Entwickler in Gdynia, und arbeite ausschließlich remote und schriftlich. Steuerliche Beratung leiste ich nicht, die klärt Ihre Steuerberatung.

Zwei Nachbarthemen habe ich ausgelagert: Das österreichische ebInterface und Peppol behandelt PHP-Entwickler Wien, den DATEV-Export PHP-Entwickler Nürnberg.

#Was für Ihre Anwendung gilt, Stand November 2026

Die FAQ des Bundesfinanzministeriums trägt den Stand 29.10.2026. Danach gilt:

Die Rechtsgrundlage der Übergangsregeln steht in § 27 Abs. 38 UStG, die Definition in § 14 Abs. 1 UStG: Eine elektronische Rechnung wird in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen und ermöglicht die elektronische Verarbeitung.

Für den Code ist ein Detail wichtiger als die Jahreszahlen. Die Fristen in § 27 Abs. 38 knüpfen an den Tag des ausgeführten Umsatzes an, nicht an das Rechnungsdatum. Eine Rechnung vom Januar 2027 über eine Leistung vom Dezember 2026 fällt noch unter die erste Frist. Ihre Rechnungstabelle braucht also das Leistungsdatum als eigenes Feld und eine Regel, die daraus ableitet, ob für diesen Beleg ein strukturiertes Format erzwungen wird.

#Format- und Geschäftsregelfehler: warum die Prüfung zählt

Das BMF-Schreiben vom 15. Oktober 2025 trennt zwei Fehlerarten. Ein Formatfehler liegt vor, wenn die Datei nicht den zulässigen Syntaxen entspricht. Dann ist sie umsatzsteuerlich eine sonstige Rechnung und keine E-Rechnung, egal welcher Art der Fehler ist. Ein Geschäftsregelfehler liegt vor, wenn die Angaben unvollständig sind oder einander widersprechen. Das Schreiben nennt als Beispiele die fehlende “BT-10 Buyer reference” in einer XRechnung und einen Steuerbetrag, der nicht zum Steuersatz passt.

Das ergänzende BMF-Schreiben vom 15. Oktober 2026 hält die Abgrenzung in den Randnummern 22 und 23 fest:

• Umsatzsteuerlich führt ein Geschäftsregelfehler nur dann zu einem Inhaltsfehler, wenn er eine Pflichtangabe nach §§ 14, 14a UStG betrifft.
• Technisch genügt schon ein Verstoß gegen eine Geschäftsregel des Kerndatenmodells, damit die Datei nicht mehr der Normenreihe EN 16931 entspricht.
• Maßgeblich für Fragen wie den Vorsteuerabzug ist die umsatzsteuerliche Sicht.

Die Praxisfolge steht im Schreiben von 2025 (Randnummer 35a): Ein Unternehmer darf sich bei Beachtung der Sorgfaltspflichten auf das Ergebnis einer geeigneten Validierungsanwendung verlassen, und zum Nachweis bietet es sich an, den Validierungsbericht aufzubewahren. Eine Validierung ersetzt aber nicht die Prüfung des Empfängers auf Vollständigkeit und Richtigkeit. Ein falscher Steuersatz fällt durch keine Schematron-Regel, wenn er in sich stimmig berechnet ist.

Das BMF empfiehlt in den FAQ, die Validierung schon bei Erstellung und Versand durchzuführen, nennt aber keine bestimmte Anwendung. Eine Pflicht ist sie nicht. Für eine Anwendung, die Rechnungen automatisch verschickt, ist sie trotzdem der günstigste Ort, einen Fehler zu finden: bevor der Kunde ihn findet.

#Rechnung erzeugen: horstoeko/zugferd und sein Nachfolger

Die verbreitete PHP-Bibliothek ist horstoeko/zugferd (MIT-Lizenz). Laut README liest und schreibt sie XML in den Profilen Minimum, Basic, EN16931, Extended und XRechnung 1 bis 3, kann das XML an ein bestehendes PDF anhängen und unterstützt ausschließlich die CII-Syntax, nicht UBL. Auf Packagist steht Version 1.0.135 vom 8. November 2026, sie verlangt PHP ab 7.3.

Das README weist darauf hin, dass der Autor horstoeko/invoicesuite zum offiziellen Nachfolger erklärt hat und für neue Projekte empfiehlt. Das Repository nennt ZUGFeRD, Factur-X und XRechnung in CII und UBL. Die jüngste Version trägt die Nummer 0.0.41 (10. November 2026). Ich entscheide das deshalb je Projekt: Ein bestehender Rechnungsexport bleibt auf zugferd, bei einem Neubau schaue ich mir zuerst den Stand der Nachfolgerin an.

Ein Beleg entsteht im Wiki der Bibliothek so:

<?php
declare(strict_types=1);

use horstoeko\zugferd\ZugferdDocumentBuilder;
use horstoeko\zugferd\ZugferdProfiles;

$document = ZugferdDocumentBuilder::CreateNew(ZugferdProfiles::PROFILE_EN16931);
$document->setDocumentInformation('471102', '380', \DateTime::createFromFormat('Ymd', '20261201'), 'EUR');
// Parteien, Positionen, Steuer und Zahlung folgen mit den weiteren set- und add-Methoden.

Die Quelle der Daten ist ein strukturierter Rechnungsdatensatz, nicht das PDF. Bei ZUGFeRD sind nach der BMF-FAQ die XML-Daten maßgeblich, bei Abweichungen gelten sie. Die Reihenfolge ist deshalb: erst Daten, dann XML, dann gegebenenfalls das PDF-Bild.

#Rechnung prüfen: Schema, Geschäftsregeln und der KoSIT-Validator

Die Bibliothek bringt zwei Prüfer mit, wie ihr Wiki zur Validierung beschreibt. ZugferdXsdValidator prüft nur gegen die XSD und findet Formatfehler. ZugferdKositValidator ruft das Werkzeug der Koordinierungsstelle für IT-Standards (KoSIT) auf, braucht dafür eine Java-Installation und ist im Wiki als experimentell gekennzeichnet.

Der KoSIT-Validator (Apache-2.0) identifiziert das XML-Format, prüft es mit Schema und Schematron-Regeln, erzeugt einen Bericht und berechnet einen Annahmestatus. Er kennt selbst keine Regeln: Die liefert eine Konfiguration, für XRechnung die validator-configuration-xrechnung mit UBL und CII. Zum Stand November 2026 gilt:

• Der Validator steht auf Version 1.6.3 vom 20. August 2026. Laut Release Notes behebt sie eine Sicherheitslücke bei der Auflösung von URIs im Modus STRICT_LOCAL.
• Die Konfiguration trägt das Datum 2026-08-31, ist mit XRechnung 3.0 kompatibel und bündelt Validator 1.6.3 sowie die CEN-Schematron-Regeln 1.3.16.
• Im Quelltext von horstoeko/zugferd stehen als Voreinstellung dagegen Validator 1.5.0 und die Konfiguration vom 21. März 2025. Die Setter setValidatorDownloadUrl und setValidatorScenarioDownloadUrl ersetzen sie.

Wer die Voreinstellung nicht anfasst, prüft also gegen Regeln von 2025. Ich pinne die Versionen deshalb im Projekt und aktualisiere sie als eigenen Schritt. Die Konfiguration dokumentiert in ihren Release Notes, wie sich Einstufungen ändern: Seit der Version 2026-08-31 etwa heißt es für nicht verarbeitbare Dokumente “Das Dokument sollte nicht automatisiert angenommen werden” statt der früheren Zurückweisungsempfehlung.

Für den Dauerbetrieb bietet sich der Daemon-Modus an. Der Validator startet dann einen HTTP-Server (-D), der auf POST-Anfragen mit einem XML-Dokument antwortet. Nach der Dokumentation bedeutet Status 200 „akzeptabel”, 406 „nicht akzeptabel” und 422 einen Verarbeitungsfehler, der auf die Konfiguration hindeutet. Die Dokumentation sagt zugleich, dass es keinen Zugriffsschutz gibt und die Oberfläche nicht für die Produktion gedacht ist; der Server basiert auf dem JDK-HTTP-Server. Er gehört also hinter einen Proxy oder auf localhost. Der Aufruf aus Symfony sieht so aus:

<?php
declare(strict_types=1);

use Symfony\Component\HttpClient\HttpClient;

$response = HttpClient::create()->request('POST', 'http://127.0.0.1:8080/', [
    'headers' => ['Content-Type' => 'application/xml'],
    'body' => fopen($xmlPfad, 'r'),
]);

$akzeptiert = $response->getStatusCode() === 200;
$bericht = $response->getContent(false); // false: bei 406 und 422 keine Exception

In Laravel oder Symfony läuft das als Job in der Queue: erzeugen, prüfen, bei Status 200 versenden, sonst den Beleg mit dem Bericht in eine Fehlerliste legen, die jemand liest. Der Versand wird nie als Nebeneffekt der Rechnungserstellung ausgelöst.

#Was die Landeshauptstadt von Lieferanten verlangt

Wer an die Stadt liefert, bekommt ein konkretes Pflichtenheft. Die Landeshauptstadt Stuttgart beschreibt auf ihrer Seite Eingang von elektronischen Rechnungen und in der Anlage zu den BT-Feldern (Stand 02.06.2026):

• Zulässig sind XRechnung und ZUGFeRD, ZUGFeRD mindestens im Profil EN 16931 (COMFORT). Das ist strenger als die Grenze des BMF. Die Stadt empfiehlt ZUGFeRD.
• Die Rechnung geht per E-Mail an die Stadt, nicht über ein Portal. Peppol wird nicht unterstützt, und die Stadt ist nicht an das Zentrale Rechnungseingangsportal des Landes angebunden.
• Eine Leitweg-ID ist grundsätzlich nicht nötig. Falls ein System sie technisch verlangt, nennt die Stadt eine Kennung, die sich in BT-10 eintragen lässt.
• Bei XRechnung gehört das Geschäftszeichen des Fachamts zusätzlich in den Betreff oder Mailtext, in BT-51 oder BT-56.
• Dieselbe Rechnung in mehreren Formaten oder zusätzlich auf Papier zu senden, ist nicht zulässig. Eine E-Mail enthält genau eine Rechnung, höchstens 12 MB, Anhänge nur als PDF und ohne Kennwort.
• Bei ZUGFeRD müssen PDF und XML inhaltlich identisch sein.
• Die Stadt bittet, in der E-Rechnung keine besonders schützenswerten Daten wie personenbezogene Daten zu führen und solche Angaben getrennt an das Fachamt zu schicken.

Daraus lassen sich Regeln für den Versandjob ableiten: Das Zielsystem trägt seine Anforderungen als Konfiguration (Profil, Pflichtfelder, Dateinamenpräfix, Mailgröße), und der Job bricht ab, wenn sie nicht erfüllt sind. Das Muster gilt für jeden größeren Kunden, der Lieferantenvorgaben hat. Ein Konzern aus der Region hat andere Vorgaben als die Stadt, und das lässt sich nur aus seinen eigenen Unterlagen lesen.

Foto: Fred Romero from Paris, France, CC BY 2.0, Wikimedia Commons.

#Archivieren: unveränderlich, mit Bericht

§ 14b Abs. 1 UStG verlangt acht Jahre Aufbewahrung für ein Doppel jeder ausgestellten und jede erhaltene Rechnung, und die Rechnungen müssen den ganzen Zeitraum die Anforderungen an Echtheit der Herkunft, Unversehrtheit des Inhalts und Lesbarkeit erfüllen. Nach den BMF-FAQ (Frage 13) ist bei einer E-Rechnung zumindest der strukturierte Teil so aufzubewahren, dass er unversehrt in seiner ursprünglichen Form vorliegt. Die Speicherung außerhalb eines GoBD-konformen Datenverarbeitungssystems ist umsatzsteuerlich regelmäßig kein Verstoß. Ergänzend verweisen die FAQ auf das GoBD-Schreiben vom 28. November 2019, zuletzt geändert am 14. Juli 2025.

In der Datenbank übersetze ich das in vier Regeln:

1. Die Originalbytes der XML-Datei (bei ZUGFeRD die ganze PDF-Datei) werden einmal gespeichert und nie überschrieben.
2. Zu jedem Beleg gehören ein Hashwert, der Zeitpunkt der Erzeugung und der Validierungsbericht samt Versionen von Validator und Konfiguration.
3. Eine Korrektur ist ein neuer Beleg mit Bezug auf den alten. Das BMF-Schreiben von 2026 sagt in Randnummer 20, die Berichtigung müsse als E-Rechnung mit dem Rechnungstyp für eine Berichtigung erfolgen, und stellt fest, dass technisch noch nicht festgelegt ist, welcher Typ welchen Vorgang abbildet. Entscheidend ist, dass sich aus Original und Berichtigungen der tatsächliche Inhalt klar ergibt.
4. Exporte für die Steuerberatung lesen das gespeicherte Original, nicht eine Neuberechnung aus aktuellen Stammdaten.

Eine Rechnung enthält Namen und Anschriften, bei Einzelunternehmen und Ansprechpersonen also personenbezogene Daten. Die Rechtsgrundlage der Verarbeitung ist die rechtliche Verpflichtung nach Art. 6 Abs. 1 lit. c DSGVO, und Art. 17 Abs. 3 lit. b nimmt die Löschpflicht aus, soweit eine Rechtspflicht die Verarbeitung erfordert. Nach Ablauf der Frist gehört der Beleg samt Bericht gelöscht, und das Löschen ist ein Job, den ich mitliefere. Aufsicht in Baden-Württemberg ist der LfDI Baden-Württemberg mit Sitz in der Heilbronner Straße 35 in Stuttgart.

#Checkliste für Ihre Rechnungsstrecke

Sie können die Liste ohne mich abarbeiten:

• Gibt es ein Leistungsdatum je Beleg, und folgt daraus, ob die Übergangsregel greift?
• Wird die Rechnung aus strukturierten Daten gebaut und das PDF daraus erzeugt, nicht umgekehrt?
• Läuft vor dem Versand eine Prüfung gegen Schema und Geschäftsregeln, und stoppt der Versand bei jedem Fehler?
• Sind Validator und Konfiguration auf einer bewusst gewählten, aktuellen Version festgelegt?
• Ist hinterlegt, welches Format, welches Profil und welche Pflichtfelder jeder größere Kunde verlangt?
• Wird der Eingang gelesen und gespeichert, nicht nur als Bild abgelegt?
• Bleiben Originaldatei, Hashwert und Validierungsbericht acht Jahre unverändert?
• Gibt es einen Löschjob nach Fristablauf?

#So arbeite ich mit Ihnen

Ich arbeite allein, remote und schriftlich, ohne Termine und Telefonate. Am Anfang steht ein schriftliches Briefing: Welche Anwendung erzeugt die Rechnungen, welche Kunden verlangen welches Format, wie sieht der Rechnungsdatensatz heute aus. Rückfragen und der schriftliche Umfang mit den Annahmen kommen per E-Mail. Umgesetzt wird auf einem Staging-System, ich liefere die Funktion mit automatischen Tests, Sie nehmen sie anhand Ihrer eigenen Beispielrechnungen ab. Danach ist ein Wartungsvertrag möglich, Stunden daraus gelten im jeweiligen Monat und werden nicht übertragen. Layouts und Grafik, etwa das Aussehen des PDF-Teils einer ZUGFeRD-Rechnung, liefern Sie als Vorlage, ich setze sie um.

Für den Start brauche ich: Zugriff auf Repository und Staging, drei bis fünf echte, anonymisierte Rechnungen, die Lieferantenvorgaben Ihrer wichtigsten Kunden und die Adresse Ihrer Steuerberatung für die Frage nach den Fristen.

#Häufige Fragen

#Muss mein Unternehmen E-Rechnungen schon senden?

Das hängt vom ausgeführten Umsatz ab. Für Umsätze bis Ende 2026 dürfen Sie noch sonstige Rechnungen ausstellen, für Umsätze 2027 nur bei höchstens 800.000 Euro Gesamtumsatz im Vorjahr. Empfangen müssen Sie E-Rechnungen seit dem 1. Januar 2025. Stand November 2026, geklärt mit Ihrer Steuerberatung.

#XRechnung oder ZUGFeRD?

Beide erfüllen laut BMF die Anforderungen, ZUGFeRD ab 2.0.1 ohne die Profile MINIMUM und BASIC-WL. Bei ZUGFeRD gelten die XML-Daten, nicht das PDF. Die Landeshauptstadt Stuttgart empfiehlt ZUGFeRD. Welches Format Ihre Kunden verlangen, steht meist in deren Lieferantenvorgaben.

#Reicht eine Prüfung gegen das XML-Schema?

Nein. Das Schema findet Formatfehler. Fehlende oder widersprüchliche Angaben, etwa eine falsche Steuersumme, findet erst die Prüfung gegen die Geschäftsregeln, zum Beispiel mit dem KoSIT-Validator.

#Was passiert, wenn die Validierung einen Geschäftsregelfehler meldet?

Umsatzsteuerlich zählt er nach dem BMF nur, wenn er eine Pflichtangabe betrifft. Technisch ist die Datei dann aber nicht EN-16931-konform, und eine automatische Annahme beim Empfänger ist nicht gesichert. Mein Ziel ist deshalb, dass der Versand bei jedem Fehler stoppt.

#Wie lange und in welcher Form muss ich E-Rechnungen aufbewahren?

Acht Jahre nach § 14b Abs. 1 UStG. Bei einer E-Rechnung muss mindestens der strukturierte Teil unversehrt im Original vorliegen. Ein PDF-Abbild ersetzt ihn nicht. Den Validierungsbericht heben Sie als Nachweis zusätzlich auf.

#Kommen Sie für die Abstimmung nach Stuttgart?

Nein. Ich arbeite remote und schriftlich, Termine und Anrufe gibt es bei mir nicht. Ich kläre alles per E-Mail und in Dokumenten.

#Schreiben Sie mir

Schicken Sie mir die Adresse Ihrer Website oder Anwendung, die PHP-Version und das Framework, das Ziel, Ihren Termin und die Angabe, welche Kunden Rechnungen als E-Rechnung verlangen. Die erste schriftliche Einschätzung zu Aufwand und Vorgehen ist für Sie kostenlos. Schreiben Sie mir dazu über die Kontaktseite.