Ich greife mal ein Thema auf, was viele aus der deutschen Leserschaft vermutlich abgehakt haben, was mir aber gerade quer gekommen ist. Es geht um elektronische Rechnungen im ZUGFeRD- und XRechnung-Format. Seit dem 1.1.2026 besteht in Deutschland ja die Pflicht, solche elektronischen Rechnungen im Firmenumfeld empfangen und lesen zu können.
Eigentlich hatte ich ja "die Hoffnung", um das ganze Thema herum zu kommen. Wir haben zwar seit 1.1.2025 eine Verpflichtung, elektronische Rechnungen im ZUGFeRD- und XRechnung-Format ausstellen zu müssen. Aber für kleine Fische wie mich gibt es Übergangsregelungen – ich müsste erst 2028 springen – und im Hinterkopf war "da bist Du längst raus, tangiert mich nicht". Der IT-Rentner hier auf administrator.de hat das so gemacht.
Aber ich habe ja Ende 2025 "den Deal" abgeschlossen und borncity.com verkauft, bleibe aber bis mindestens Ende 2028 hier im IT-Blog an Bord. Ergo kommt, statt im Liegestuhl Caipirinha zu schlürfen, doch das Thema elektronische Rechnungen auf mich zu. Hab mich also die Tage kurz hingesetzt und das für mich (hoffentlich) geregelt. Dachte, ich fasse mal einiges in einer Artikelreihe zusammen, auch wie ich mit Facturama als OpenSource-Lösung herausgekommen bin. Vielleicht gibt es ja noch einige arme Seelen, die auch tangiert sind.
Elektronische Rechnung (ZUGFeRD und XRechnung)
Sachstand ist, dass mit dem Wachstumschancengesetz die Regelungen zur Ausstellung von Rechnungen nach § 14 UStG neu gefasst wurden. Durch die E‑Rechnung soll die Digitalisierung der deutschen Wirtschaft gefördert werden. Insbesondere im Rechnungswesen können Prozesse vereinfacht werden (keine doppelten Erfassungen von Rechnungsdaten mehr).
Pflicht zur eRechnung seit 2025
Ab dem 1. Januar 2025 ist bei Umsätzen zwischen inländischen Unternehmern regelmäßig eine elektronische Rechnung (E-Rechnung) zu verwenden. Die Regelungen zur verpflichtenden E‑Rechnung gelten nur, wenn überhaupt eine umsatzsteuerliche Pflicht zur Ausstellung einer Rechnung besteht.
Daher gelten die Regelungen nicht bei Rechnungen an Endverbraucher und für viele steuerfreie Umsätze. Eine Rechnung braucht diese nicht als E‑Rechnung ausgestellt zu werden, bei:
- Kleinbeträgen (bis 250 Euro Bruttobetrag, § 33 UStDV),
- Fahrausweisen, die als Rechnung gelten (§ 34 UStDV),
- Leistungen, die von Kleinunternehmern erbracht werden (§ 34a UStDV),
Gleiche gilt für Leistungen an juristische Personen, die nicht Unternehmer sind (z. B. viele Vereine – oder staatliche Einrichtungen), und bestimmten Leistungen an Endverbraucher im Zusammenhang mit einem Grundstück (siehe auch FAQ des Bundesfinanzministeriums).
Es gibt Übergangsfristen
Bei der Einführung dieser obligatorischen (verpflichtenden) E‑Rechnung ab dem 1.1.2025 gelten Übergangsregelungen.
- Kleinunternehmer sind von der Ausstellung einer E-Rechnung ausgenommen, müssen aber in der Lage sein, E‑Rechnungen zu empfangen (ein E-Mail-Postfach reicht).
- Bezüglich der Pflicht zur Ausstellung einer eRechnung gibt es zwischen 2025 bis Ende 2027 Übergangsfristen, die in folgender Abbildung der IHK Darmstadt Rhein Main Neckar aufgeführt sind.
Fristen eRechnung in Deutschland; Quelle IHK Darmstadt Rhein Main Neckar
Gemäß dieser Auflistung dürfen auch 2026 Rechnung in Papierform oder nicht im eRechnungsformat einvernehmlich ausgetauscht werden. Beim Umsätze unter 800.000 Euro gilt die Pflicht, eine eRechnung zu versenden, sogar erst im Jahr 2028.
eRechnung als ZUGFeRD oder XRechnung
Elektronische Rechnung bedeutet dann nicht mehr "eine PDF-Datei" reicht – das läuft dann unter "sonstige Rechnungen". Wer eine elektronische Rechnung erstellen muss, ist verpflichtet, diese im ZUGFeRD- oder XRechnungsformat zu tun.
- XRechnung ist ein Rechnungsdokument in Form einer XML-Datei, die alle Daten für den Empfänger und ggf. Steuerbehörden enthält und im öffentlichen Auftragswesen bereits zum Einsatz kommt.
- Alternativ gibt es die elektronische Rechnung im hybriden ZUGFeRD-Format, bei der ein von Menschen lesbares PDF-Dokument mit einer XML-Datei (XRechnung) kombiniert wird.
Die beiden obigen Rechnungsformate sind die, die in Deutschland wohl zum Einsatz gelangen. Allerdings sind weitere Formate, wie beispielsweise die "französische" Factur-X – zulässig, wenn sie die technischen Anforderungen der CEN-Norm EN 16931 umsetzen, heißt es bei der IHK in diesem Dokument. Welches Rechnungsformat verwendet wird, ist zwischen den Vertragsparteien zu vereinbaren. Ich gehe davon aus, dass (abseits der Bundesverwaltung und Behörden) meist das ZUGFeRD-Format zum Einsatz kommt, da deren PDF-Teil von Menschen gelesen werden kann.
Informationen, was eine eRechnung an Informationen enthalten muss, hat die IHK Rheinhessen in diesem Dokument zusammen getragen.
Wie wird die eRechnung zugestellt/empfangen?
Zur Zustellung einer eRechnung im Format XRechnung oder ZUGFeRD ist lediglich ein E-Mail-Postfach beim Empfang erforderlich. Auch der Absender benötigt ein eMail-Postfach zum Verschicken. Möglich ist die Übermittlung der elektronischen Rechnung auch über digitale Schnittstellen oder über interne oder öffentlichen Download-Portale.
eRechnungen an Einrichtungen der Bundesverwaltung sind über das OZG-RE-Portal einzureichen (siehe diese Infoseite). Dazu bedarf es m.W. auch einer Leitweg-ID.
eRechnung als Sicherheitsrisiko?
Abschließend noch ein Hinweis: Auch wenn die elektronische Rechnung von der Politik als "Fortschritt" gefeiert wird, lauert der Teufel im Detail. Neben dem Klimmzug, die eRechnung für den Empfänger konform erstellen und zustellen sowie für die Finanzämter aufbewahren zu müssen, lauern auch Sicherheitsrisiken.
Zu diesem Thema verweise ich auf den umfangreichen Artikel ZUGFeRD, XRechnung und Co.: Wie elektronische Rechnungen zum Sicherheitsrisiko werden, der Mitte Dezember 2025 bei Golem erschienen ist. Der Artikel beleuchtet das Risiko von XML-Dateien sowie das Chaos, welches durch die Pflicht, verschiedene Profile der eRechnung abdecken zu müssen. Auch PDF-Dokumente können ein Sicherheitsrisiko darstellen, wenn sie nicht bestimmten Formaten entsprechen.
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
Da ist wohl ein kleiner Vertipper bei ZUGFeRD passiert ;)
Ja, Asche auf mein Haupt, die Gedanken waren schon beim Nachmittagspport und dem Zugpferd ;-)
Bin schon sehr gespannt auf den Beitrag über Fakturama.
++
Danke Günter, dass Du hier so viel Arbeit investierst!
Solange meine Kunden nicht danach fragen bleibt es bei PDF. Meine Software kann das nicht und es gibt kein Update bzw nur eines mit Abo zu Phantasie-Preisen. Nein danke.
Also Notlösung für jemanden, der doch mal schreit habe ich PDF24 in der Hinterhand.
Auch habe ich mal e-rechnungs-studio.de ausprobiert. Gutes Ergebnis aber ich weiß nicht in wie weit man dem Anbieter trauen kann und was er mit den Daten macht, die man übermittelt. Der kriegt ja alles frei Haus was auf so einer Rechnung steht.
Wenn alle Stricke reißen und ich doch Geld investieren muss habe ich mir MonKey Office aus-geguckt. Das gibt es als 2 Benutzer Lösung zum kleinen Preis zu kaufen oder als Abo.
Geht mir auch so, Kurzrecherche ergab keine kleine eigenständige Software, nur online Dienste, Kundendaten mag ich da nicht hinschicken…
Warte Teil 2 ab – vielleicht ist was dabei.
Ich plane noch einige Gedanken zu obigen Themen in Teil 2.
MonKey Office kann ich empfehlen. Hat (evtl. durch die Mac-Abstammung) an einigen Ecken eine ungewöhnliche Bedienung, so geht z. B. Rechtsklick zum Ausschneiden/Einfügen nicht überall, wo man's vermuten würde. Aber generell macht die Programm-Suite, was sie machen soll, ist recht schnell (gefühlt 100x schneller als Lexware) und preislich fair. Und, das darf/muss man heutzutage ausdrücklich lobend erwähnen: ProSaldo bietet einen sehr guten, engagierten und deutschsprachigen Support mit echten Menschen! :)
E-Rechnung funktioniert inzwischen ebenfalls prima.
ZUGFeRD war hier ein Thema.
Wir haben eine selbstprogrammierte Softwarelösung im Einsatz und da stand dann natürlich auch die E-Rechnung auf der Agenda.
Das habe ich da als zusätzliche Option der Rechnungserstellung programmiert und es läuft hier einwandfrei.
Der PDF-Teil der ZUGFeRD-Rechnung sieht aus wie unsere bisherigen PDF-Rechnungen und drin eingebettet ist eine E-Rechnung im XML-Format.
Bisher gabs noch keine Reklamationen von Kunden, das die Rechnung nicht verarbeitet werden kann.
Das Zusammenführen von PDF und XML geschieht hier per Ghostscript.
Ghostscript liefert dafür schon ein fertiges Script mit.
Das mitgelieferte Script kann auch aus einem Standard-PDF ein PDF/A3 machen, wie es für das ZUGFeRD-Format nötig ist.
Im Übrigen entspricht Faktur-X seit einigen Jahren zu 100% dem deutschen System.
Beides wird von einem deutsch-französischen Konsortium definiert und entwickelt.
Nur die Bezeichnung unterscheidet sich noch in Deutschland und in Frankreich.
Im Übrigen ist das nur der Anfang.
Es gibt auch schon Entwürfe für eine E-Bestellung, E-Lieferschein, E-Auftragsbestätigung, etc.
Und derzeit läuft auch eine Harmonisierung der E-Rechnungssysteme verschiedener europäischer Länder.
Ziel ist es, das die E-Rechnung EU-weit verpflichtend wird.
Wir bleiben als kleiner Laden bei herkömmlichem PDF oder Xrechnung für öffentliche Hand. Letzteres seit Jahren.
ZUGFerd sehe ich das hybride als Gefahr. PDF und XML sollen das gleiche zeigen – muss aber kontrolliert werden. Daher sehe ich den einfach lesbaren PDF-Teil nicht als Vorteil.
"Wir bleiben als kleiner Laden bei…"
Sportliche Einstellung, einfach Gesetze zu ignorieren. Je mehr sich die E-Rechnung etablieren wird, umso mehr Kunden werden darauf bestehen, weil diese schlichtweg Kosten einsparen. Wir üben bereits sanften Druck auf alle Lieferanten aus, dass diese endlich umstellen. Wer uns nach Ablauf der Übergangsfrist dann keine E-Rechnungen ausstellen kann, wird ausgelistet. Ganz einfach.
Das ignorieren auch recht große Unternehmen wenn es z.B. um die GoBD geht….
In einem hat der Poster Recht: Man ist bei manchem gut beraten, erstmal zu schauen was Sache ist. Noch verstößt oder ignoriert kein Kleinunternehmen irgendwelche Gesetze.
Die Ausnahmeregeln sind doch oben im Artikel deutlich dargestellt? Vielleicht erstmal genau lesen und erst kommentieren?
Wenn ihr eh schon X-Rechnungen für die öffentliche Hand ausstellt, dann könnt ihr das auch für alle anderen gewerblichen Kunden machen.
Da gibt es keinen Grund für ein PDF oder eine Papierrechnung.
Und da ihr eh PDF und X-Rechnung könnt, dann ist es leicht, beides zu erstellen und mit einem Tool zu einer ZUGFeRD-Rechnung zusammenzuführen.
Und es gibt sehr wohl Strafen für einen Verstoß gegen die GoDB.
Bei Verstößen kann das Finanzamt sogar die komplette Buchhaltung als nicht ordungsgemäß und damit hinfällig ansehen und die Steuern schätzen!
Und sogar Verfahren wegen Steuerhinterziehung sind möglich!
Verstöße gegen die Rechnungslegungspflicht (E-Rechnung) werden mit Bußgeldern bis zu 5.000,- € geahndet.
Es ist also schon grober Vorsatz, keine E-Rechnungen ausstellen zu wollen.
"Verstöße gegen die Rechnungslegungspflicht (E-Rechnung) werden mit Bußgeldern bis zu 5.000,- € geahndet."
Was aber lächerlich wenig ist im Vergleich zu den sonst üblichen Bußgeldhöhen im unternehmerischen Bereich…
> Kleinunternehmer sind von der Ausstellung einer E-Rechnung ausgenommen, müssen aber in der Lage sein, E‑Rechnungen zu empfangen (ein E-Mail-Postfach reicht).
Tja, wenn Absender sich aber entschlossen hat eine XRechnung zu verschicken, hat der Empfänger viel Spass sich die Rechnungsbeträge, Zahlungsfristen, Rabatte, Skonto, usw. aus dem XML-Dokument rauszudröseln. Dabei kann man auch noch mit zwei verschiedenen XML-Formaten (Universal Business Language [UBL] oder Cross Industry Invoice [CII]) konfrontiert werden. Man kommt dann nicht um eine Software/Webseite herum, die das auswerten und menschenlesbar darstellen kann.
> Ich gehe davon aus, dass … meist das ZUGFeRD-Format zum Einsatz kommt, da deren PDF-Teil von Menschen gelesen werden kann.
Rechtsverbindlich ist aber nur das im PDF eingebettete XML-Dokument. Wenn der Ersteller eine Software verwendet, die dabei Fehler macht und im PDF etwas anderes steht als im XML-Dokument, kann das Probleme bereiten.
> Allerdings sind weitere Formate, wie beispielsweise die "französische" Factur-X – zulässig
Factur-X und ZUGFerD wurden gemeinsam von deutschen und französischen Gremien entwickelt und sind in der aktuellen Version kompatibel.
Übrigens: Wer es noch nicht verstanden hat – die elektronische Rechnung wurde nicht zur Erleichterung bzw. Beschleuigung/Automatisierung des Geschäftsverkehrs eingeführt. Das ist nur ein möglicher Nebeneffekt. Es geht um die Kontrolle aller Zahlungsvorgänge zur Vermeidung von Umsatzsteuerbetrug und anderer krimineller Machenschaften. Das Thema wird Anfang der 2030er Jahre richtig Fahrt aufnehmen, wenn eine europaweite Infrastruktur aufgebaut werden soll, mit deren Hilfe es möglich/verpflichtend wird, Rechnungen nur noch elektronisch an zentrale (staatliche) Stellen zu schicken, die die Rechnungen abgreifen und auswerten und danach an die eigentlichen Empfänger zustellen. Die Anfänge davon sind PEPPOL, hier wurde die zukünftige Kommunikationsinfrastruktur bereits implementiert.
In Italien geht schon seit Jahren jede Rechung von Firma A zu Firma B über das Finanzamt aber es gibt immer Möglichkeiten etwas zu umgehen.
In Belgien ist so ein Portal seit anfang des Jahres pflicht.
Am Ende kriegen die den Hals nicht voll und statt sparen gibt es dann ein "Sondervermögen" bezahlt vom Steuerzahler.
Geh mal zu einer Bank und sage "Ich möchte kein Kredit sondern nur ein Sondervermögen".
Die werden eine auslachen.
Aus Kredit wird "Sondervermögen" sonst ändert sich nix.
den schaden der Betrüger tragen alle.
deshalb hat sich meine Meinung zu dem Thema von "böse Überwachung" nach "sinnvolle maßnahme" entwickelt.
Betrüger finden andere Wege. Der Rest wird totalüberwacht.
Weil das sinnvolle Ziel, dass Belege von einem Buchhaltungs System automatisch verarbeitet werden können so undenkbar ist.
Ein echter Beleg muss ausgedruckt, idealerweise gleich mehrfach, und dann gleich mehrfach abgelegt werden (verschieden Sortiert).
"Man kommt dann nicht um eine Software/Webseite herum, die das auswerten und menschenlesbar darstellen kann
da würde ich https://www.elster.de/eportal/e-rechnung empfehelen
Amicron Faktura und DATEV sind bei uns im Einsatz.
Es gibt einen Punkt den hier viele übersehen meiner Meinung nach, weshalb der Artikel zu kurz greift.
Fraglich ist auch ob der Weg über Email überhaupt noch haltbar ist in Zukunft.
Ab 2030 greift die Meldepflicht.
Natürlich kann man sich offline Lösungen schaffen aber ab 2030 kommt der nächste Schritt, der klar und deutlich eine Plattform benötigt die beim übersenden der Rechnung an den Kunden im gleichen Zug die Rechnung an die zuständigen Behörden meldet.
Das gleiche soll übrigens beim Empfang passieren.
Der Empfänger benötigt hier auch eine platform, die entsprechend meldet beim Eingang einer Rechnung um doppelte Validierung zu erreichen.
Somit sind alle offline Lösungen obsolet oder sie bieten eine Schnittstelle an eben eine solche platform.
Ich fahre aktuell 2 gleisig einmal invoice ninja für die Rechnungs Erstellung und für das übersenden eine Lösung von traffiqx bzw b4value um diese sauber und sicher zu versenden.
Da platform unumgänglich wird sind wir jetzt schonmal sauber aufgestellt.
Wer ist invoice ninja?
Ich finde auf den Seiten keine Angaben zum Unternehmen.
Invoice Ninja LLC
Sie bieten eine Lösung in der Cloud an, aber ich nutze das Self-hosted.
Kostet für das Whitelabel, glaube ich, 30 € im Jahr, somit sehr kostengünstig die Lösung.
Hier das Github
https://github.com/invoiceninja/invoiceninja
ich sehe das Problem nicht, eine Zeile curl mit hinterlegten API-Token und evt. etwas jq für das json und gut ist… bzw. ein curl-ping gegen das Portal, dass man diese empfangen/gelesen hat.
Wenn man eine eigene REST API braucht, das kann jedes NodeJS mit wenig Zeilen (aber viel Overhead). Wer eine kompakte, schlanke Lösung braucht:
https://codeberg.org/tomas-jakobs/rest-api-skeleton
Aber mit Sicherheit gibt es bis dahin diese typischen überfreundlichen Menschen, die Unternehmen Ihr Schlangenöl andrehen wollen…
1. als Empfänger darf man ab 2027 nicht-zugferd Rechnungen zurückweisen. Als Unternehmer sollten man das dann auch
2. muss man als Empfänger die zugfred Rechnung validieren und das 8 Jahre nachweisen
Darf ich diesen wichtigen Hinweis mal in die Runde streuen?
Ich gehe davon aus, dass wenn jetzt ganz viele anfangen Ihre Rechnungen per Email zu versenden und zu bearbeiten, einige ihr blaues Wunder erleben werden:
https://blog.jakobs.systems/blog/20250805-risiko-rechnung-emails/
Danke für diesen Einwurf – aber ich plädiere aktuell mal dafür, die Front kurz zu halten. Die Leute haben ggf. aktuell noch genügend zu tun, überhaupt eRechnungen abwickeln zu können. Da braucht es nicht noch "signierte Mails" oder den in einem anderen Kommentar aufgeworfene Punkt, dass alle eRechnungen 2030 in einem Portal einzureichen sind.
Nein verschlüsselt brauchen sie nicht zu sein, signiert reicht aus, denn das Prüfen der Signatur obliegt dann wieder beim Empfänger. Das Risiko ist dann abgeschoben.
Aber wenn Du schon Kriegs-Analogien nutzt und die "Front verkürzen" willst. Im Krieg und in der Liebe gibt es bekanntlich keine Pausen… kein Mitleid und es werden auch keine Gefangenen gemacht ;-)
interessant wäre, wenn Fakturama auch gleich direkt die Rechnung signieren könnte. Sonst muss man sich halt mit LibreOffice behelfen.
Ich kenne Fakturama nicht, aber das Signieren der PDF ist mit Vorsicht zu machen. Viele PDF Reader zeigen unschöne Warnungen mit privaten bzw. unbekannten Certs an. Die meisten Dokumentenmanagementsysteme weigern sich, diese zu verarbeiten bzw. schmeissen die Zertifikate teils sogar ganz weg. Und öffentliche, valide Certs kosten und sind für manche noch komplizierter im Handling. On top kommt dann bei Offline Systemen (und das dürften viele sein), dass diese ein Cert und insb. eine Revokation List (CRL) nicht validieren können, wenn man 10 oder 25 Jahre in Zukunft denkt, noch weniger.
Nein wenn per Mail übertragen wird, sollte die komplette Mail mit Ihren multi-part MIME Anlagen signiert sein. Das macht man entweder im Mailprogramm (Evolution, Thunderbird) oder einem eigenen Mailserver, der das im Maildrop Verzeichnis macht. Das ist seit 25 Jahren bewährter Standard und schützt vor Manipulation. Im eigenen Workflow ist die Datei dann ohne Signierung und erzeugt weniger Probleme.
Das Problem ist nicht die PDF, es ist der Transport.
Know your Threat-Landscape!
Bei vielen, die bislang in der Windows-Welt gefangen sind, ohne eigene Technik und Expertise, und IT eh nur als Kostenstelle wahrgenommen bzw. nicht strategisch für Ihr Business ernst genommen haben, ist das verständlicherweise jetzt alles ein Problem und mit erheblich Aufwand und Kosten verbunden.
Interessanter Thread – sollten wir ggf. im Fakturama-Teil diskutieren. Bin ja schon über Wochen mit der Idee zu einem ZUGFeRD-Artikel "schwanger gegangen", hab aber überlegt, wer braucht das noch. Dann habe ich einen Tag mit lösungsaustesten und Fakturama-Einrichtung verbracht und dachte "schreib mal was kurzes".
Nun sehe ich, dass die Schwarm-Intelligenz der Blog-Leserschaft mir alleine aus Teil 1 schon wieder so viele Anregungen geliefert hat, dass ich vielleicht noch einen Beitrag drüber mache. Muss jetzt aber Teil 2 fertig schreiben (immer wenn ich danke "hast jetzt über alles gebloggt, isch over, schwappt die nächste Katastrophenwelle über mich").
bin auf mehr gespannt…
Und Verlinkungen oder Namennenungen sind gerne gesehen ;-)
Ich habe den Hinweis zum Anlass genommen, mir endlich ein SMIME Zertifikat bei der PSW Group zu bestellen, die P12 Datei wird auch vom Mail Programm (Thunderbird / Apple Mail) akzeptiert. Beim Empfänger wird es trotzdem nicht als gültig erkannt. Also so ganz trivial scheint das nicht zu sein, da lobe ich mir PGP in Thunderbird.
S/MIME ist seit 2018 praktisch tot gerade bei multi-part Messages und bestimmten Client-Implementationen (Outlook).
Ich empfehle den Vortrag von Sebastian Schinzel, FH Münster:
https://media.ccc.de/v/35c3-9463-attacking_end-to-end_email_encryption
Kommentar zu Efail: "you cant fix S/MIME cause it would be a breaking fix"
Habe den Vortrag überflogen:
Es geht da vor allem um das Austricksen der Verschlüsselung. Der Anwendungsfall hier ist aber signieren. Zu Signaturen wird in dem Vortrag eher wenig gesagt. Einige der Lücken sind schon vor dem Vortrag behoben worden auf Initiative der Vortragenden.
Ein wesentlicher Teil bezieht auch auf das Laden externer Inhalte. Das hat aber wenig mit Unsicherheit der Crypto-Funktionen zu tun, sondern eine allgemeine Unart von E-Mail, die falsch agebogen ist und seitdem die Kurve nicht kriegt. Mein E-Mail-Client, der in dem Vortrag nicht vorkommt, lädt keine externen Inhalte, ohne dass ich ihn explizit dazu auffordere. Und auch eingebettete Inhalte lasse ich mir erst auf Anfrage anzeigen. Alles ausser dem Textinhalt ist in aller Regel völlig belanglos. Links werden immer vollständig angezeigt bevor sie an das System weitergegeben werden und das ist quasi der einzige Dialog. Ein versehentliches Anklicken ist damit weitgehend ausgeschlossen.
Von FairEmail, einer One-Man-Show, könnten sich die Entwickler von Thunderbird, Outlook etc. einiges abschauen. Man fragt sich geradezu, was die anderen Entwickler beruflich machen.
Zeit Dein Fairmail HTML an bzw. nutzt eine HTML Engine zur Darstellung (auch von Nur-Text)? Dann wäre ich mir nicht so sicher.
Von welcher CA ist das S/MIME-Zertifikat denn ausgestellt? Certum? Sectigo? Welche Mail-Clients verwenden die Empfänger? Bei Outlook scheint es so zu sein, dass man sich erst einmal die Zertifikatseigenschaften anzeigen lassen muss. Dann lädt oder validiert Outlook mutmaßlich die Zertifikatskette. Danach wird die E-Mail dann als gültig signiert erkannt. Privat benutze ich ausschließlich FairEmail und damit ist S/MIME trivial zu nutzen. Die größte Hürde bei S/MIME neben € dürfte das Erstellen des CSR sein. Da bin ich mir fast sicher, dass die meisten da nicht auf ein lokales OpenSSL zurückgreifen, sondern den privaten Schlüssel von der CA generieren lassen. Gut, rein theoretisch funktioniert das client-seitig im Browser und wird niemals nie auf den Server hochgeladen. Muss man aber glauben oder im Debugger live beobachten.
Es ist ein Armutszeugnis, was die deutsche Wirtschaft hier liefert. Alle schreien ständig "Ditgitalisierung" und bekommen das selbst nicht hin. Wir hatten uns Ende 24 intensiv damit auseinandergesetzt und recht schnell festgestellt, dass das keine Rocket-Science ist. Selbst wenn das ERP System das nicht unterstützt, gibt es genug Tools, die das übernehmen. Pünktlich zum 01.01.25 waren wir in der Lage X-Rechnungen auszustellen und einzulesen. Was ist seitdem passiert?
Nahezu alle Kunden wollen weiter PDF Rechnungen, weil Sie keine E-Rechnungen verarbeiten können und diese nach wie vor manuell erfassen.
Kaum ein Lieferant ist in der Lage E-Rechnungen zu erstellen. Somit sind auch wir gezwungen, die Rechnungen weiterhin manuell zu erfassen.
Und das betrifft sowohl kleinere Unternehmen, als auch das "Who is Who" der deutschen Top Unternehmen, die SAP, Navision etc. einsetzen.
Vertrieb und Einkauf scheuen das Thema ebenso wie der Teufel das Weihwasser. Man hätte ja noch die Übergangsfrist. Von den 24 Monaten sind aber bereits 13 Monate abgelaufen. Wenn der Gesetzgeber die Übergangsfrist nicht verlängert, kracht es Ende 26 aber so richtig.
So geht Digitalisierung in Deutschland:
https://media.licdn.com/dms/image/v2/C4E22AQEWAnsyb7oQfw/feedshare-shrink_800/feedshare-shrink_800/0/1676034086783?e=1770854400&v=beta&t=sUu3GJ9lxdLVSuRT3z1zo-M5nYGW4NFzPhb9mzGUVaY
Die Unternehmen sind seit 1.1.25 verpflichtet, E-Rechnungen verarbeiten zu können.
Da gibt es keine Übergangsfrist!
Eine Übergangsfrist gibt es nur für die Versendung von E-Rechnungen.
Und seit 1.1.26 muß der Empfänger explizit zustimmen, das man ihm noch herkömmliche Rechnungen anstatt E-Rechnungen zusenden darf.
Man muß da aktiv nach Erlaubnis fragen!
Ohne explizite Erlaubnis, die zu archivieren ist, muß man dem Empfänger E-Rechnungen zusenden.
Die Rechtslage ist mir durchaus bekannt. Vielen anderen vermutlich immer noch nicht. So wurden wir teilweise von Kunden übelst beschimpft (was habt Ihr Euch denn da für einen Schrott ausgedacht).
Allerdings sieht das Gesetz keinerlei Sanktionen bei Verstößen vor und somit wird das im Moment noch "vom Markt geregelt".
Doch, es ist für Verstöße ein Bußgeld von bis zu 5.000,- € möglich.
Zudem kann das Finanzamt auch bei einer Steuerprüfung ziemlich krass reagieren, so das da hohe Steuernachzahlungen auf einen zukommen.
Es gibt aber noch eine Einschränkung:
Ab dem Moment, wo man selbst die erste E-Rechnung versendet hat, kann man keine Papierrechnungen mehr versenden außer an Verbraucher.
Man hat ja den Beweis angetreten, dass man E-Rechnungen versenden kann, die Übergangsfrist gilt nur, bis man es kann.
Du vergisst ausländische Kunden.
Da gilt die ganze E-Rechnungsgeschichte nicht.
Ein Kunde in z.B. Norwegen oder Brasilien kann mit einer X-Rechnung nichts anfangen.
Und bei einer ZUGFeRD-Rechnung wird er nur den PDF-Teil berücksichtigen.
Genau deiner Meinung. 90 % müssten das Feature wohl einfach nur im ERP aktivieren. Voraussetzung natürlich, dass die Stammdaten ordentlich gepflegt sind. Da scheitet es leider schon häufig.
Genau meine Erfahrung!
Unsere bisherige Lösung für mehrere 100 Rechnungen immer zum Jahresanfang: Datenbankexport in CSV, Serienbrief, drucken, eintüten, fertig. Geht mit eRechnung nicht mehr.
Also nun so: Datenbankexport in XML (X-Rechnung), Powershell-Script zum versenden der XMLs, fertig.
DENKSTE! Das war ein Stich ins Wespennest. Kaum einer kann damit was anfangen. Also mittels pdf24tools aus den XMLs ZUGFeRD-Rechungen automatisch generieren lassen, diese dann versenden und gut ist.
Fazit: Digitalisierung? Soooo wichtig wenn es bei anderen hapert, aber selber bekommt man es nicht hin.
So wird das nichts mit der Zukunft…
"Kaum einer kann damit was anfangen."
Das ist aber das Problem des Rechnungsempfängers, denn die Rechtslage ist da eindeutig: Er muss E-Rechnungen verarbeiten können.
Die ablehnende Haltung verschiebt lediglich das Problem auf das Jahresende 26.
Die Wahl der Formate finde ich allerdings fragwürdig. XML und PDF sind für die Zwecke, die sie genutzt werden komplett over engineered. PDF wurde von Adobe entwickelt und auch weiterhin dominiert.
Statt XML hätte man auch wesentlich schlankeres und lesbares JSON nehmen können. Ja, es gibt dafür etablierte Bibliotheken und Tools, aber die Komplexität dahinter ist eben Wahnsinn für so etwas eigentlich Triviales. Einen einfachen Ersatz für PDF kenne ich nicht, aber so wie es verwendet wird würde da auch ein PNG oder JPEG reichen.
Man lacht über die Leute, die Brötchen mit dem SUV holen. Dabei holt man in der IT Auftau-Brötchen mit dem Flugzeugträger.
Bei unserem Handwerksbetrieb erhalten wir nur von 3 der ca. 50 Kreditoren E-Rechnungen. Zum Glück alle im ZUGFeRD-Format.
Ich selber halte das für großen Scheiß. Das Format ist nicht so einheitlich, wie im großen TamTam angekündigt und als Sicher kann man das nun auch nicht bezeichnen. Der Wegfall des Papieres und der PDF (X-Rechnung) macht Austausch von Kontonummern und Inhalten wesentlich leichter, da die klassische Sichtkontrolle nun mit einer richtig Zeit kostenden Hürde erschwert wird. Die Sichtkontrolle ist notwendig, da immer mehr und immer bessere gefälschte Rechnungen ankommen. So erhalten wir für unser Hosting auf jede echte Rechnung ca 5 nicht echte Rechnungen. Es ist fraglich, ob Programme auf verdächtige Änderungen aufmerksam machen oder nur die Daten einfach so zur Überweisung vorbereiten. Es ist noch fraglicher, ob es hier je überhaupt eine vernünftige für KLEINBETRIEBE geeignete sichere Lösung geben wird. Man bedenke. Der Kunde wird bei einer Entscheidung zwischen einer Firma mit 90 € pro Handwerkerstunde und einer Firma mit 100 € pro Handwerkerstunde nicht wissen und beachten, dass die 10 € extra für die Umsetzung sicherer EDV erforderlich sind.
Das ist leider eine typische Haltung, die Digitalisierung in Deutschland verhindert.
Vermutlich hast Du Dich mit dem Thema noch nie ernsthaft auseinandergesetzt. Anders lassen sich diese Mutmaßungen nicht erklären.
Eine Kontrolle der Daten ist auf jeden Fall erforderlich. Die Kontonummern sind sowieso im Lieferantenstamm hinterlegt und lassen sich durch eine abweichende Bankverbindung auf der Rechnung nicht überschreiben. Der gesamte Rechnungsbeleg wird bei der Elektronischen Rechnung eingelesen und die Daten im ERP System visualisiert und vorausgefüllt. Abweichungen sind sofort erkennbar. Fehler, die beim händischen Erfassen einer Rechnung passieren können, sind aber ausgeschlossen.
Sie wissen schon, dass wir so neben der EDV auch noch andere Dinge zu tun haben? Wie viel zusätzliche Prozent währen Sie denn als Endkunde bereit, dafür zu zahlen, dass wir ein digitaler Handwerksbetrieb mit sicherer EDV sind?
Zu " Digitalisierung in Deutschland verhindert" – halte ich für den Witz des Jahres. Im Vorfeld der ganzen Geschichte ging mir so der Gedanke durch den Kopf: Warum gibt es keine Referenzimplementierung von staatlicher Seite? Vielleicht habe ich es übersehen: Ein Portal, wo ich als Kleinunternehmen meine eRechnungen drüber erstellen, versenden und verwalten kann – und für ERP-Systeme sowie andere Software könnte eine API bereitgestellt werden, um die eRechnung einzuspeisen.
Stattdessen wurden erste Testimplementierungen vor Jahren bereits gelöscht (ist mir aufgefallen, als ich 2024 erste Recherchen anstellte und Links gebrochen waren). Und die Verantwortlichen, die die Regularien festlegen, denken meiner Information nach bereits über weitere Profile nach (im Golem-Artikel war so etwas angerissen). Wenn ich es nicht verpeilt habe, hier wurde Italien genannt – eine Implementierung, verpflichtend ab Tag X – scheint dort (mein Eindruck) praxisnah umgesetzt worden zu sein.
Best Practice:
Einfach eine separate Mailadresse ausschließlich für den Empfang von E-Rechnungen einrichten!
Und den Spamfilter richtig konfigurieren!
Alle E-Rechnungen, die auf anderen Mailadressen rein kommen, zurückweisen!
Ach Handwerker… die arbeiten wie Jesus, der doch einst sagte "Gebt dem Staat (=Augustus), was dem Staate ist" und verdiente seinen Lebensunterhalt unter der Hand ;-)
Ich kenne keinen Handwerker die nicht auch abends und an Wochenenden an "privaten" Baustellen arbeitet… und der zwischen "offiziell" und "inoffiziell" unterscheidet…
Daran wird sich auch in Zukunft nichts ändern…
Also für die offiziellen Rechnungen ein wenig mehr Arbeit, für den Rest ändert sich nischts… kannst Dich wieder legen…
Rechnungen musst du doch so oder so prüfen. Egal ob Papier oder Digital. Und als Kleinunternehmer sollte man auch grob im Kopf haben was man bestellt hat und was nicht.
Ich kann dir wirklich dringend empfehlen einen guten IT'ler zu suchen. IT verursacht richtig umgesetzt nicht nur kosten, sondern erleichtert auch die Arbeit ungemein.
Das schlimmste was man als Unternehmer machen kann, ist auf der Stelle stehen zu bleiben. Früher oder später wird dir das auf die Füße fallen.
Hier mal ein paar kostenlose Tools, alles installierbare Programme, die nichts ins Internet übertragen dürften:
Tool zum Erstellen von ZugFerd:
https://github.com/OpenIndex/ZUGFeRD-Manager
Tool zum Visualisieren von X-Rechnungen und dem XML Inhalt von ZUGFeRD PDFs:
https://quba-viewer.org/
dto. aber mit Validierungstool:
https://jcthiele.github.io/OpenXRechnungToolbox/
Ich verwende die OpenXRechnungToolbox sehr häufig, da sich damit auch ein Prüfreport generieren lässt, den man dem Rechnungssteller übermitteln, ggf. auch um die Ohren hauen kann.
Die OpenXRechnungToolbox wurde von Jan C. Thiele entwickelt. Dr. Dr. Jan C. Thiele war hauptberuflich Referent und stv. Referatsleiter beim Senator für Finanzen der Freien Hansestadt Bremen. Er ist einer der Autoren des Standards XRechnung, hat das EU-Projekt "Peppol eInvoicing für Government in Germany" (PeGGy) für Bremen durchgeführt und war Vertreter Bremens im Steuerungskreis von XRechnung.
Danke für die Links. Ich will in Teil 2 einige kommentierte Lösungen vorstellen. Den ZUGFeRD-Manager muss ich mir noch anschauen.
Der ZUGFerd-Manager machte auf den ersten Blick Hoffnung so was wie e-studio offline zu sein, erweist sich dann in der Praxis aber leider als völlig nutzlos. Ich zieh mein PDF rein und muss dann ALLES noch einmal komplett manuell ausfüllen??? Da brauche ich eine Stunde für eine Rechnung, nein danke. Wenn ich ein lesbares PDF rein ziehe sollte das auch maschinell soweit vor verarbeitet werden wie nur möglich. Oder übersehe ich da was? Außerdem kommen meine PDFs aus dem ERP System ohne /a und das ist auch nicht änderbar.
Offenbar gibt es noch immer keine kostenlose Lösung für Kleinunternehmen mit 10-50 Rechnungen pro Monat, die fertige PDFs einfach verarbeiten können ohne Cloud, Abo und Datenschutzproblemen.
Nein, so funktioniert das nicht, was auch meine Chef immer noch nicht begriffen hat. Im XML hast du genau definierte Datenfelder. Aus einem PDF lässt sich nur in seltenen Fällen eine klare Zuordnung "Text zu Datenfeld" machen. Daher funktionieren bisherige Lösungen, die Rechnungen rein visuell definiert haben, nicht mehr. Solange bei einem Wert keine Klassifizierung möglich ist, kann da auch keine e-Rechnung daraus werden.
Wenn es um OpenSource geht, schaut Euch doch mal Kivitendo an!
Das ist ein komplettes webbasiertes ERP-System und man kann seine Vorlagen mit LaTeX bauen — man muss "nur" die vorinstallierten LaTeX Dateien bearbeiten!
Die haben ZUGFeRD schon seit 2020 (siehe Homepage) dirn und bauen das direkt in die via LaTeX generierten PDF'-Dateien ein!
Wir wären schon mal einen großen Schritt weiter, wenn die Leute schlicht on-premises eine schnell einrichtbare Lösung hätten. Mir ging das von dir Genannte kurz durch den Kopf. Ich war auf der kivitendo-Seite. Erzähle mal einem Kleinstgewerbetreibenden oder deinem Bäcker "brauchst doch nur kivitendo auf UCS 3.0 installieren" – dann ist der glücklich. Mich hat das Ganze sofort in einem weiten Bogen reißaus nehmen lassen.
OK — haette ich dazu schreiben sollen: eine kleine "mal eben"-Loesung ist das ganz und gar nicht!!!
Aber: ab einer bestimmten Groesse und gutem IT Support koennte es eine Alternative sein! Keine Lizenzkosten, aber Arbeit (bei Ersteinrichtung), aber absulute Freiheit!!!
Noachmal aber: selbstaendige ITler mit Linux-Kenntnissen koennten sich Kivitendo auf jeden Fall mal anschauen :-)
Ein schönes Beispiel dafür, dass Open-Source alles andere als umsonst, geschweige denn billig ist.
https://kivitendo.de/services/service-pakete.html
Dass die dort befindlichen Links zu den Details der heftig teuren Supportangebote ins Leere führen, spricht auch nicht für eine Cloud Lösung.
Und das Teil kann auf den ersten Blick auch nicht wirklich viel.
Hallo,
nicht zu vergessen bei den Links.
https://www.mustangproject.org/?lang=de
Infos. freie Java Bibliothek und einige Tools und Links
Viel Spaß
Da hier ganz viele Angebote schon genannt wurden, will ich noch auf eines Hinweisen, was noch arg fehlt:
https://github.com/itplr-kosit/
Dort gibt es Referenzimplementierungen (auf denen auch sehr viele andere "Produkte" aufbauen).
Womit wir dann über die KoSIT auch bei https://xeinkauf.de/ landen.
Was sie allerdings nicht anbieten ist irgendwas direkt über Oberfläche/Webseite direkt nutzbares.
Die Österreicher waren da weiter. Aber ich habe gerade gesehen, das dort das Zertifikat abgelaufen ist, so dass man da nichts mehr aufrufen kann. Die hatten schön per Webformular Prüftools und Konverter.
Aber auch aus Österreich gibt's Quellcodes:
https://github.com/austriapro
Einen Konverter gibts noch unter:
https://labs.ebinterface.at/labs
Die ERP-Schmiede aus Waldorf kann auch nichts davon ab Werk.
Regulatorik und Verordnung können wir weltmeisterlich. Echte Lösungen um zumindest den Einzelkämpfern, Kreativen, Vereinen etc. die Handhabe zu ermöglichen können wir nicht.
Die Softwareschmieden der entsprechenden Programme in die Pflicht nehmen geht ja offenbar auch nicht, wie xbrl seit über 22 Jahren beweist.
Stattdessen wird bald jeder einzelne gegeißelt, sich abseits seines Kerngeschäfts damit zu beschäftigen oder dafür zu zahlen, sobald Rechnungen gestellt werden.
Garantiert volle Brieftaschen für Berater, Behörden, Bußgeldstellen und Anwälte. Wen interessieren da praktikable Lösungen oder gar das eigentliche Ziel der Interoperabilität sowie der flotten Umsetzungen?
Das Ziel ist doch nicht Interoperabilität. Wenn sie das Ziel wäre, hätte es gereicht, eine gute Referenzimplementierung zu machen, als Staat irgendwelche Incentives für Nutzer der Formate rauszugeben und ein bisschen Werbung zu machen. Per se ist das auch gar keine hoheitliche Aufgabe, sondern Sache, die die Wirtschaft wie auch immer selbst regeln kann, wenn sie will – oder aber nicht.
Das ganze Tamtam unter falscher Flagge ist schlicht dazu da, dass künftig alle Rechnungen übers Finanzamt laufen und dort automatisch verarbeitet werden können. Es geht darum, Steuereuros zu generieren. Die Kosten und die Aufwände sind dem Staat egal und konterkarieren natürlich das gleichzeitige Gefasel von Bürokratieabbau etc.
Ich bin selbst Betreiber einer Online-Lösung für die Umwandlung von PDF-Rechnungen in E-Rechnungen (sowohl XRechnung als auch ZUGFeRD). Ich kann die Argumentation zu Cloud und Datenschutz durchaus verstehen, als auch die bewusste Entscheidung, dass man etwas On-Premise haben möchte. Der Einsatz von KI ist ohne Cloud-Dienstleister quasi kaum mehr möglich (aus verschiedenen Gründen).
Für einen viel wichtigeren Grund für den Einsatz einer Online-Lösung möchte ich aber dennoch sensibilisieren: Updates. Gerade im Bereich E-Rechnungen ist es ratsam, aktuelle Versionen einzusetzen. So wurde erst jetzt im Januar die Version 2.4.0 von ZUGFeRD freigegeben. Ältere Versionen sind in der Regel noch eine Weile nutzbar, werden zum Teil aber auch abgekündigt und können dann zuünftig steuerrechtliche Probleme verursachen. Mit SaaS-Angeboten muss man sich dahingehend nicht mehr kümmern.
Wir haben Ausgangsrechnungen mit ZUGFeRD für das hauseigenen Rechnungssystem hier zum Jahreswechsel umgesetzt. Das war eigentlich kein großer Akt. CSV-Dateien mit den Rechnungsdaten haben wir schon lange mit verschickt, da waren alle Daten schon vorbereitet. Etwas gestolpert sind wir über die Notwendigkeit, Einheiten aus einer festgelegten Liste wählen zu müssen. Wir hatten irgendwie Freitext erwartet… Dinge wie "1 Sowieso / 6 Wochen" und was sich so im Lauf der Jahrzehnte an Wunderlichkeiten einschleicht, gab es dort nicht. Da mussten unerwartet die Datenbestände angepasst werden. Aber alles in allem war das auch Dank der horstoeko/zugferd Bibliothek und der zugehörigen guten Doku (Dank an den Autor!) kaum mehr als ein Manntag. (easybill /zugferd-php hatten wir schnell verworfen, einfach, aber für unsere Zwecke zu stark abstrahiert.) OpenSource und eigene Software sind ein gutes Team ;-)