E-Rechnung ab 2025: wie macht ihr das? OpenSource?

pit234a

pit234a

Well-Known Member
Gerade lauschte ich einem Vortrag zu der Einführung der E-Rechnung.
Ab 01.01.2025 muss ich im B2B (von Geschäft zu Geschäft) eine elektronische Rechnung akzeptieren, die nun im Wachstumschancengesetz (wer kommt nur auf solche Namen?) genauer beschrieben ist. Grob gesagt handelt es sich dabei um eine Datei in XML, bei der es Normen für gewisse Felder gibt.
<bt-115> ist der Rechnungsbetrag.

Nun stellte ich mir vor, die xml-Datei einfach nach diesem und anderen Feldern zu durchsuchen, um meine Information abzugreifen. Die nachfolgende Archivierung stellt dann wieder eigene Anforderungen, die mir noch nicht so ganz klar geworden sind.

Innerhalb des Vortrages wurde jedoch vorausgesetzt, dass man irgendwelche Programme benutzt, die dann alles können und dass die Archivierung auf sogenannten GOBD zertifizierten Clouds erfolgt. Logisch. Ohne Zertifikat und do it yourself ist heute nicht mehr in Mode.
Das bedeutet für mich, als Kleinstunternehmer mit weniger als zehn B2B-Rechnungen im Jahr, einen ziemlichen Aufwand mich da durch zu lesen und eine verträgliche Lösung zu finden. Bisher sehe ich zugferd als praktikablen Weg, um einen OpenSource-E-Rechnungs-Viewer zu erhalten, habe aber noch gar nichts weiter in der Richtung probiert.

Dachte mir, frag doch lieber erst mal im BSD-Foren.de!



In geplauder-fun-und-chillzone bin ich auch deshalb gelandet, weil ich mir eben vorstellen kann, dass es gar keine Anwendungen für FreeBSD gibt und trotzdem Erfahrungen oder Anregungen mir weiter helfen können.
 
Geht es dir ums

Erstellen (Rechnung ausgehend zu deinen Kunden)
Annehmen (Rechnung eingehend von deinen Lieferanten?)
Annehmen und Automatisierte Weiterverarbeiten (Annehmen und dann z.B. die Rechnungsdaten Automatisiert in ein Buchhaltungsprogramm übernehmen?)
 
ab 01.01.2025 muss ich annehmen können.
Wobei annehmen ja nicht das Thema ist. Statt einer PDF bekomme ich dann halt eine XML.
XML ist aber nicht so bequem zu lesen, weshalb ich gerne einen Viewer dazu hätte, der es mir bequemer macht, die Rechnungen zu überweisen.

Anschließend muss ich das ja speichern, sprich, archivieren und da ist es natürlich auch bequemer nach zu vollziehen, wenn man einen entsprechenden Viewer hat.

Die Buchführung ist bisher bei mir ein Blatt einer LibreOffice Tabelle mit allen Einnahmen und Ausgaben des laufenden Geschäftsjahres.
Das ist durchaus übersichtlich und lohnt bisher den Aufwand nicht, ein eigenes Programm zu benutzen

Erstellen muss ich selbst E-Rechnungen erst ab 2028 und mein bisheriger Plan sieht eher vor, meinen Betrieb 2027 auslaufen zu lassen, so dass ich daran zunächst noch nicht denke. Könnte eine Anwendung dies zusätzlich, wäre es natürlich kein Hinderungsgrund.
Aber derzeit suche ich nur nach einem Viewer, um erhaltene und archivierte E-Rechnungen Menschen-lesbar darstellen zu können.
 
Wenn es zugpferd ist, ist es doch eine PDF in die XML zusätzlich integriert ist, die du aber mit jedem PDF-Betrachter öffnen kannst.

Ich weiß gerade nicht ob andere Standards ab 1.1.25 noch zusätzlich eingeführt werden die dann nur XML sind.

Bei so geringen mengen an Eingangsrechnungen vermute ich das es reicht die ... "irgendwo nach gängigen technischen standards" - die du sicher mehr als die meisten anderen Kleinunternehmer erfüllst - abzuspeichern und halt "normal" zu sichern.
 
