E-Rechnungssoftware für Entwickler: XRechnung, Factur-X, Peppol selbst bauen?

Eine gültige EN-16931-XML-Datei zu erzeugen ist der kleine Teil der E-Rechnung, und eine gute Bibliothek erledigt das für Sie in einer Woche. Der große Teil ist alles rund um die Datei: mit nationalen Regelwerken Schritt halten, die sich ständig ändern; gegen das Schematron des Käuferlandes validieren; je Käufer das richtige Profil und die richtige Syntax wählen; das Dokument über Peppol, eine zugelassene Plattform oder KSeF übermitteln; die Rechnung so, wie sie ausgestellt wurde, für die Aufbewahrungsfrist speichern; und das Ganze in umgekehrter Richtung für das tun, was Ihre Lieferanten Ihnen schicken. Bauen Sie selbst, wenn E-Rechnung Ihr Produkt ist; kaufen Sie — oder integrieren Sie über eine API —, wenn sie Ihre Pflicht ist.

Was die Norm tatsächlich von Ihnen verlangt

EN 16931 definiert ein semantisches Datenmodell einer Rechnung und zwei XML-Syntaxen, die es transportieren; jedes nationale Format in West- und Mitteleuropa ist entweder ein eingeschränktes Profil dieses Modells oder, im Fall Polens, ein eigenes Schema. Zur Umsetzung brauchen Sie das Modell, die Syntaxbindung und die darüber gelegten nationalen Regeln.

Die Seite der Kommission zum Bezug der Norm listet die Teile auf: „das semantische Datenmodell (EN 16931-1: 2017)“ und „die beiden verpflichtenden Syntaxen, die der Norm entsprechen (CEN/TS 16931-2: 2017)“ sind über nationale Normungsorganisationen kostenfrei erhältlich, während „Kopien der übrigen Teile (3-6) der Norm, bestehend aus Syntaxbindungen, Leitlinien und Methoden, verkauft werden“. Die beiden Syntaxen sind UBL 2.1 (Teil 3-2) und UN/CEFACT CII D16B (Teil 3-3). Darüber hinaus:

• Deutschland — XRechnung, die nationale Spezifikation der KoSIT, mit eigenem Schematron und eigenen Codelisten-Einschränkungen; und ZUGFeRD, das hybride PDF/A-3 mit eingebettetem CII. Ab 2027 dürfen Unternehmen mit über 800.000 EUR Umsatz „keine Papierrechnungen mehr ausstellen oder unstrukturierte elektronische Formate verwenden“; alle Unternehmen ab 2028.
• Frankreich — Factur-X, „ein deutsch-französischer Standard für hybride elektronische Rechnungen (PDF für Nutzer und XML-Daten für die automatisierte Verarbeitung)“, technisch „derselbe Standard wie ZUGFeRD 2.5“, dazu UBL und CII, ausgetauscht über zugelassene Plattformen, die das Ministerium als „obligatorischen Vermittler zwischen Unternehmen“ bezeichnet.
• Belgien — Peppol BIS Billing 3.0, eine CIUS der EN 16931 in UBL 2.1; „alle Instanzdokumente, die dieser Spezifikation entsprechen, entsprechen der europäischen Norm (EN 16931)“.
• Polen — FA(3), ein nationales XML-Schema, das an KSeF übermittelt wird, „verpflichtend für alle Unternehmer“ ab dem 1. April 2026 mit Ausnahme der kleinsten, die am 1. Januar 2027 folgen.

Die Formate werden auf der Formatseite im Detail verglichen; das Modell selbst auf EN 16931.

Was eine Bibliothek leistet — und was nicht

Eine Bibliothek verwandelt Ihr Rechnungsobjekt in XML (oder ein hybrides PDF) und führt, bei den besseren, das Schematron aus. Sie kennt weder das Land Ihres Käufers noch Ihr umsatzsteuerliches Ergebnis, Ihren Nummernkreis oder die Aufbewahrungsfrist, und sie liefert nichts irgendwohin.

