ZUGFeRD PDF Rechnungen mit LibreOffice - einfach durch Ausdrucken - erstellen!

Deutsch
,
#1

Hallo liebe Community!

Da ich denke das das Thema in der Zukunft für den ein oder anderen Rechnungsschreiberling mit LibreOffice Writer und Calc …also so wie ich das auch mache :slight_smile:, interessant werden dürfte…anbei ein Link zu einer Lösung die ich eben mal probiert habe.

Nun - geht. Hab es mal getestet…Die erzeugte PDF ZUGFeRD Rechnung ist “valide” und entspricht den gesetzlichen Normen und Schema, hab es bereits mit 3 Validatoren geprüft.

Die Einrichtung ist super einfach…danach Rechnung einfach ausdrucken …fertig!

LG!!

#3

Und dafür lädst Du Rechnungen auf den Server www.7-pdf.de hoch? Warum traust Du denen?

#4

Na ja, der Link führt erst einmal zu einer Version, die auf einen Windows-Rechner herunter geladen wird und wohl als Drucker in LibreOffice mit eingebunden wird. Es geht also nicht um den Upload und Download, der für Firmen sowieso indiskutabel sein sollte.

In der FAQ der Seite ist dann zu erfahren, dass das Ganze ca. 93,76 € ohne Validator kostet und darüber hinaus für einen Invoice Instractor monatlich 3,90 € anfällt.

#2

Die kostenlose Lösung für LibreOffice gibt es allerdings hier: https://wiki.documentfoundation.org/images/d/d5/XRechnung_Extension_2502.zip

Und die kann neben der Erstellung von XRechnungen, erweiterten XRechnungen und ZUGFeRD-Rechnungen auch das Einlesen von Rechnungen, die archivierte Ablage von Rechnungen usw. Inzwischen auch als Serverversion zusammen mit der MariaDB/MySQL und mit der Möglichkeit, englischsprachige Rechnungen automatisch für Länder zu erstellen, die nicht DE, AU oder CH sind.

#5

Hey zusammen,

ich wollte nochmal kurz auf ein paar Rückfragen eingehen – vor allem zur Frage mit dem Upload und auch im Vergleich zur LibreOffice-Erweiterung (XRechnung Extension).

:white_check_mark: Ja, es wird etwas hochgeladen – aber datenschutzkonform

Ich habe die Lösung selbst getestet: Man druckt seine Rechnung in LibreOffice über den 7-PDF Printer – und dieser übermittelt die erzeugte PDF dann an einen deutschen Server, wo die XML nach ZUGFeRD/XRechnung erzeugt und zurückgeliefert wird.

Das Ganze läuft verschlüsselt (https), und laut Info auf der Seite:

  • werden die Daten nicht gespeichert
  • es gibt keine Cloudanbindung
  • der Betreiber ist ein deutsches Einzelunternehmen mit persönlicher Haftung (also keine GmbH oder große Firma)

Ob man das möchte, muss man natürlich selbst abwägen. Für mich klang das vertretbar – ähnlich wie bei ELSTER, Banking-App, E-Mail-Dienst, DATEV, sevdesk, etc.

:arrows_counterclockwise: Vergleich zur XRechnung-Erweiterung für LibreOffice

Ich finde es super, dass es mittlerweile auch diese XRechnung Extension gibt. Aber nach meinem Verständnis richtet die sich eher an technisch versierte Nutzer:innen.

Man braucht:

  • Grundkenntnisse im XML-Bereich
  • eventuell MariaDB/MySQL
  • und Tools für das Einbetten der XML in PDF/A-3

Dafür ist das Ganze natürlich kostenlos und Open Source, was ich klasse finde!

Die getestete Lösung von 7-PDF richtet sich eher an Leute wie mich, die:

  • Rechnungen optisch sauber in Writer oder Calc gestalten
  • und dann einfach über “Drucken → fertig” zur E-Rechnung kommen wollen

:pushpin: Fazit (meine persönliche Meinung)