Musst du denn die Rechnung als E-Rechnung archivieren? Ansonsten einfach als PDF wie deine üblichen ER archivieren und gut ist.
 
also, nach einem Vortrag von etwa 45min bin ich natürlich kein Experte.

Es wurde da unterschieden zwischen
  • XML
  • XML-Hybrid (sprich zugferd)

Was diese Hybrid-Darstellung technisch ist, wurde nicht aufgearbeitet (es war ein Vortrag für Landwirte, nicht für IT's)
Was eine XML-Datei ist, wurde auch nicht erklärt, sondern nur erwähnt, dass man diesen Code ja nicht lesen könne (was ja nicht so ganz richtig ist, man kann ihn ja doch ziemlich gut lesen, finde ich).

Was für eine Lösung die Absender für sich benutzen, kann man natürlich nicht im Voraus wissen.
Deshalb gehe ich von der XML aus, die dem ganzen ja irgendwo zu Grunde liegt und die einzige Rechnung, die ich bisher im Netz finden konnte, ist tatsächlich nicht in einem Browser (xml-viewer) darstellbar (außer als Quelltext), weil es an Style-Informationen mangelt.

Deshalb vermutete ich, dass es spezielle E-Rechnungs-Viewer gibt (eben zugferd), die mir das Lesen des XML-Codes leichter machen.
zugferd habe ich mir noch nicht runtergeladen und angesehen, nur darüber gelesen.
 
Also Zugpferd ist idr. dieses Hybride PDF was ich erwähnt habe (Mein Arbeitgeber macht das schon seit Jahren, neben mir sitzt eine Abteilung die ua den ganzen Tag unsere Kunden bei Fragen und Problemen zu solchen Themen berät, ich bin da also nicht komplett unorientiert)

Wenn es das ist, kannst du die in jedem PDF-Betrachter öffnen, da ist dann lediglich die XML mit den Maschinenlesbaren Daten zusätzlich mit eingebettet.

Ich kann die Kollegen wenn du möchtest mal Fragen ob die so eine PDF mit XML für dich als Beispiel haben. Und auch ob es noch ein anderes Format gibt.
 
Also zumindest hier in Ö gibts auch ein reines XML Format, wo man dann erstmal nichts sieht. Wird aber soweit ich weiß nur zwischen großen Unternehmen, wo das alles komplett automatisch passiert verwendet, oder sogar gegen Ämter. Ich nehme an das meint @pit234a auch?

Hierfür gibts ebenfalls OS Reader (z.b quba), ich bin in dieser Materie aber nicht drinnen, ich lass mir ein PDF Schicken und bisher hatte noch nie jemand damit ein Problem - ob ich in Ö so ein reines XML annehmen müsste weiß ich ehrlich gesagt nicht. Selbst in der Firma hätten wir da glaub ich keinen Prozess für.
 
2024.09.24-132404.webp

Dank eurer Hinweise und einiger Recherche habe ich tatsächlich eine "Hybrid-E-Rechnung im zugferd-Format" gelesen und verstehe nun viel besser.

Mein Verstand funktioniert offenbar sehr viel anders, als jener von Buchhaltern.
Wieso kann man nicht einfach erklären (wie @CommanderZed), dass zugferd eine PDF-Datei erzeugt, die eingebettete Daten in Form eines XML-Dokumentes enthält?
Hybride Dingensda: warum immer solche unsinnige Umschreibungen für etwas, das wir eh schon lange kennen?

Das pure XML-Format ist in DE auch zugelassen und könnte mich also überraschen. Dabei gibt es mehrere Unterarten, die erlaubt sind. quba fand ich inzwischen auch, aber leider nicht als fertiges Paket für FreeBSD. Wäre auch zu weit gegangen.
In keinem Beispiel fand ich ein Feld <bt-115>!
In der xml zu dem Bild von oben steht zB:
<ram:DuePayableAmount>1428.00</ram:DuePayableAmount>
na gut. Im Zweifel kann man das auch noch als Mensch lesen und verstehen.

Vorerst mal Dank. Habe schon viel mehr verstanden, als noch vor einigen Stunden!
 
Ich glaube ehrlich gesagt nicht, dass du in den kommenden 3 Jahren mit so einer reinen xml Rechnung konfrontiert wirst. Ich kenne das wie gesagt nur zwischen großen Unternehmen. Und jedes System derzeit kann immer noch hybride Rechnungen als PDF ausspuchen. Bis diese Systeme durch welche abgelöst sind, welche nur noch XML produzieren wird noch viel viel Zeit vergehen (im DACH Raum erst recht nochmal doppelt so viel wie überall sonst).
 
Hallo,
schau Dir mal mustang-cli an. Ist ein in Java geschriebenes Kommandozeilentool das auch unter FreeBSD läuft. Schau Dir die Beispiele an, damit kannst Du eigentlich alles machen was Du für die E-Rechnung benötigst ... außer archivieren.

Commandline - Mustang

Use Commandline Use Commandline Extract XML Combining PDF and XML Validate Convert CII to UBL Migrate ZUGFeRD XML Visualize XMLin HTML Visualize XMLin PDF Convert PDF/A-1 to PDF/A-3 Metrics Verbose parameters Commandline After downloading Mustang, besides integrating into your software you can...
www.mustangproject.org

Viele Grüße
Stefan
 
Ich muss mich korrigieren, Rechnungen kannst Du mit mustang-cli nicht erstellen. Das Tool dient zum extrahieren ,konvertieren, einbetten, visualisieren und validieren von Dateien. Ich verwende das Tool in einer selbst programmierten Finanzbuchhaltung unter FreeBSD.

Viele Grüße
Stefan
 
Stefan1 schrieb:
Ich muss mich korrigieren, Rechnungen kannst Du mit mustang-cli nicht erstellen. Das Tool dient zum extrahieren ,konvertieren, einbetten, visualisieren und validieren von Dateien
Zum Vergrößern anklicken....
Danke für die Meldung.

Das Thema ist dadurch entschärft, dass ich inzwischen hier gelernt habe, dass die gemeinhin üblichen Rechnungen im zugferd-Format eben nur PDF-Dateien sind, die zusätzliche Daten enthalten.
Das bedeutet, ich brauche zur Darstellung gar keine zusätzliche SW und erst 2028 vielleicht etwas, um Rechnungen erstellen zu können und dann wird es voraussichtlich meinen Betrieb nicht mehr geben.

Azazyel schrieb:
Für die lesbare Ausgabe der XML-Daten gibt es auch schon Stylesheets für die Umwandlung in PDF oder HTML. :)
Zum Vergrößern anklicken....
für die wenigen anderen Fälle, habe ich mir das schon mal angesehen, es aber noch nicht wirklich durchblickt. Zu viel zu tun im Augenblick.
Davon ab, die fraglichen zwei Rechnungen im Jahr, die da überhaupt vielleicht mal kommen könnten, kann ich auch als Text lesen und verstehen und die passenden Beträge ausmachen, die ich überweisen muss.
 
