E-Invoicing für Kleinunternehmer

Sebastian Birnbach

14. Januar 2025

E-Invoicing für Kleinunternehmer, am Beispiel von Zweibrücken IP

Unternehmen im B2B-Bereich müssen elektronische Rechnungen ab dem 01. Januar 2025 empfangen und ab 2027 auch stellen können. Hat Ihr Unternehmen einen Jahresumsatz unter 800.000 €, können Sie sich damit Zeit lassen bis 20281. Weil man auch als Rechnungssteller etwas davon haben könnte, haben wir eine gute Lösung für unsere Kanzleiabläufe gesucht und gefunden.

Was genau ist eine E-Invoice?

Ein elektronisches Dokument, das den automatischen Datentransfer von Rechnungen und Aufträgen zwischen Unternehmen erleichtern soll. Getrieben ist das Ganze vom Steuerrecht. In Deutschland gibt es zwei relevante Formate: X-Rechnung und ZUGFeRD. Die X-Rechnung ist für Menschen kaum lesbar, enthält (potentiell) mehr klerikale Angaben und ist vor Allem für den Austausch mit Behörden vorgesehen. Das deutsche ZUGFeRD ist ab Version 2.1 gültig. Alternativ wäre auch ein anderes europäisches Format möglich, beispielsweise das französische Factur-X (inzwischen identisch mit ZUGFeRD) oder das italienische FatturaPA.

Eine E-Invoice nach ZUGFeRD ist ein PDF-Dokument, das mit einem üblichen Programm angesehen oder ausgedruckt werden kann, in das aber ein XML-Dokument mit maschinenlesbaren Daten eingebettet ist und an das eine XML-Erläuterungsdatei angehängt ist. Das XML-Dokument ist nach einem von mehreren vorgegebenen Profil aufgebaut, wobei jeweils ein Profil von einem nächst komplexeren Profil umfasst ist: Basic ⊆ Comfort ⊆ Extended. Wer was braucht, richtet sich nach der Größe des Unternehmens und der Komplexität der Rechnungen.

Die sichtbaren Informationen im PDF und die strukturierten Daten in der eingebetteten XML-Datei werden übrigens nicht durch das Datenvormat synchron gehalten, dafür ist der Erzeuger der Datei selbst verantwortlich. Bei Widersprüchen ist so weit ich weiß der XML-Teil verbindlich.

Eine erzeugte E-Invoice kann mit einem von zahlreichen Validatoren überprüft werden. Es gibt herunterladbare Programme oder Online-Lösungen, beide in kostenlosen und kommerziellen Varianten. Nicht alle Validatoren arbeiten gleich und manches Dokument passiert den einen, aber nicht den anderen Test. Es gibt auch Dokumente, die von dem ZUGFeRD-Validator verworfen werden, aber nach dem Standard korrekt sind und umgekehrt. Derartige Schwierigkeiten bestehen übrigens mit praktisch allen Standards.

Erzeugen einer E-Invoice

Das ZUGFeRD-Gremium ging bei der Konzeption des Standards davon aus, dass praktisch jedes bestehende Verarbeitungssytsem PDF-Dateien erzeugen kann und dass man eine XML-Datei notfalls auch manuell in einem Texteditor bearbeiten kann. Für beide Teile wurden genaue Vorgaben entwickelt, die in den geltenden Standard 2.1 mündeten. Details zur Integration auf Dateiebene finden Sie am Ende dieses Artikels.

Das Zusammenfügen beider Teile ist nicht ganz einfach, jedenfalls etwas, was die meisten grafischen PDF-Tools nicht beherrschen. Von ZUGFeRD werden zu diesem Zweck Skripten und ein Server angeboten. Die sind leider nicht kostenlos, nicht für alle relevanten Betriebssysteme geeignet und daher für uns uninteressant. Außerdem stellt ZUGFeRD einen Validator zur Verfügung, mit dem nachgewiesen werden kann, ob eine Rechnung den Vorgaben entspricht.

Software

