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

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.


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
 
Ich muss mich korrigieren, Rechnungen kannst Du mit mustang-cli nicht erstellen. Das Tool dient zum extrahieren ,konvertieren, einbetten, visualisieren und validieren von Dateien
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.

Für die lesbare Ausgabe der XML-Daten gibt es auch schon Stylesheets für die Umwandlung in PDF oder HTML. :)
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.
 
Zurück
Oben