Azazyel schrieb:
Für die lesbare Ausgabe der XML-Daten
Zum Vergrößern anklicken....
Cool, so etwas suche ich auch.

Bin auch beruflich mit dem Thema XRechnung konfrontiert worden und habe unser Rechnungsprogramm XRechnungs-ausgabefaehig gemacht. Das ging recht einfach mit der entsprechenden Doku zB auf xoev.de.
Schwierig fand ich zu verstehen wie unwichtig wohl aktuell die Leitweg-ID bei B2B ist.
Es wird vermittelt wie wichtig die Leitweg-ID bei B2G ist. Das hat mich dann in eine Sackgasse gefuehrt bei dem Versuch verzweifelt Aussagen zu finden wie man an eine Leitweg-ID fuer unsere Firmen kommt.

Habe dann einen Hinweis gefunden der mich zum erstellen eigener Leitweg-IDs brachte, danach wurde meine Anfrage vom Bund FA dann endlich beantwortet: Leitweg-ID bei B2B nicht notwendig. Das waere schoen gewesen klar und deutlich in der Doku zur XRechnung lesen zu koennen.

Nun ist fuer uns vorerst klar:
  • Empfang von XRechnungen einfach per E-Mail ermoeglichen (dank DMS sollte es auch GODB treu sein)
  • der workflow bleibt bei uns erst mal erhalten: XML per Ultramarinviewer darstellen und regulaeren Rechnungsweg bei uns durchlaufen lassen
  • der Rest wird sich die naechste 3 Jahre ergeben
 
