Eine gültige E-Rechnung (XRechnung oder ZUGFeRD/Factur-X) erzeugst du aus Java am robustesten über eine E-Rechnung API statt durch eigenes XML-Bauen: Du sendest strukturierte Rechnungsdaten per java.net.http.HttpClient, der Dienst rechnet die Summen, vergibt die Nummer und rendert das EN-16931-konforme Dokument. Der Flow sind drei Calls — anlegen, ausstellen, XML oder PDF abholen — die sich mit dem seit Java 11 eingebauten HttpClient ohne zusätzliche HTTP-Bibliothek abbilden lassen.
Eine gültige E-Rechnung (XRechnung oder ZUGFeRD/Factur-X) erzeugst du aus Python am robustesten über eine E-Rechnung API statt durch eigenes XML-Bauen: Du sendest strukturierte Rechnungsdaten per requests, der Dienst rechnet die Summen, vergibt die Nummer und rendert das EN-16931-konforme Dokument. Der Flow sind drei Calls — anlegen, ausstellen, XML oder PDF abholen — die sich mit requests in wenigen Zeilen abbilden lassen.
Peppol ist ein europäisches Vier-Ecken-Netzwerk zum Austausch elektronischer Rechnungen: Du übergibst den Beleg an einen zertifizierten Access Point, der ihn über das Netz an den Access Point des Empfängers zustellt. Für inländisches B2B ist Peppol in Deutschland nicht vorgeschrieben — die E-Mail genügt. Über eine E-Rechnung API bereitest du die Anbindung vor, indem Erzeugung und Versand getrennt bleiben; bei Fortlauf ist der Peppol-Versand geplant und noch nicht als Rail verfügbar.
Ein ZUGFeRD-Dokument ist ein PDF/A-3b, in das das CII-XML nach EN 16931 als benannte Datei eingebettet ist (bei ZUGFeRD 2.1+/Factur-X: factur-x.xml), mit einer Dokument-Zuordnung (AFRelationship) und einem XMP-Extension-Schema, das Profil und Dateinamen deklariert. Selbst gebaut ist das fehleranfällig — PDF/A-3b-Konformität, XMP und Beleg-XML-Konsistenz müssen exakt stimmen. Über eine API bekommst du das fertige PDF/A-3 aus einem Call.
EN 16931 ist die europäische Norm, die ein semantisches Kernmodell für die elektronische Rechnung definiert: benannte Geschäftsobjekte (Business Groups, BG-…) und Geschäftsfelder (Business Terms, BT-…) samt Geschäftsregeln (BR-…). Sie ist syntaxneutral und wird in zwei XML-Syntaxen abgebildet — UN/CEFACT CII und OASIS UBL. XRechnung und ZUGFeRD/Factur-X sind nationale Ausprägungen (CIUS) dieser einen Norm.
Eine gültige XRechnung aus Node.js erzeugst du am robustesten über eine E-Rechnung API statt durch eigenes XML-Bauen: Du sendest strukturierte Rechnungsdaten per fetch, der Dienst rechnet die Summen, vergibt die Nummer und rendert das EN-16931-konforme XML. Der Flow sind drei Calls — anlegen, ausstellen, XML abholen — die sich mit dem eingebauten fetch in wenigen Zeilen TypeScript abbilden lassen.
Eine gültige XRechnung aus PHP heraus erzeugst du am robustesten nicht durch eigenes XML-Zusammenbauen, sondern über eine E-Rechnung API: Du schickst strukturierte Rechnungsdaten (Kunde, Positionen, Steuersätze) per HTTP, der Dienst rechnet die Summen, vergibt die Nummer und rendert das EN-16931-konforme XML. Der Flow sind drei Calls — anlegen, ausstellen, XML abholen — die sich mit Guzzle oder der curl-Erweiterung in wenigen Zeilen abbilden lassen.
Ein DATEV-Export überführt Ihre Rechnungsdaten in einen DATEV-konformen Buchungsstapel im DATEV-Format (EXTF), den Ihre Steuerberatung direkt in DATEV importieren kann. Bei Fortlauf ist dieser Export auf denselben strukturierten Rechnungsdaten angelegt wie die E-Rechnung — er ist aber noch nicht nutzbar: Es gibt bislang keine Oberfläche dafür und keinen Abruf über einen API-Schlüssel. Der DATEV-Export steht damit auf der Roadmap.
XRechnung ist ein reines XML-Format für elektronische Rechnungen nach der Norm EN 16931. Es enthält ausschließlich strukturierte Daten — keinen Sichtbeleg — und existiert in zwei Syntaxen (CII oder UBL). XRechnung wird vor allem im Behördenkontext (B2G) verlangt und von vielen großen Abnehmern erwartet.
ZUGFeRD ist ein hybrides E-Rechnungsformat: ein PDF/A-3 mit eingebettetem CII-XML nach EN 16931. Der Empfänger sieht ein normales PDF, die Software liest die strukturierten Daten aus dem eingebetteten XML. Factur-X ist derselbe Standard unter französischem Namen; ab Version 2.0.1 sind die Profile deckungsgleich.
Selbst bauen lohnt sich, wenn E-Rechnung zu deinem Kernprodukt gehört und du die laufende Formatpflege dauerhaft tragen willst. Einbinden lohnt sich, wenn Rechnung ein Nebenschauplatz ist: Eine API kapselt Codelisten, EN-16931-Geschäftsregeln, Profilversionen, Validierung, atomare Nummernvergabe und Archivierung — Arbeit, die nie fertig wird, weil die Formate ein bewegliches Ziel sind.
Für inländische B2B-E-Rechnungen ist kein bestimmtes Übertragungsnetz vorgeschrieben — die E-Mail ist ein zulässiger Übertragungsweg. Peppol ist ein optionaler Kanal, der an Bedeutung gewinnt, aber keine Pflicht ist. Erzeugung und Versand sind zwei getrennte Schritte: Das Format (XRechnung/ZUGFeRD) ist unabhängig vom Weg zum Empfänger.
XRechnung ist ein reines XML-Format nach EN 16931 (in Deutschland als CII-Syntax), das Behörden und viele große Abnehmer verlangen. Über eine API erzeugst du es in drei Schritten: Rechnung anlegen (der Server rechnet Summen und USt), ausstellen (Nummer wird atomar vergeben, das XML wird gerendert und validiert), XML abholen.
Eine E-Rechnungs-API nimmt strukturierte Rechnungsdaten (Kunde, Positionen, Steuersätze) entgegen und gibt dir daraus EN-16931-konforme Belege zurück — XRechnung als XML und ZUGFeRD/Factur-X als hybrides PDF/A-3. Du schickst die Daten, der Dienst übernimmt Format, Berechnung und Nummernvergabe. So sparst du dir eigene Formatpflege gegen die EN 16931.
Die KoSIT-Validierung prüft eine E-Rechnung gegen die offiziellen Prüfregeln der Koordinierungsstelle für IT-Standards (KoSIT) — die Umsetzung der EN 16931 und des jeweiligen Profils (XRechnung, ZUGFeRD). Das Ergebnis ist ein Bericht mit den Verdikten passed, warning oder failed und den verletzten Geschäftsregeln.
ZUGFeRD (bzw. Factur-X) ist ein hybrides PDF/A-3 mit eingebettetem CII-XML nach EN 16931. Über eine API erzeugst du es in drei Schritten: Rechnung anlegen (der Server rechnet Summen und USt), ausstellen (Nummer und Format werden festgezogen), Artefakt abholen (das PDF/A-3 inkl. XML).
Wir möchten messen, wie diese Seite genutzt wird, um sie zu verbessern — mit
Umami, das wir selbst auf eigenen Servern in Deutschland betreiben.
Keine Weitergabe an Dritte, keine seitenübergreifenden Profile, keine Werbe-Cookies.
Dazu speichern bzw. lesen wir Informationen auf deinem Gerät (§ 25 TDDDG) und
verarbeiten die dabei erhobenen Nutzungsdaten (Art. 6 Abs. 1 lit. a DSGVO) — beides ausschließlich mit deiner Einwilligung. Ohne deine Einwilligung
wird nichts geladen und die Seite funktioniert vollständig. Du kannst jederzeit ablehnen
oder deine Einwilligung mit Wirkung für die Zukunft widerrufen; die Rechtmäßigkeit der
bis dahin erfolgten Verarbeitung bleibt davon unberührt.