Beide Lösungen haben ihre Zielgruppe:

  • Wer technisch fit ist, lieber alles selbst kontrolliert und gerne bastelt: LibreOffice-Extension.
  • Wer einfach „aus LibreOffice heraus eine gültige ZUGFeRD-Rechnung erzeugen“ will – mit WYSIWYG-Rechnung, ohne viel Setup: die Drucker-basierte Lösung.

Ich fand’s angenehm simpel – und meine Testrechnung war laut drei Validatoren valide (EN 16931 / ZUGFeRD 2.1).

Grüße!

#6

  • Grundkenntnisse im xml-Bereich sind bei der XRechnung-Erweiterung nirgendwo gefragt.

  • Die interne Firebird-Datenbank ist zur Zeit bei den meisten Leuten die erste Wahl. Die Servervariante wird in größeren Firmen nachgefragt.

  • Natürlich erzeugt die XRechnung-Erweiterung im Writer eine ansehnliche Rechnung. Sie wird mit den Daten gefüttert, die zu der Rechnung gehören und lädt das dann in eine entsprechende Vorlagendatei.

  • Die Einbindung von Dateien in PDF-Dateien nach dem Standard, der für ZUGFeRD erforderlich ist, gelingt leider mit LibreOffice nicht direkt. Auch andere Tools schaffen das nicht (wie tkpdf - da wird zwar eingebunden aber die interne Datei kann nicht in Quba angezeigt werden)

Wenn ich das bei der 7-PDF-Version richtig verstanden habe arbeitet die mit KI. Du verlässt Dich dann darauf, dass das, was in Deiner eigentlichen Rechnung steht, auch in der erstellten xml-Datei steht. Dass die Datei gültig ist bedeutet ja nicht, dass die Daten denen entsprechen, die Du in Deiner Rechnung hast. Ich würde tunlichst den Inhalt mittel Quba Viewer überprüfen. Da hast Du bei einer korrekten ZUGFeRD-Datei die PDF-Datei auf der einen Seite, die ausgelesenen Inhalte der xml-Rechnung auf der anderen Seite.

Ich erinnere nur an die Stadt im Münsterland, die für 2 Feuerwehrwagen nach einer xml-Rechnung bezahlt hat - nur war in der xml-Rechnung die IBAN ausgetauscht worden: Stadt Dülmen überweist 400.000 Euro an Betrüger - Nachrichten - WDR

#7

Danke für die Ergänzungen, Robert – super wichtig und berechtigt!

Zur XRechnung-Erweiterung: Ich hatte mich vor allem auf die MariaDB-Variante bezogen, weil die im Thread vorher genannt wurde. Dass Firebird mittlerweile Standard ist und keine XML-Kenntnisse nötig sind, ist natürlich ein klarer Pluspunkt – danke für die Korrektur! :+1:

Zur 7-PDF-Lösung mit KI:
Ich verlasse mich dabei nicht blind auf die erzeugte XML-Datei. Genau deshalb habe ich die generierten Rechnungen mit dem:

  • Quba Viewer
  • ZUGFeRD Viewer
  • und dem offiziellen KoSIT Validator

nochmal manuell geprüft.

Mein Testergebnis:

  • Alle Inhalte wurden korrekt übernommen:
    • Beträge, Rabatte, Zuschläge
    • USt, Reverse-Charge (IGL), steuerfreie Leistungen
    • IBAN & BIC
    • sogar eine englischsprachige Rechnung wurde korrekt verarbeitet
  • Die XML war visuell deckungsgleich mit dem PDF-Inhalt
  • Validierung erfolgreich nach EN 16931 / ZUGFeRD 2.1

Ich stimme dir aber völlig zu:
Gültigkeit heißt noch lange nicht, dass die Inhalte korrekt sind.
Ein Validator prüft das XML-Schema, aber nicht, ob jemand z. B. die IBAN ausgetauscht hat – siehe dein Beispiel aus Dülmen.

Gerade bei größeren Beträgen oder automatisierter Verarbeitung sollte man den XML-Inhalt unbedingt visuell gegenprüfen – egal ob per Hand erstellt, mit Makros gebaut oder per KI generiert.