Ich habe vor kurzem ein Projekt angefangen, das es ermöglicht, EN16931-konforme E-Rechnungen komplett mit OpenSource-Software zu erstellen: https://github.com/gflohr/e-invoice-eu

Zur Zeit können folgende Formate erzeugt werden:

  • CII
  • Factur-X/ZUGFeRD Extended
  • UBL
  • XRechnung-UBL

Die anderen Factur-X/ZUGFeRD-Varianten sollten in den nächsten Tagen folgen. Auch XRechnung-CII sollte relativ zeitnah realisierbar sein.

Die einzigen Abhängigkeiten sind Node.js und evtl. LibreOffice, falls die Rechnung aus Spreadsheets generiert werden soll. In der Zukunft soll es aber auch möglich sein, die Rechnung direkt aus JSON-Daten zu erzeugen (die dann auf anderem Wege generiert werden müssen). Die generelle Idee hinter dem Projekt habe ich in einem Blog-Post beschrieben: https://www.guido-flohr.net/creating-electronic-invoices-with-free-and-open-source-software/ (deutsche Version: https://www.guido-flohr.net/elektronische-rechnungen-mit-freier-und-quelloffener-software-erzeugen/).

Was die andere Richtung, also den Empfang elektronischer Rechnungen, hast du mit Factur-X/ZUGFeRD in der Praxis kein Problem, weil das Format hybrid ist. Die XML-Version der Rechnung ist ein Attachment der PDF-Version und XML und PDF müssen nach Vorgabe des Bundesfinanzministeriums "inhaltsgleiche Mehrstücke" sein. Wie bei Abweichungen zwischen den beiden Versionen zu verfahren ist, wird sich vermutlich in der Zukunft herausstellen. IMHO ist eine Rechnung, bei der steuerlich relevante Angaben der PDF-Version von der XML-Version abweichen, fehlerhaft und sollte zurückgewiesen werden.

Ein sehr wichtiger Aspekt ist die Validierung sowohl eingehender als auch ausgehender Rechnungen. Dafür gibt es zwei quasi-Standard-Tools, beide Open-Source:


Beide Validatoren bieten auch eine zumindest krude Visualisierung der XML-Daten. Mehr zum Thema Validierung habe ich hier geschrieben: https://github.com/gflohr/e-invoice-eu/tree/main/contrib/validators

Es wurde auch die Frage nach der Leitweg-ID gestellt. Die ist eigentlich nur für B2G, also Geschäfte mit der unmittelbaren Bundesverwaltung wichtig, und man wird die Leitweg-ID des Kunden in diesen Fällen mitgeteilt bekommen. Sofern man Rechnungen als XRechnung verschicken will, muss man in das Feld allerdings auch für B2B irgendetwas eintragen, nur dann keine Leitweg-ID, sondern normalerweise die Bestellnummer des Kunden. Wenn dem Kunden das egal ist, kann man auch einfach einen Text wie "bekannt" eintragen. Genauere Informationen hier: https://www.guido-flohr.net/elektro...ware-erzeugen/#kauferreferenz-buyer-reference
 
Um meinen Erfahrungsschatz für Unternehmer mit Hang zu Open Source und schrägen Lösungen zu teilen - ich habe über viele Jahre jetzt open3a eingesetzt und war damit immer sehr zufrieden. Die haben auch kostenpflichtige Module für alle möglichen und unmöglichen Anwendungen incl. mittlerweile eines für e-Rechnung, was auf ZUGFeRD aufsetzt:

Rechnungsprogramm | Rechnungsprogramm kostenlos | open3A - Plugins

www.open3a.de www.open3a.de

Persönlich würde ich als Unternehmer mittlerweile allerdings eher zu Allround Zahlungsdiensanbietern mit Rechnungsstellung wechseln, wie es Stripe und SumUp z.B. tun. Alles in einer Hand und bei einer Prüfung etwas, was vermutlich weniger Diskussionen mit dem Prüfer verspricht.

