E-Rechnung Pflicht 2027/2028: Der Leitfaden für Entwickler

• Seit 1. Januar 2025 muss jedes deutsche Unternehmen E-Rechnungen empfangen können — dafür genügt technisch ein E-Mail-Postfach.
• Ab 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 € Vorjahresumsatz E-Rechnungen ausstellen.
• Ab 1. Januar 2028 gilt die Ausstellungspflicht für alle Unternehmen im inländischen B2B-Geschäft.
• Eine E-Rechnung ist strukturiertes XML nach EN 16931 — in der Praxis XRechnung oder ZUGFeRD. Ein gewöhnliches PDF ist keine E-Rechnung.
• Deutschland verlangt keine Plattform, kein Portal, keine Zertifizierung: Übertragung per E-Mail ist zulässig. Die Pflicht ist ein reines Format- und Validierungsproblem — also ein Softwareproblem.

Rechtsgrundlage ist das Wachstumschancengesetz, das § 14 UStG neu gefasst hat. Die Pflicht betrifft Umsätze zwischen inländischen Unternehmen (B2B). Privatkunden (B2C) sind nicht betroffen.

Bis dahin gelten Übergangsregeln: 2025 und 2026 dürfen alle Unternehmen mit Zustimmung des Empfängers weiterhin Papier oder sonstige Formate verwenden; 2027 gilt das nur noch für Unternehmen bis 800.000 € Vorjahresumsatz. Wichtig für die Planung: Die Zustimmung liegt beim Empfänger — sobald ein großer Kunde sie verweigert, ist die eigene Software faktisch früher in der Pflicht als das Gesetz verlangt.

Eine E-Rechnung ist eine Rechnung in einem strukturierten elektronischen Format, das der europäischen Norm EN 16931 entspricht — Daten, die eine Maschine feldgenau verarbeiten kann: Rechnungsnummer, Steuerbeträge, Zahlungsdaten als typisierte Felder statt als Fließtext.

Das räumt mit dem häufigsten Missverständnis auf: ein PDF ist keine E-Rechnung, auch kein sauber gestaltetes. Ein PDF ist ein Bild für Menschen. Beim Hybridformat ZUGFeRD steckt deshalb ein XML-Datensatz in der PDF-Datei — und rechtlich führend ist der XML-Teil, nicht das, was auf dem PDF zu sehen ist.

„Entspricht EN 16931“ heißt konkret: Das Dokument besteht die Prüfung gegen die Geschäftsregeln der Norm (Codes wie BR-CO-16) und — in Deutschland — gegen die nationalen Zusatzregeln der XRechnung (BR-DE-*). Diese Regeln sind versioniert und ändern sich etwa halbjährlich.

Beide Formate erfüllen die Pflicht. Die Wahl ist eine Produktentscheidung, keine rechtliche:

Faustregel: Wer an die öffentliche Hand oder an Konzerne fakturiert, braucht XRechnung. Wer an kleine Geschäftskunden fakturiert, macht ihnen mit ZUGFeRD den Übergang leichter. Viele Systeme bieten schlicht beides an — der Datensatz dahinter ist derselbe.

Hier ist Deutschland bemerkenswert pragmatisch: Es gibt keine staatliche Plattform, keine Registrierung und keine Zertifizierung. Eine E-Rechnung per E-Mail-Anhang erfüllt die Pflicht. Das unterscheidet Deutschland von Italien (SdI), Polen (KSeF) und Frankreich (Plateformes Agréées), wo Rechnungen über staatlich kontrollierte Infrastruktur laufen.

In der Praxis können Empfänger trotzdem Wege vorgeben: Behörden nutzen Portale oder Peppol, Konzerne teils eigene Eingangskanäle. Für die Software heißt das: Das Erzeugen des korrekten Formats ist die Pflicht, der Versandweg ist Vereinbarungssache.