Wenn Sie für Ihre Organisation eine etablierte Software-Lösung verwenden, kümmert sich Ihr Anbieter um die Integration. Haben Sie eine eigene Lösung oder arbeiten Sie ohne integriertes Verwaltungssystem beispielsweise mit Tabellen, brauchen Sie neue Software.

Aktuell gibt es sehr viele Anbieter, die Ihnen Dienstleistungen oder Software zur E-Invoice andrehen möchten. Seien Sie wachsam, die meisten Angebote sind Mist. Online-Lösungen erfordern immer, dass Sie Ihre Rechnungsdaten dem Dienstleister bereitstellen. Das dürfte nicht nur aus Gründen des Datenschutzes, sondern auch des Standesrechts unzulässig sein. Anbieter von bei Ihnen ablaufender Software trachten gerne danach, Produkte gebündelt zu vertreiben. Wenn Sie Glück haben, installieren Sie zusätzliche Software, die Sie nicht brauchen; wenn Sie Pech haben, bekommen Sie Malware.

Vermeiden Sie auf jeden Fall ein Lock-In, das es Ihnen praktisch unmöglich macht, eine Software wieder loszuwerden. Ein solcher beginnt meistens, indem Sie mehr als eine Software aus dem gleichen Haus benötigen, ein Abonnement abschließen oder “in die Cloud gehen”. Misstrauen Sie Herstellern mit einer schlechten Repuation, die haben die nicht von Ungefähr.

Open Source ist eine gute Idee, das ist nicht nur kostenlos, sondern vor Allem für Sie einsehbar, sodass Sie nachprüfen können, was Sie bekommen und was die Software genau macht. Erforderlichenfalls können Sie die Anpassungen oder Änderungen selbst vornehmen oder jemanden dazu beauftragen.

Bedenken Sie, dass eine Software von weiterer Software abhängen kann. Nimmt die Gesamtlösung größere Ausmaße an, haben Sie neue Probleme, denn jedes Teil des Geflechts wird einzeln gepflegt und weiterentwickelt, sodass Sie 1.) laufend updaten sollten und 2.) eine beträchtliche Angriffsfläche für mögliche Fehler oder Sicherheitslücken haben. Erinnern Sie sich zum Beispiel an Log4J? Ein vermeintlich einfacher Logger, der sich als Einfallstor für jede Art von Ungeziefer entpuppte.

Wählen Sie daher eine schlanke Lösung mit wenigen Abhängigkeiten. Geht der Funktionsumfang einer Lösung zu weit über Ihr ursprüngliches Problem hinaus, sollten Sie sich nach Alternativen umsehen. Vorteilhaft ist, wenn eine Lösung schon eine gewisse Nutzerbasis hat, dann ist man mit seinen Problemen nicht allein und der Maintainer ist vielleicht motivierter. Gut ist auch, wenn die Software nicht erst seit gestern existiert und wenn man erkennen kann, dass sie über die Zeit betreut wurde.

Anforderungen

Derzeit werden unsere PDF Rechnungen auf dem Server aus einem DOCX-Template erstellt und am Arbeitsplatz auf Papier oder in eine Datei gedruckt. Um bei der Erstellung der E-Invoice mehrfache Übertragungen von Teildokumenten zwischen dem Server und einem Arbeitsplatz zu vermeiden, möchten wir gerne alle Schritte auf dem Server ausführen.

Der Server tut sich schwer mit der Erstellung eines PDF aus einem Format wie DOCX oder ODF. PDF ist ein reines Anzeigeformat und ein Dokument kann ziemlich komplex werden. Zur Umwandlung verwendet man am besten ein Programm, das in beiden Welten zuhause ist, hier also MS Word oder Open Office. Für ODF gibt es sowieso keinen anderen Renderer und DOCX ist ein so verschwurbeltes Format, dass Ärger vorprogrammiert ist. MS Word läuft nicht auf einem Unix-artigen Betriebssystem. Beide Office-Schwergewichte sind so komplex, dass sie bezüglich Stabilität, Fehleranfälligkeit und Angriffsfläche für Malware auf dem Server nichts verloren haben. Sicher könnte man über ein Office-Paket in einem abgeschlossenen Container (z. B. Docker) nachdenken, eine elegante und angemessene Lösung wird das aber nicht mehr.