Der Validator von 7-PDF selbst (hab die Trial ausprobiert) kann übrigens auch:

  • Schema-Validierung
  • PDF/A-3 Konformität prüfen
  • GUI und CLI nutzen

Fazit (für mich persönlich):
Für kleinere Firmen oder Solo-Selbstständige, die 1–2 E-Rechnungen im Monat schreiben, war das ein sehr angenehmer Workflow:

LibreOffice-Rechnung → Drucken → XML wird eingebettet → Validieren → Fertig

#8

Roberts Lösung:

  • Datenbankdokument und Formular öffnen.
  • Rechnung eintragen.
  • Schaltfläche klicken.

Ergebnis ist 1 odt, 1 pdf, 1 xml

Die Rechnungsdaten (was, wann, wie, an wen, zu welchen Konditionen) sind in der Datenbank gespeichert. Rechnungsnummern werden autom. erzeugt. Aus den Daten kann jede Rechnung zu jeder Zeit neu erzeugt werden.

Du müsstest wohl noch eine Vorlage für Dein persönliches “Rechnungspapier” (den PDF-Ausdruck) vorbeireiten.

#9

Danke für die Ergänzung, Villeroy – ich finde es gut, dass ihr da eine richtig durchdachte Datenbanklösung aufgebaut habt.

Die Idee, alle Rechnungsdaten strukturiert zu speichern und auf Knopfdruck wiederherstellen zu können, ist natürlich stark – für ein Unternehmen mit festen Strukturen sicher super sinnvoll.

Aber (wirklich nicht wertend gemeint):
Nicht jeder arbeitet so organisiert – oder will das.
Manche schreiben 1–2 Rechnungen im Monat, gestalten die in Writer oder Calc und möchten sie einfach direkt als ZUGFeRD konform drucken – ohne Datenbank, Masken, Formularlogik oder Seriennummernverwaltung.

Für solche Fälle – also eher „visuelles Schreiben + rechtssicher drucken“ – war die getestete Lösung überraschend pragmatisch.

:file_folder: Thema Archivierung und GoBD

Was man (ganz unabhängig von der Lösung) nie vergessen darf:

GoBD-Konformität heißt auch: Archivierung in unveränderbarer Form

Auch bei einer Datenbanklösung gilt: Wenn Rechnungen jederzeit neu erzeugbar und änderbar sind, muss zusätzlich sichergestellt werden, dass das Original (z. B. PDF/A-3 mit eingebetteter XML)

  • revisionssicher archiviert,
  • unveränderbar abgelegt
  • und für die Dauer der Aufbewahrungspflicht auffindbar ist.

Die getestete Drucklösung erzeugt ein PDF/A-3 mit eingebetteter XML, das direkt:

  • lokal validiert werden kann (via Quba, KoSIT, ZUGFeRD Viewer etc.)
  • und an ein DMS oder Archivsystem übergeben werden kann

:gear: Und falls’s größer wird…

Was ich richtig spannend fand:

Die Lösung ist voll automatisierbar, auch via Kommandozeile

D. h. sobald man mehr Volumen hat, kann man auch:

  • PDF + XML im Hintergrund erzeugen lassen
  • per Skript oder Printjob direkt ans Archivsystem übergeben
  • auf Wunsch ohne GUI, ohne Zutun

Und gerade die Anbindung via PDF-Drucker ist da oft ein Vorteil – weil viele Archiv- oder ERP-Systeme genau auf diesen Workflow setzen (Drucken → Archivieren).

:brain: KI? Ja – aber mit Sicherheitsnetz!

Ein häufiger Einwand lautet:

„Wenn da KI mitmischt – kann die nicht falsche Daten in die XML schreiben?“

