ZUGFeRD lässt sich ohne Cloud-Dienst verarbeiten. Das folgt schon aus dem Aufbau: Die Rechnung ist eine PDF/A-3-Datei, in der strukturierte XML-Rechnungsdaten eingebettet sind. Ein geeignetes System kann beides lokal lesen. Weder ZUGFeRD noch Factur-X schreibt vor, dass eine Rechnung an einen externen Dienst übertragen werden muss.
Das ist allerdings keine Ein-Klick-Aussage wie „Datei öffnen und fertig“. Produktive lokale Verarbeitung besteht aus mehreren Komponenten: sicherer Dateieingang, Extraktion, technische und fachliche Validierung, Visualisierung, Freigabe, Übergabe an die Buchhaltung und Aufbewahrung.
Stand: August 2026. Aktuelles FeRD-Release ist ZUGFeRD 2.5 / Factur-X 1.09. Betriebs- und Sicherheitsanforderungen müssen zur tatsächlich eingesetzten Version und Infrastruktur passen.
Was „ohne Cloud“ konkret bedeuten kann
Der Begriff wird oft unscharf verwendet. Drei Modelle sind zu unterscheiden:
| Betriebsmodell | Verarbeitung | Datenspeicherung | Typische Verantwortung |
|---|---|---|---|
| vollständig On-Premises | Parser, Validierung, Workflow und ERP-Anbindung im eigenen Netz | eigene Systeme | internes IT-/Operations-Team |
| Private Cloud / dedizierte Umgebung | Komponenten in einer exklusiven Cloud-Umgebung | definierter Mandant oder eigene Subscription | Unternehmen und Betreiber geteilt |
| SaaS | Verarbeitung beim Softwareanbieter | nach Vertrag und Architektur des Anbieters | überwiegend Anbieter, mit Pflichten des Kunden |
„Keine öffentliche SaaS-Plattform“ ist also nicht automatisch dasselbe wie „alles steht im Serverraum“. Entscheidend sind Datenflüsse, Speicherorte, Administrationszugriffe und vertragliche Verantwortlichkeiten.
So funktioniert die lokale ZUGFeRD-Verarbeitung
1. Datei sicher annehmen
Rechnungen können per E-Mail, Upload, Dateisystem, DMS oder Schnittstelle eintreffen. Der Eingang braucht klare Größenlimits, erlaubte Dateitypen, Malware-Prüfung und eine Quarantäne für auffällige Dokumente. Die Dateiendung allein reicht nicht; das System muss den tatsächlichen Inhalt prüfen.
2. PDF und eingebettetes XML erkennen
Ein PDF/A-3-fähiger Parser prüft, ob die PDF eingebettete Dateien enthält und ob die ZUGFeRD-/Factur-X-Metadaten plausibel sind. In aktuellen Releases trägt die XML-Datei typischerweise den Namen factur-x.xml. Der Name allein beweist aber keine Konformität.
3. XML sicher parsen
XML-Parser sollten externe Entitäten und unkontrollierte Netzwerkzugriffe deaktivieren. Eingangsdateien sind nicht vertrauenswürdig, nur weil sie Rechnungen heißen. Größen-, Verschachtelungs- und Laufzeitgrenzen verhindern, dass manipulierte XML-Dateien unnötig Ressourcen binden.
4. Version und Profil bestimmen
Guideline-ID, Namespaces und Metadaten zeigen, nach welcher ZUGFeRD-/Factur-X-Version und welchem Profil die Datei erstellt wurde. Diese Information entscheidet, welche Schemata, Schematron-Regeln und Codelisten anzuwenden sind. Einen Überblick gibt ZUGFeRD-Versionen und Profile.
5. Technisch und fachlich validieren
Eine robuste Prüfung besteht aus mehreren Ebenen:
- XML-Wohlgeformtheit,
- Schema-Konformität,
- Profil- und EN-16931-Geschäftsregeln,
- Pflichtangaben nach dem konkreten Geschäftsvorfall,
- rechnerische Plausibilität,
- Abgleich von strukturiertem Teil und sichtbarer PDF.
Das BMF stellt klar: Eine technische Validierung ist nicht allein Voraussetzung für die steuerliche Anerkennung, aber sinnvoll, um fehlende oder unlogische Angaben früh zu erkennen. Bei einer hybriden E-Rechnung ist der strukturierte Teil führend, falls XML und PDF-Darstellung voneinander abweichen.
6. Lesbare Ansicht erzeugen
Die vorhandene PDF-Sicht ist praktisch, darf aber nicht ungeprüft als alleinige Datenquelle dienen. Die Anwendung sollte die aus dem XML gelesenen Werte sichtbar machen und Abweichungen markieren. So prüft Finance das maßgebliche strukturierte Original statt nur eine optisch plausible PDF.
7. Workflow, ERP und Archiv anbinden
Nach der Validierung folgen Dublettenprüfung, Kontierung, Freigabe und Buchungsübergabe. Das Originaldokument, das XML, Validierungsergebnis und relevante Prozessereignisse müssen eindeutig demselben Vorgang zugeordnet bleiben. Wie SALinvoice unterschiedliche Rechnungsformate in einen Prozess bringt, zeigt die Seite E-Rechnungen und Rechnungsformate verarbeiten.
Sicherheitsgrenzen einer On-Premises-Lösung
Lokaler Betrieb reduziert mögliche externe Datenübertragungen, ersetzt aber kein Sicherheitskonzept. Prüfen Sie mindestens:
- Werden Parser und Validierungsartefakte kontrolliert aktualisiert?
- Laufen Dateiprüfung und Extraktion mit minimalen Rechten?
- Sind temporäre Dateien verschlüsselt und werden sie zuverlässig entfernt?
- Enthalten Logs nur technische IDs und Fehler oder unnötig vollständige Rechnungsdaten?
- Sind Rollen für Administration, Fachprüfung und Freigabe getrennt?
- Gibt es Backup, Wiederanlauf und getestete Wiederherstellung?
- Werden historische Validierungsartefakte aufbewahrt, damit alte Rechnungen später nachvollziehbar geprüft werden können?
Entscheidung: lokal, Private Cloud oder SaaS?
On-Premises ist sinnvoll, wenn verbindliche Datenlokalität, isolierte Netze oder vorhandene Betriebsplattformen überwiegen und das Unternehmen Parser, Regeln und Sicherheitsupdates dauerhaft betreiben kann. SaaS kann sinnvoller sein, wenn schnelle Updates, Skalierung und geringerer interner Betrieb wichtiger sind.
Die richtige Frage lautet daher nicht nur „Cloud oder nicht?“, sondern:
- Welche Daten verlassen welche Vertrauenszone?
- Wer aktualisiert ZUGFeRD-Schemata und Geschäftsregeln?
- Wer überwacht Fehler, Quarantäne und Wiederverarbeitung?
- Wie werden Original, XML und Audit Trail gemeinsam aufbewahrt?
- Wie gelangt ein validierter Vorgang ohne Medienbruch in das ERP?
Offizielle Quellen
- FeRD – ZUGFeRD 2.5 / Factur-X 1.09: aktuelles Release-Paket, PDF/A-3-Aufbau, Profile und Validierungsartefakte.
- Bundesfinanzministerium – FAQ zur E-Rechnung: zulässige Formate, Validierung, strukturierter Rechnungsteil und Aufbewahrung.