Wir haben uns daher entschlossen, den bestehenden Template-Mechanismus durch eine andere Lösung zu ersetzen, die vollständig auf dem Server abläuft. Wir nehmen dabei in Kauf, dass die erstellte E-Invoice am Arbeitsplatz nicht mehr editierbar ist. Um eine einzelne Schwachstelle (single source of failure) zu vermeiden, gibt für die Rechnungserzeugung noch einen Plan-B, dazu später mehr.

Unsere Lösung

Die XML-Datei wird bei uns auf der Basis eines XML-Templates mit TBS erzeugt. TBS ist eine in PHP geschriebene Template-Engine und liegt in Version 3.15.2 vor. TBS ist Standalone, erfordert also keine weitere Software, und kommt mit winzigen 172 kByte aus. Wir haben mit TBS bereits gute Erfahrungen beim Verarbeiten von DOCX/ODT-Dateien gemacht. Ein weiterer Schwerpunkt von TBS ist die Bearbeitung von HTML-Dateien, was (mehr oder weniger) als Dialekt von XML angesehen werden kann. Für unsere Zwecke ist die Software also hervorragend geeignet.

Das XML-Template ist aus einer ZUGFeRD Beispieldatei (Profil: Basis) generiert, indem informationstragende Einträge durch Tags ersetzt wurden, die von TBS erkannt und beim Ausführen mit dynamischen Informationen gefüllt werden können. TBS beherrscht das verschachtelte Ersetzen, sodass beispielsweise ein Tag mit einer Tabelle ersetzt werden kann, die so viele Zeilen hat, wie Rechnungsposten vorhanden sind, und wobei in jeder Zeile ein Beschreibungstext und ein Betrag stehen. Sehr hilfreich ist auch die Möglichkeit, für eine Ersetzung eine Methode einer Klasse aufrufen zu lassen. Man gibt also nicht an “ersetze A durch B”, sonderen “wenn Du A findest, ersetze es durch das Ergebnis folgender Methode”. Das erlaubt deutlich flexiblere und komplexere Ersetzungen. Beispielsweise können in Abhängigkeit des Landes des Rechnungsempfängers unterschiedliche Datumsformate verwendet werden.

Das PDF wird auf dem Server mit FPDF erstellt,das von Olivier Plathey geschrieben wurde und seit ca. 2011 (?) besteht. Es nutzt PHP und liegt in der Version 1.8 vor. Es ist keine weitere Software erforderlich, mit Ausnahme von Zlib, um Inhalte zu komprimieren und GD, um GIFs einzubinden (beides optional). FPDF ist sehr populär, liegt zahlreichen weiteren OpenSource-Paketen zu Grunde und wurde u.a. nach Python portiert. Die Software ist Freeware (aka. “Free-PDF”), es gibt keinerlei Einschränkung für die private oder kommerzielle Nutzung. Es besteht eine aktive Community, die viele hilfreiche Skripte beigesteuert hat. Unsere Anfrage hat Olivier Plathey sehr schnell und kompetent beantwortet.

Zur Erstellung der E-Invoice beginnen wir mit einem Template im PDF-Format. Das Template enthält unser Logo, die Bankverbindung und andere statische Informationen und ist mit einem üblichen Programm erstellt. Rechnungsposten und andere individuelle Informationen werden auf der Basis unserer Fakturierungsdaten mit Methoden von FPDF ins Template eingefügt und tabellarisch formatiert. Seitenumbrüche und Seitenzahlen werden automatisch verwaltet. Für die E-Invoice muss das PDF in Version PDF/A-3 erstellt werden, was bedeutet, dass verwendete Schriften ins Dokument eingebettet werden müssen. FPDF enthält ein Skript (makefont), mit dem eine TTF-Schriftendatei für die Einbindung vorbereitet werden kann.