Im Ende macht das alles für alle wie immer teurer und hat einen fraglichen Wert, aber Hauptsache es wurde wieder was verwaltet. :ugly:
 
peterle schrieb:
Im Ende macht das alles für alle wie immer teurer und hat einen fraglichen Wert, aber Hauptsache es wurde wieder was verwaltet. :ugly:
Zum Vergrößern anklicken....

Hauptsache "die Politik" gebasht.

Sachlich betrachtet gibt es etliche gute Gründe für die E-Rechnungs-Pflicht im B2B-Bereich. Die wichtigsten sindl:

  • Die manuelle Verarbeitung einer Eingangsrechnung kostet ein Unternehmen mindestens 50 Euro. Bei der Verarbeitung maschinenlesbarer Rechnungen fallen etliche manuelle Schritte weg, und das spart enorm Kosten.
  • Insbesondere fehlerhafte Rechnungen sind sowohl für die Ausstellerin als auch die Empfängerin extrem teuer. Wenn die Rechnungsempfängerin eine nicht valide Rechnung automatisiert ablehen kann, werden diese Kosten zum größten Teil auf die Verursacherin, also die Ausstellerin der fehlerhaften Rechnung abgewälzt.
  • Die E-Rechnungspflicht in Deutschland dient als Vorstufe zur automatischen Echtzeitmeldung von Umsätzen an das Finanzamt, die ab 2029 (das ist die Vorgabe der EU-Kommission) in der EU verbindlich ist. Und das ist eine notwendige Maßnahme, um endlich die massenhafte Steuerhinterziehung durch Umsatzsteuer-Karusselle wirksam zu bekämpfen.

Das ist wohl auch der Grund, weshalb es einen breiten Konsens beim Thema E-Rechnungs-Pflicht in Deutschland gibt.
 
gflohr schrieb:
Hauptsache "die Politik" gebasht.
Zum Vergrößern anklicken....
Die "die Politik" nicht so viel Schmu machen würde, würde die wohl auch nicht so oft "gebasht" werden. :-)

gflohr schrieb:
gibt es etliche gute Gründe
Zum Vergrößern anklicken....
Naja. Es gibt aber auch Gründe dagegen.
  • Wir können keine sichere Software. Das zeigt sich immer wieder. Auch bei denen, denen man unterstellt zu den Besten der Besten zu gehören. Fahrlässig naiv zu glauben, das es bei E-Rechnung anders sein wird.
  • Man erhöht die Abhängigkeit von Technik. Und wehe, wenn die mal nicht funktioniert. Wie oft ich den Satz höre "das System streikt gerade" kann ich schon längst nicht mehr zählen.
  • Manuelle Rechnungsstellung ist fehleranfälliger. Ist nicht schön, aber wenigstens ist der Fehler nur vereinzelt hier und da. Wenn im E-Rechnungssystem ein Fehler/Bugs auftreten, hast Du gleich einen Flächenbrand.
  • Es ist digitale Diskriminierung, weil alle die sich dem nicht aussetzen wollen über Gebühr benachteiligt werden.
  • Kostensenkung ist per se kein Argument. Wenn es um Kostensenkung geht, kannst Du auch fordern, das Umweltstandards herabgesetzt oder Arbeitnehmerschutz reduziert wird.
  • Was das Thema Steuerhinterziehung angeht: Das geht man jetzt schon nicht vernünftig an. Wenn ich sehe, das Großkonzerne vergleichsweise wenig Steuern zahlen müssen. Wenn ich auf das Thema Finanztransaktionssteuer gucke. Wenn ich sehe, wie die Vermögensverteilung ist. Wenn ich sehe, das die Steuerfahndung seit Jahren (Jahrzehnten!) personell unterbesetzt ist. Dann braucht mir keiner mit dem Argument Bekämpfung von Steuerhinterziehung kommen.
 
Zuletzt bearbeitet:
gflohr schrieb:
Hauptsache "die Politik" gebasht.