1. 1Felder kartieren. Die Norm adressiert Felder als Business Terms (BT) und Gruppen (BG): BT-1 Rechnungsnummer, BT-2 Datum, BT-10 Käuferreferenz, BG-16 Zahlungsdaten. Erstellen Sie ein Mapping vom eigenen Datenmodell auf diese Begriffe, bevor Sie XML anfassen — die Pflichtfelder der XRechnung gehen über viele interne Rechnungsmodelle hinaus (etwa der Ansprechpartner-Block BG-6).
2. 2Beträge als Dezimalzahlen rechnen. Die Summenregeln der Norm prüfen centgenau. Gleitkommazahlen erzeugen Rundungsdifferenzen, die erst in der Validierung sichtbar werden — der klassische Fehler ist BR-CO-16.
3. 3XML erzeugen. UBL oder CII sind reihenfolgestrenge XSD-Schemata mit festen Namensräumen. Ob Bibliothek oder API: erzeugen Sie nie XML aus String-Vorlagen ohne anschließende Validierung.
4. 4Gegen das offizielle Regelwerk validieren — in der CI. Maßstab ist die Prüfung der KoSIT-Regeln, nicht „das Schema ist gültig“. Nehmen Sie echte Beispielrechnungen als Golden Files in die Testsuite auf und lassen Sie jede Änderung dagegen laufen.
5. 5Regelstände beobachten. Die XRechnung wird etwa halbjährlich aktualisiert. Pinnen Sie die Regelwerksversion, testen Sie Upgrades bewusst — eine Rechnung, die heute gültig ist, kann gegen ein neues Regelwerk Warnungen produzieren.

Die Praxis scheitert selten an Exoten — es sind immer dieselben Regeln:

• BR-DE-15 — die Käuferreferenz (BT-10) fehlt. Bei Behördenrechnungen gehört hier die Leitweg-ID hinein.
• BR-DE-2 bis BR-DE-7 — der komplette Kontaktblock des Verkäufers fehlt, weil er nur im PDF-Briefkopf existierte.
• BR-CO-16 und die übrigen Summenregeln — Rundungsdifferenzen aus Gleitkomma-Arithmetik.
• BR-DE-18 — Skonto-Angabe im Format #SKONTO#TAGE=n#PROZENT=n.nn# begonnen, aber nicht exakt eingehalten.
• BR-CO-25 — weder Fälligkeitsdatum noch Zahlungsbedingungen übermittelt.

Das vollständige Nachschlagewerk mit Erklärung und Lösung je Regel: alle XRechnung-Fehlercodes. Oder direkt ausprobieren: Rechnung im Validator prüfen — kostenlos, ohne Speicherung.

Selbst bauen ist machbar: Es gibt solide Open-Source-Bibliotheken, und die Spezifikationen sind öffentlich. Der ehrliche Kostenpunkt ist nicht der erste Release, sondern die Pflege — Regelwerks-Updates etwa halbjährlich, zwei Syntaxen, PDF/A-3-Konformität beim Hybridformat und die Testabdeckung, die Korrektheit dauerhaft absichert.

Genau diesen laufenden Teil übernimmt NormAPI: Rechnungsdaten als JSON an die API, valide XRechnung oder ZUGFeRD zurück, Prüfung gegen das jeweils aktuelle Regelwerk — Version pinnen oder automatisch folgen. Der Validator ist dieselbe API, die auch Kunden nutzen.

1. 1Stichtag des eigenen Produkts klären: Welche Kunden überschreiten 800.000 € — 2027 oder 2028?
2. 2Zielformate festlegen: XRechnung (UBL/CII), ZUGFeRD oder beides.
3. 3Feld-Mapping auf BT/BG-Begriffe dokumentieren, Pflichtfelder-Lücken im eigenen Datenmodell schließen.
4. 4Geldbeträge auf Dezimalarithmetik umstellen, Rundung zentralisieren.
5. 5Validierung gegen das offizielle Regelwerk in die CI aufnehmen — oder per API prüfen.
6. 6Golden Files echter Rechnungen in die Testsuite aufnehmen.
7. 7Prozess für Regelwerks-Updates festlegen (pinnen, testen, nachziehen).
8. 8Empfangsweg für eingehende E-Rechnungen der eigenen Kunden bedenken.