Ja, kann sie – theoretisch.
Aber die getestete Lösung bringt gleich mehrere Sicherungsmechanismen mit:

  1. :white_check_mark: Visuelle Kontrolle
    Die erzeugte PDF/A-3 mit eingebetteter XML lässt sich mit dem Quba Viewer, KoSIT-Validator oder dem ZUGFeRD Viewer öffnen und vergleichen
    → Man sieht sofort, ob Beträge, IBANs, Texte und Positionen korrekt übertragen wurden.

  2. :white_check_mark: Automatische Validierung
    Ein eigener 7-PDF E-Invoice Validator (auch CLI-fähig) prüft das Ergebnis:

    • ZUGFeRD- oder XRechnung-konform?
    • PDF/A-3 konform?
    • Optionaler Teil automatisierter Verarbeitungspipeline

  3. :white_check_mark: Integrierte Plausibilitätsprüfung
    Der KI-Service selbst prüft:

    • Stimmen Summen, Steuerbeträge, Positionswerte?
    • Sind Einheiten, Währungen und Gesamtsummen stimmig?

    ➤ Wenn die Rechnung rechnerisch nicht plausibel ist, wird keine XML erzeugt.

Ich finde es ehrlich super, dass es beide Wege gibt – denn am Ende zählt doch:
Rechnung normkonform → Kunde kann verarbeiten → prüfungssicher archiviert → fertig.

#11

Das ist zu 100% Roberts Verdienst, und man kann es auch gleich richtig machen, anstatt das über eine Online-Verbindung eine KI erledigen zu lassen. Das Datenbankformular funktioniert mit einer Rechnung pro Jahr oder tausend Rechnungen am Tag.

#12

Danke dir für die Ergänzung, Villeroy!

Dass das Datenbankformular skaliert – von 1 bis 1.000 Rechnungen – absolut unbestritten.
Und es ist klasse, dass durch Roberts Arbeit da ein richtig solides Werkzeug entstanden ist! :+1:

Was ich aber eben auch gut finde:

Dass es eben nicht den einen „richtigen“ Weg gibt – sondern verschiedene Ansätze, je nach Zielgruppe und Bedarf.

Ich persönlich hatte einfach einen anderen Einstiegspunkt:

  • :writing_hand: Ich gestalte meine Rechnungen bewusst im Writer/Calc – so wie sie beim Empfänger aussehen sollen
  • :jigsaw: Und ich wollte eine Lösung, die meinen vorhandenen Workflow ergänzt, nicht ersetzt
  • :closed_lock_with_key: Dabei war mir Datenschutz und lokale Validierung genauso wichtig wie Prüfbarkeit und Archivierung

Und ja, die getestete Lösung arbeitet mit KI – aber nicht ohne Sicherheitsnetz:

  • :white_check_mark: Visuelle Kontrolle: Quba Viewer, ZUGFeRD Viewer, KoSIT Validator
  • :white_check_mark: Schema- und PDF/A-Validierung (lokal & automatisiert via CLI möglich)
  • :white_check_mark: Plausibilitätsprüfung durch den Dienst selbst – inkl. Rechenprüfung
  • :no_entry_sign: Keine XML-Ausgabe, wenn Daten widersprüchlich oder unstimmig sind

:package: Und: Die Lösung erzeugt sofort ein PDF/A-3 mit eingebetteter XML, das archiviert und weiterverarbeitet werden kann – inkl. direkter Übergabe ans DMS oder Archivsystem (z. B. via Printjob).

Fazit aus meiner Sicht:

Wer lieber „gestaltet & druckt“ statt „formuliert & speichert“, findet hier einen gut abgesicherten, einfachen Einstieg.

Und das Schöne ist: Man kann ja beide Ansätze ausprobieren – und selbst entscheiden, was besser zum Alltag passt. :wink:

Viele Grüße!

#10

:raising_hand_man: Persönlich wichtig war mir bei der getesteten Lösung:

  • Dass ich schnell loslegen konnte – ohne Setup-Marathon
  • Dass die Rechnung so aussieht, wie ich sie gestaltet habe (WYSIWYG)
  • Dass die Lösung nicht auf große Cloudanbieter setzt, sondern auf einen deutschen Anbieter mit klarer Kommunikation
  • Dass ich prüfen kann, ob alles stimmt – und nicht einfach „blind vertraue“

Süsse Träume allen hier im Forum!!

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.