Sachlich betrachtet gibt es etliche gute Gründe für die E-Rechnungs-Pflicht im B2B-Bereich. Die wichtigsten sindl:

  • Die manuelle Verarbeitung einer Eingangsrechnung kostet ein Unternehmen mindestens 50 Euro. Bei der Verarbeitung maschinenlesbarer Rechnungen fallen etliche manuelle Schritte weg, und das spart enorm Kosten.
  • Insbesondere fehlerhafte Rechnungen sind sowohl für die Ausstellerin als auch die Empfängerin extrem teuer. Wenn die Rechnungsempfängerin eine nicht valide Rechnung automatisiert ablehen kann, werden diese Kosten zum größten Teil auf die Verursacherin, also die Ausstellerin der fehlerhaften Rechnung abgewälzt.
  • Die E-Rechnungspflicht in Deutschland dient als Vorstufe zur automatischen Echtzeitmeldung von Umsätzen an das Finanzamt, die ab 2029 (das ist die Vorgabe der EU-Kommission) in der EU verbindlich ist. Und das ist eine notwendige Maßnahme, um endlich die massenhafte Steuerhinterziehung durch Umsatzsteuer-Karusselle wirksam zu bekämpfen.

Das ist wohl auch der Grund, weshalb es einen breiten Konsens beim Thema E-Rechnungs-Pflicht in Deutschland gibt.
Zum Vergrößern anklicken....
keinen Widerspruch von meiner Seite und das Bashing der Politik geht mir auch nicht besonders ab, aber, mein Betrieb ist sehr klein und ich habe insgesamt weniger als 10 Rechnungen im Jahr zu bearbeiten, rein manuell und für weniger als 50€, die ich da pro Rechnung als Bearbeitungsgebühr veranschlagen könnte. Ich will nicht übertreiben, aber die kommende E-Rechnung ist ein weiterer kleiner Sargnagel für meinen Kleinstbetrieb. Maximal bis 2028 mache den Zores noch mit, aber danach ist Schluss für mich.

Das Stichwort hier ist auch eher "Digitalisierung" und nicht Aufblähen der Verwaltung. Natürlich zunächst vollkommen Wertefrei, wird diese Digitalisierung und die einhergehenden Möglichkeiten der Überwachung dann doch meist eingesetzt, um Fehler zu korrigieren. Also gemäß des Mottos: einen Fehler mit einem anderen austreiben. Wir haben ein unsäglich kompliziertes Steuersystem, uneinheitlich über ganz Europa und den Rest der Welt verteilt, dass auch dazu einlädt, Steuern zu hinter ziehen (noch nicht mal bösartig, sondern weil man den Dschungel an Vorschriften und Regeln nicht mehr durchblicken kann).
Die Lösung wäre also, das System zumindest in der EU zu vereinheitlichen und ganz ganz einfach zu gestalten, ohne die vielen "Sonder-Schlupflöcher".
Gab es nicht mal im finsteren Mittelalter einen Ansatz des Zehntels? Egal, wie Arm oder Reich, jeder 10% immer und überall, das hört sich zumindest mal einfach an.

Was die E-Rechnung angeht, wage ich die Prognose, dass sie die positiven Erwartungen nicht erfüllen wird.
 
Mal unabhaengig davon finde ich es schon merkwuerdig, dass es kein einheitliches Format gibt, sondern mehrere Formate. Das macht es nur noch komplizierter. Ich bin mal gespannt, welches Format sich dann durchsetzen wird.

Bei uns in der Firma ist noch nichts in Richtung E-Rechnung passiert. Ich habe es im Laufe des Jahres schon mehrmals angesprochen und es interessiert scheinbar niemanden. Im Januar habe ich mir meinen Resturlaub genommen. Dann muss es ploetzlich ganz schnell eingefuehrt werden. Das kann dann jemand anderes uebernehmen. :-)
 
@pit234a

ich nehm mal an, dass Du Kleinunternehmer im Sinne v. §19 Umsatzsteuergesetz bist oder es zumindest sein könntest.
Dann kannst Du auch nach 2028 eine "sonstige Rechnung" (sprich Papierrechnung) stellen. Ist zumindest im Jahressteuergesetz 2024 so vorgesehen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben