In Teil 1 habe ich mich mit der elektronischen Rechnung als ZUGFeRD und XRechnung befasst und in Teil 2 habe ich einen Abriss möglicher Lösungen zur Erzeugung und Anzeige solcher Rechnungen gegeben. In Teil 3a wurde die von mir gewählte OpenSource-Lösung Fakturama im "hands on" vor gestellt. In Teil 3b gehe ich auf den letzten Teil der Konfigurierung ein und zeige auf, wo es leider immer noch haptert.
Erste Einrichtungsschritte – so geht's schneller
Nach der Erstinstallation, die bei mir unter Windows 10, mit bereits installiertem Amazon Corretto (JAVA) und LibreOffice, problemlos ablief, bin ich aber erst einmal "gegen die Wand gelaufen", da ich vor lauter Bäumen den Wald nicht mehr gesehen habe. In einer VM lief Fakturama zwar, aber die "Rechnungen" wurden als Mini-Icon angezeigt. Auf dem späteren Windows 10-Produktiv-System hatte ich plötzlich Brutto-Preise für Lieferungen einzugeben und ansonsten bin ich auch heftig in Probleme gelaufen. Nach ca. einem Tag Einarbeitung glaube ich, die größten Hürden genommen zu haben. Daher hier mein "Waschzettel" mit Anmerkungen, was ich hätte vorher wissen sollen.
Zuerst Einstellungen für LibreOffice, XRechnung etc. vornehmen
Als erstes empfehle ich, in Fakturama unter Datei – Einstellungen das betreffende Einstellungsfenster aufzurufen. Unter Dokumente findet sich eine Option, wo man Netto-Werte für Preise in Artikellisten vorgeben kann (Standard war bei mir auf Brutto eingestellt).
Dann sollte unter Office-Integration der Pfad für die Integration von LibreOffice kontrolliert werden. Nachfolgender Screenshot zeigt, dass der Standardwert auf ein falsches Verzeichnis verweist – das musste ich korrigieren.
Ohne gültige Faktuara LibreOffice-Integration klappt später das Drucken nicht – da habe ich einige Zeit mit Fehlersuche zugebracht, da die Druckfunktion nur einen Fehler auf fehlendes Office lieferte.
Anpassen der ZUGFeRD-Einstellungen
Eine weitere Falle war für mich auch, dass ich mit den ZUGFeRD-Einstellungen herum experimentiert hatte, weil das Drucken nicht klappen wollte, sondern mit einer Export- oder Druckfehlermeldung abbrach.
Obiger Screenshot zeigt meine Einstellungen, die ich inzwischen verwende. Sollte eine gültige ZUGFeRD-Rechnung mit XML-Anteil erzeugen.
Wenn es Druckfehler beim Export gibt
Es gibt noch ein nerviges Problem in Fakturama, weil der Druck von ZUGFeRD-Rechnungen per LibreOffice-Writer passiert. Immer, wenn ich im Writer die Vorlage für die für mich angepasste Rechnung geändert habe, scheiterte der Rechnungsdruck im Anschluss (es kommt nur ein Dialogfeld mit einem Hinweis auf einen Exportfehler).
Gemäß diesem Forenthread und dem folgenden Hinweise auf Seite 60 im Faktorama-Handbuch, muss im LibreOffice die Erstellung von PDF/A dauerhaft aktiviert werden, um ein gültiges PDF zu erzeugen. Dies erreicht man, indem einmalig eine beliebige Writer-Datei ins PDF-Format konvertiert wird. Dabei ist in den Einstellungen anzugeben, dass PDF/A zu erstellen ist.
Ich rufe dann im LibreOffice Writer im Menü Datei den Befehl Exportieren als – Als PDF exportieren auf. Dann kann ich die in obigem Screenshot unter "Allgemein", "Archiv (PDF/A …" angegebene PDF/a-3b wählen und auf Exportieren klicken. Danach funktionierte bei mir der Rechnungsdruck.
Anlegen Mehrwertsteuer, Debitoren, Waren, Rechnungen
Bevor man loslegen und Rechnungen drucken kann, sollte man in Fakturama im Fenster Einträge für Steuersätze, Debitoren (also Kunden), Kontakte und möglichst Produkte anlegen. Das ist gemäß nachfolgendem Fenster über die Einträge der Symbolleiste oder über die linke Seitenleiste möglich.
Hier bin ich derzeit noch am Lernen, wie das alles bestmöglich funktioniert – manches ist halt "a bisserl sperrig" (z.B. keine Pull-Down-Auswahllisten, keine Kontextmenüs etc.).
Anpassen der Vorlage(n)
Fakturama wird mit einem Satz an LibreOffice .ott-Vorlagen für Angebote, Rechnungen etc. ausgeliefert. Diese müssen an die eigenen Bedürfnisse und Vorstellungen angepasst werden. Ich habe mir die Fakturama-Ordner auf eine separate Partition legen lassen. Die Dokumentdateien wie Rechnungen etc. finden sich im Unterordner
Fakturama/Dokumente
wobei dort der Unterordner ODT für die Writer-Dokumente und PDF für die PDF-Ausgaben stehen. Darunter findet sich ein Unterordner für das Jahr (z.B. 2026) mit weiteren Unterordnern für Rechnungen, Angebote etc.
Die Vorlagen finden sich im Ordner Vorlagen, wobei der Ordner Rechnung für die Rechnungserstellung interessiert (siehe obige Abbildung). Die Datei Document.ott ist die Fakturama-Vorlage, ich habe mir Kopien davon im Ordner erstellt und diese dann benannt. Diese Namen werden mir beim Rechnungsdruck zur Auswahl angeboten (mit nur einer Datei habe ich die Situation, dass sich beim Drucke oft nichts tut).
Obiger Screenshot zeigt die ursprüngliche Rechnungsvorlage .ott, die ich dann für meine Zwecke angepasst habe. Die Felder im Writer-Dokument sollte man nur anfassen, wenn man weiß, was man tut. Über diese Felder wird später das Dokument mit Inhalten gefüllt und die XML-Datei im ZUGFeRD-Dokument erzeugt.
Hier hält die Vorlage von Fakturama in meinen Augen noch eine Falle bereit. Ich hatte in Fakturama eine Rechnung mit Netto-, MwST- und Brutto-Beträgen, die auch stimmig war, angelegt, und bekam eine wunderbare ZUGFeRD-Rechnung als PDF. Aber dann sah ich, dass im PDF nur der Bruttobetrag und die enthaltene Mehrwertsteuer angezeigt wurde. Zwar korrekt, aber meine Kunden erwarten Netto-Beträge, Netto-Summe, Mehrwertsteuer und dann den Brutto-Wert.
Eine schnelle Internetsuche half mit in der Fakturama-Community weiter – hier steht "Dann mußt Du die Platzhalter in der Vorlage entsprechend anpassen. Steht auch im Handbuch (NET statt GROSS)." Genau so ist es, die Felder:
<DOCUMENT.ITEMS.GROSS>
in der Rechnung müssen in:
<DOCUMENT.ITEMS.NET>
geändert werden. Danach wurden mir die Rechnungsdaten auch im PDF-Teil der ZUGFeRD-Rechnung so ausgewiesen, wie ich sie erwartete habe. Alles weitere ist dem Fakturama-Handbuch zu entnehmen oder findet sich in Antworten in der Fakturama-Community.
Im Nachgang habe ich noch diesen Beitrag gefunden, in dem jemand einen schnellen Einstieg in Fakturama skizziert.
Fakturama scheitert bei ZUGFeRD
Ergänzung: Nach einigen Tagen intensiver Nutzung bin ich zum betrüblichen Schluss gekommen, dass Fakturama aktuell (Ende Januar 2026) leider nicht für ZUGFeRD-Rechnungen verwendbar zu sein scheint. Es ist irgendwie arg kompliziert – Fakturama läuft hier, wie ich das so haben wollte und erzeugt auch Rechnungen im ZUGFeRD-Format. Soweit so gut – ich war zufrieden.
Zur Sicherheit habe ich dann diese Rechnung noch, wie in Lösungen zum Empfang und Erzeugen von ZUgFeRD-Rechnungen – Teil 2 erwähnt im Quba-Viewer sowie OpenIndex ZUGFeRD-Manager validieren lassen. Mir wurde gemeldet, dass da alles in Ordnung sei.
Leider meldete sich ein Kunde am Ende des Tages mit dem Hinweis, dass meine ZUGFeRD-Rechnung nicht validierbar sei und von deren System abgewiesen werde. Ich habe einige Tests durchgeführt, und auch den XML-Teil abgetrennt, um diesen beim s E-Rechnungs-Validator-Portal von Baden-Württemberg prüfen zu lassen. Es gab zwar Warnungen, aber die Annahme wurde dort empfohlen.
Am Ende des Tages habe ich dann die Validierung auf ecosio.com vornehmen lassen (die sagen zu, dass die Rechnungen nicht im persistenten Speicher gespeichert und nach der Validierung sofort verworfen werden). Die Validierung ist kostenlos und die Seite bietet ausführliche Validierungsoptionen. Ich habe die automatische ZUGFeRD-Validierung als Option gewählt, bekam aber immer Validierungsfehler angezeigt – die XML-Struktur ist valide, aber die Inhalte entsprechen nicht den Vorgaben.
Ich habe einige Tests durchgeführt – derzeit entsprechen bestimmte Werte (Entities) in den XML-Elementen von x-faktur.xml nicht den erwarteten Vorgaben. Am Ende des Tages habe ich dann noch auf die Schnelle eine E-Rechnung im ZUGFeRD-Format vom OpenIndex ZUGFeRD-Manager erstellen lassen. Auch diese ließ sich nicht validieren, sondern es wurden Warnungen ausgegeben.
Mir blieb nichts anderes übrig, mir dann auf die Schnelle eine E-Rechnung für den Kunden mittels PDF24 generieren zu lassen. Diese ZUGFeRD-Rechnung wurde zumindest bei der Validierung auf ecosio.com als korrekt ausgewiesen. Jetzt muss ich schauen, ob das System des Kunden die E-Rechnung auch akzeptiert. Ich werde (Stand 2. Februar 2026) weitere Lösungen testen und auch mal mit den Fakturama-Entwicklern Kontakt aufnehmen. Da ist angedacht, die ZUGFeRD-Geschichte in der Version 2.2 von Fakturama anzugehen – was ich in der Beta, die ich zum Test installiert hatte, aber nicht bestätigen kann (da gibt es noch die gleichen Validierungsfehler).
Artikelreihe
ZUGFeRD und XRechnung: Bestandsaufnahme und Überblick – Teil 1
Lösungen zum Empfang und Erzeugen von ZUgFeRD-Rechnungen – Teil 2
OpenSource ZUGFeRD-Lösung Fakturama im Hands-on – Teil 3a
OpenSource ZUGFeRD-Lösung Fakturama im Hands-on – Teil 3b
MVP: 2013 – 2016
Klingt für mich nach einer "Frickellösung".
hier wäre noch eine Alternative zu Fakturama:
https://www.open3a.de
ist nicht onprem …
doch
danke, man muss nur wiet genug runterscrollen.
-> open3A zum selbst Installieren
nur Cloud, nicht onPremise. Daher keine Alternative.
what? ;-)
https://www.open3a.de/page-Download
hab ich übersehen, mein Fehler.
Wird aber ganz schön teuer wenn man ein paar Module braucht und besonders X-Rechnung kostet richtig. Die Module sind wohl immer kostenpflichtig oder übersehen ich da auch was? Wenn ich zusammenrechne was ich so brauche ist MonKey Office REWE preiswerter.
mag sein, dass Deine Version vielleicht günstiger ist. Musst halt wissen, was du brauchst/willst.
Dafür gibts open3a für Linux und ist OpenSource – wobei ich jetzt nicht weis, ob deine nicht auch OS ist.
Setze Fakturama seit 2016 ein. War damals glaub noch die Version 1.x
Vorlagen können einen zur Verzweiflung bringen und die Doku in meinen Augen etwas verstreut.
Für mich war die Plattformunabhängigkeit wichtig. Die Datenbank habe ich mal auf eine MariaDB konvertiert um auch mal gefahrlos auf zwei Rechnern das Programm öffnen zu können.
Den langsamen Start kann ich bestätigen, wenn es einmal gestartet ist gehts aber.
Die Bedenken be jedem LibreOffice Update waren bisher umsonst.
Eine reine Browserlösung wäre mir lieber, da wirklich unabhängig. Allerdings reichts für die paar Rechnungen, die ich schreibe.
"Eine reine Browserlösung wäre mir lieber"
Ich nutze seit 2011 Kivitendo. Ist in Perl (!) geschrieben und winzig. Die Vorlagen zu bearbeiten ist (wie quasi überall) sperrig aber wenn man's einmal hat… Und es gibt auch ein paar Dienstleister, die einem helfen. Einen Großteil der Funktionen nutz ich gar nicht, aber zum Rechnungen schreiben tut's gut :-)
Danke, muss ich mir mal ansehen. Ist aber von den Funktionen her eine andere Liga als Fakturama.
LaTeX für die Vorlagen zu nutzen hätte auch was, wenn auch der Einstieg schwieriger ist.
Von Fakturama nutze ich auch nicht viele Funktionen. Kunden und ein paar Artikel, mehr nicht.
Moin Günter,
danke für Deinen Aufwand hier – interessant…
Nachdem Du Dich damit beschäftigt hast: Magst Du wohl einen Vergleich zwischen Fakturama und ZugFerd-Manager ziehen?
Danke!
Zum ZUGFeRD-Manager habe ich was in Teil 2 nachgetragen. Wer nur einige Rechnungen pro Monat hat, dürfte mit dem Teil sein Ziel erreichen, wenn er die restlichen Anforderungen laut GoBD erfüllt.
Lohnt sich dieser Aufwand überhaupt?
Ich habe in den vergangenen Jahren in der Datenverarbeitung auch den Einsatz von EDIFACT direkt begleitet. Das war sehr viel Aufwand für ein Team von Menschen, die die Umsetzung begleitet haben. Hat sich natürlich gelohnt, wenn z. B. bei Automobilkonzernen zehntausende von Ersatzteilen von den Vertragswerkstätten verwaltet und die Bestellungen organisiert werden müssen.
Bei den ersten Schritten in Sachen Electronic Commerce mussten wir in der Software die Erfahrung machen, dass man vom Bleistift bis zum Atomkraftwerk (heute wären es wohl eher Rüstungsgüter) eben nicht einfach mal ein einheitliches Datenformat verwenden kann. Jede Branche hat ihre eigenen Anforderungen und das XML-Format ist keine eierlegende Wollmilchsau.
Bis heute bleibt gerade bei Einzelunternehmen und kleinen Betrieben mit einer überschaubaren Anzahl von Belegen das Papier die übersichtlichste Lösung. Die Ergebnisse können dann einfach in Elster von Hand eingetragen werden.
Ein wunder Punkt wird anscheinend von allen übersehen: Kommt es zu einem Ausfall der Systeme und der Zerstörung von Daten, konnte man früher einfach die Papierbelege erneut erfassen. Digital steht man möglicherweise vor dem Nichts, weil Datensicherungskonzepte auch Lücken und Fehler haben.
Das kommt immer auf die Anzahl der Belege an.
Das mit dem Papier skaliert nicht lange gut. Denn jeder Zettel den man erstellt, muss man später noch einige Male anfassen.. von Zahlungskontrolle bis sortieren für den Steuerberater.
Sobald es mehr als 500 Belege pro Jahr werden, steigt der Aufwand enorm.
Keine Ahnung was daran ein so großer Aufwand sein soll.
Es gab mal eine Zeit da gab es keine Computer. Seltsam dass das über 100 Jahre so funktionieren konnte.
Dann entspricht die Datensicherung nicht den GoDB-Anforderungen und du hast ganz andere Probleme.
Das Finanzamt kann dann die komplette Buchführung als nicht ordnungsgemäß verwerfen und die Steuern schätzen!
Bußgeld gibts obendrauf!
Bei der E-Rechnung gibts noch eine Reihe von Baustellen.
Beispielsweise Zahlungsziel:
Im Maschinenbau sind z.B. Zahlungsziele folgender Art üblich:
1. Teilzahlung bei Auftragserteilung
2. Teilzahlung nach x% Baufortschritt
3. Teilzahlung bei Lieferung
Schlußzahlung Termin X nach Lieferung (oder erfolgreicher Abnahme)
Wir haben bei einigen Kunden auch Zahlungsziele wie z.B.:
10 Tage 3% Skonto, 20 Tage 2% Sonto, 30 Tage 1% Skonto, 60 Tage netto.
Das geht bei der E-Rechnung auch nicht.
Die kennt nur X Tage Y% Skonto, Z Tage netto.
Die E-Rechnung verlangt auch zwingend Artikelnummer und Artikelname.
Es gibt aber auch so etwas wie, das die Artikelnummer schon der Artikelname ist.
Beispielsweise die Artikelnummer heißt "Arbeitsstunden".
Was schreibt man da bei Artikelname rein?
Leer lassen darf man das Feld nicht, sonst gibts Fehler.
Ergo das Feld mit irgendeinem Dummywert, wie z.B. einem Punkt o.Ä. füllen.
Danke @ Günter für diese Serie. Da hat man immer weniger Lust freiberuflich/selbstständig zu arbeiten.
Aufwand steigt, Bürokratiekosten & Berichtspflichten erzeugen zB 62 Milliarden € Aufwand in DE.
Daher denke ich bei Fakturma sofort an Futurama, die "Suicide Booth" und Benders Bezahlweise dort, Youtube watch?v=X8i5_oeu4z8.
Ich verwende Fakturama begeistert seit ca. 2 Jahren.
Einrichtung nicht ganz so trivial aber sobal man mal alles gemacht hat läuft das Ganze spitze auch mit 2 Rechnern und dem Verzeichnis auf Onedrive.
Ich bin den Entwicklern sehr dankbar für den großen Funktionsumfang inkl X-Rechnung.
Leicht verspätet… Auf der Suche nach Infos zu LibreOffice Base bin ich hier über XRechnung und ZUGFeRD-PDF gestolpert – ich glaube, das wurde noch nicht erwähnt:
"https://www.familiegrosskopf.de/robert/index.php?&Inhalt=xrechnung"
Benötige ich nicht, aber vielleicht kann's ja jemand brauchen.
Bin weder bekannt, noch verwandt, noch verschwägert :)
Ich habe die Lösung von Großkopf adhoc nicht zum Laufen gebracht, bin daher nicht dazu gekommen, eine E-Rechnung zu validieren.