Mittels eines FPDF-Plugins wird die zuvor erstellte XML-Datei standardkonform in das erstellte PDF eingebunden. Das Ergebnis besteht Tests mit allen relevanten Validatoren.

Plan-B

FPDF und TBS sind in PHP geschrieben, was leicht auf einem Arbeitsplatzrechner installiert werden kann. Im Fehlerfall kann man eine Rechnung damit auch lokal erstellen. Informationen, die in die Rechnung einfließen sollen, können z. B. in einer Textdatei angegeben werden.

Plan-C

Sollte die automatische Erstellung aufgrund eines Logikfehlers nicht funktionieren, kann die XML-Datei mit einem Texteditor erstellt werden und der PDF-Teil mit einem beliebigen Programm. Beide Teile können mit FPDF zusammengefügt werden.

Plan-D

Falls nicht mal PHP mehr geht, besteht mit akretion/factur-x eine lokal ausführbare Alternative. Es handelt sich um Python-Skripte zur Erstellung der XML-Datei und zur Integration mit einem bestehenden PDF. Hier wird das XML-Dokument nativ erstellt und nicht per Ersetzungen aus einem Template generiert.

Mit WeasyPrint besteht eine weitere Python-Bibliothek zur Umwandlung von HTML in PDF, sodass HTML-Templates zur Erstellung des PDF-Teils verwendet werden können. Es gibt einen aktuellen Pull-Request zur ZUGFeRD-konformen Integration von XML-Daten.

Plan-E

Mit der E-Invoice gibt es keine Rechner-lose Rechnungsstellung mehr. Sollte Ihre Computer-Infrastruktur nicht mehr verfügbar sein, können Sie nicht mit Methoden wie Stift und Papier weiterarbeiten.

Anhang: wie kommt das XML ins PDF?

Eine PDF-Datei folgt einer Struktur, die in Standards festgelegt ist, die von der PDF Association gepflegt werden. Dazu ein paar nützliche Links:

Eine E-Invoice nach ZUGFeRD legt innerhalb eines gültigen PDF eine gewisse Struktur fest. Der Leitfaden klärt auf:

  • Das Dokument muss dem PDF/A-3 Standard folgen, ist also schon ohne XML-Dateien lesbar, anzeigbar und druckbar. Das Dateiformat ist üblicherweise PDF/A-3b für Basic; alternativ auch PDF/A-3a für Accessible, also barrierefrei, oder PDF/A-3u für Unicode
  • Eine XML-Datei mit Bezug auf das gesamte Dokument, die über eine Beziehung vom Typ “Alternative” eingebettet ist. Hierzu benötigt die Datei (bzw. der Stream nach PDF-Sprech) einen Eintrag in einer Datenstruktur namens File Specification Dictionary.
  • Ein spezifisches XMP Erweiterungsschema (eine vorgegebene XML-Beschreibungsdatei) zur Beschreibung des Dokuments als ZUGFeRD-konforme Rechnung sowie der XMP Metadaten

Wichtig ist, dass die XML-Datei eingebettet (embedded) ist. Die XMP-Datei ist hingegen angehängt (attached). Um eine standardkonforme E-Invoice zu erstellen, muss man also auf der Ebene von PDF-Primitiven arbeiten und kann nicht etwa eine XML-Datei mit einem üblichen visuellen Editor an ein bestehendes PDF anfügen. ZUGFeRD macht noch weitere Vorgaben, beispielsweise dass keine passwortgeschützten Inhalte vorhanden sind, keine aktiven Komponenten, keine Multimedia-Dateien und so weiter.

  1. Alle Angaben dieses Blogs und insbesondere dieser Seite sind ohne Gewähr ↩︎

Mehr News vom Zweibrücken-IP Blog

Immer auf dem aktuellen Stand bleiben: Hier finden Sie alle News aus dem Hause Zweibrücken IP. Von aktuellen Bewegungen im Patentrecht, über kanzlei-interne Neuigkeiten, hinzu Kommentaren.

Zum Blog