Eine Entscheidung fürs Selbstbauen ist in Wirklichkeit eine Entscheidung, die mittleren Zeilen dieser Tabelle selbst zu verantworten. Für ein Unternehmen, dessen Produkt die Rechnungsstellung ist, ist das die richtige Wahl. Für ein SaaS- oder Dienstleistungsunternehmen, das fünfzig gültige Rechnungen im Monat in drei Ländern ausstellen muss, ist es ein zweites Produkt, nach dem niemand gefragt hat.

Validierung: Die Regeln ändern sich, und der Validator des Käufers gewinnt

Eine Rechnung ist gültig, wenn der Validator des Empfängers das sagt, und Empfänger verwenden die nationalen Regelwerke. Validieren Sie gegen diese, nicht gegen „wohlgeformtes XML“, und validieren Sie erneut, wenn sich das Regelwerk ändert — sowohl KoSIT als auch OpenPeppol veröffentlichen aktualisierte Regelpakete in regelmäßigen Release-Zyklen.

Das Referenzwerkzeug für Deutschland ist der KoSIT-Validator, eine Open-Source-Engine, die „das tatsächliche XML-Format erkennt, die XML-Datei (anhand von Schema- und Schematron-Regeln) validiert, einen eigenen Bericht erzeugt / eigene Daten aus der XML-Datei extrahiert und einen Annahmestatus berechnet“, gesteuert über Szenario-Konfigurationen für XRechnung und EN 16931. Er läuft von der Kommandozeile, eingebettet in Java oder als HTTP-Daemon, unter der Apache-2.0-Lizenz — was ihn zu einem guten CI-Schritt macht, ob Sie nun bauen oder kaufen. Peppol BIS Billing 3.0 liefert sein Schematron in zwei Sätzen, „Peppol transaction business rules“ und „EN 16931 transaction business rules“; beide müssen bestehen. Bei hybriden Formaten validieren Sie zweimal: das eingebettete XML gegen das Profil und den Container gegen PDF/A-3.

Wofür Sie sich auch entscheiden: Behalten Sie einen unabhängigen Validator in Ihrer Pipeline. Der kostenlose E-Rechnungs-Prüfer validiert eine Datei gegen die Regeln eines Landes, ohne sie zu speichern — das genügt für eine Stichprobe; der KoSIT-Validator in der CI ist die stärkere Gewohnheit. Die Details auf Entwicklerebene — Business Terms, Regelkennungen, häufige Fehler — stehen im EN-16931-Entwicklerleitfaden.

Übertragung: Drei Netzwerke, drei verschiedene Probleme

Die Datei zu erzeugen ist in jedem Land dasselbe Problem; sie zuzustellen nicht. Peppol ist ein Vier-Ecken-Netzwerk, dem Sie über einen Access Point beitreten; das französische System leitet B2B-Rechnungen über zugelassene Plattformen; das polnische KSeF ist eine zentrale staatliche Plattform, die der Rechnung ihre rechtliche Identität zuweist.

Peppol (Belgien und grenzüberschreitend)

Sie sprechen nicht mit dem Käufer; Ihr Access Point spricht mit dessen Access Point, nachdem er die Teilnehmerkennung des Käufers nachgeschlagen hat. Einen eigenen Access Point zu bauen bedeutet eine Akkreditierung bei OpenPeppol und den Betrieb von SMP/AS4-Infrastruktur; fast jedes Unternehmen beauftragt stattdessen einen Access-Point-Anbieter und integriert dessen API. Siehe Peppol und den Peppol-Entwicklerleitfaden.

Zugelassene Plattformen (Frankreich)

Nur eine plateforme agréée darf zwischen Unternehmen und an die Steuerverwaltung übermitteln. Ein Softwareanbieter wird entweder selbst eine — ein Registrierungsverfahren bei der Verwaltung — oder integriert eine. Siehe zugelassene Plattformen.

KSeF (Polen)

Sie authentifizieren sich, öffnen eine Sitzung, übermitteln FA(3)-XML und erhalten eine KSeF-Nummer und eine amtliche Empfangsbestätigung (UPO); die Rechnung ist rechtlich ausgestellt, wenn KSeF sie annimmt, nicht wenn Sie sie erzeugen. Die Plattform hat getrennte Test- und Produktionsumgebungen, und ein in der einen nachgewiesenes Verhalten beweist nichts für die andere. Siehe KSeF.

Deutschland

Kein vorgeschriebenes Netzwerk: E-Mail, Download oder Peppol sind im B2B allesamt zulässige Kanäle für XRechnung und ZUGFeRD. Die Pflicht betrifft das Format, nicht den Übertragungsweg.

Archivierung: Die ausgestellte Datei, unverändert, über Jahre

Die Rechnung, die Sie aufbewahren müssen, ist die strukturierte Datei so, wie sie ausgestellt wurde — nicht eine PDF-Darstellung davon und nicht eine aus heutigen Daten neu erzeugte Kopie. Die EU-Regeln lassen die Form der Aufbewahrung offen („Unternehmen können Rechnungen im Allgemeinen frei entscheiden, wo und wie sie sie aufbewahren“), aber jedes Land legt eine Aufbewahrungsfrist und Anforderungen an den Prüfungszugriff fest, und wo die Rechnung als strukturiertes XML ausgestellt wurde, gilt das XML — nicht eine Darstellung davon — als die Rechnung.

Für einen Entwickler heißt das: Speichern Sie exakt die Bytes, die Sie gesendet haben, mit einem Hash, zusammen mit dem Validierungsbericht und — bei Peppol oder KSeF — der Übertragungsquittung; erzeugen Sie nie neu; machen Sie das Archiv ohne Ihre Anwendung lesbar. Aufbewahrungsfristen und der zulässige Speicherort für Ihr Unternehmen erfordern eine fachliche Bestätigung.

Wie KRONENWERK damit umgeht

KRONENWERK ist ein Buchhaltungssystem, das die E-Rechnung bei der Ausstellung erzeugt und validiert, mit einer API für die Abläufe drumherum. Es ist die Spalte „Kaufen / Integrieren“ der obigen Tabelle, mit den genannten Einschränkungen bei der Übertragung. Mit Einschränkungen unterstützt

• Erzeugung und Validierung bei der Ausstellung. Deutschland: XRechnung und ZUGFeRD, validiert mit den KoSIT-Schematron-Regeln und gegengeprüft mit der Mustang-Bibliothek. Frankreich: Factur-X (PDF/A-3 mit eingebettetem CII). Belgien: Peppol BIS Billing 3.0 UBL. Polen: FA(3)-XML für KSeF. Profil und Syntax folgen dem Land des Käufers; das umsatzsteuerliche Ergebnis und die VIES-Prüfung erfolgen im selben Schritt.
• Empfang. Eingehende XRechnung, ZUGFeRD/Factur-X und UBL werden als Eingangsrechnungen eingelesen.
• Übertragung. Peppol-Versand und -Empfang über einen akkreditierten Access-Point-Anbieter (Storecove), sobald die Firma unter Einstellungen → Zustellung angebunden ist — KRONENWERK ist selbst kein Access Point. Mit Einschränkungen unterstützt. Die französische Übermittlung ist über die Funktion von Storecove als zugelassene Plattform geplant und noch nicht produktionsreif — KRONENWERK ist keine plateforme agréée. Noch nicht bereit. Das KSeF-2.0-Modul (Token-Authentifizierung, Sitzung, FA(3)-Übermittlung, UPO-Abruf, Empfang) ist gebaut und umgebungsabhängig, wurde nicht gegen das produktive KSeF verwendet, und KRONENWERK verkauft derzeit keine Abonnements an polnische Unternehmen. Noch nicht bereit für die Übermittlung.
• API. Ihre Anwendung legt Kunden und Rechnungsentwürfe unter https://kronenwerk.org/api/extern/v1 an (POST /customers, POST /invoices/drafts, mit Idempotency-Key); die Ausstellung — der Schritt, der die Nummer vergibt, die E-Rechnung erzeugt und die Validierung ausführt — erfolgt im Produkt nach der Validierung. Webhooks melden invoice.issued, invoice.paid und invoice.cancelled. Beginnen Sie beim Schnellstart; der E-Rechnungs-Aspekt steht auf der Seite E-Rechnungs-API.