Für Nutzer von RechnungFertig ist dabei vor allem wichtig:
RechnungFertig orientiert sich primär am Profil EN16931 der ZUGFeRD-Spezifikation. Dieses Profil bildet den gesetzlich relevanten Kern für elektronische Rechnungen ab. Viele der jetzt genannten Änderungen betreffen dagegen vor allem das umfangreichere Profil EXTENDED und sind deshalb für typische RechnungFertig-Anwendungsfälle meist nicht relevant.

Was sich mit ZUGFeRD 2.5 ändert

Die neue Version aktualisiert vor allem:

• Validierungsartefakte
• Codelisten
• Schematron- und XSD-Dateien
• die technische Basis auf UN/CEFACT CII D22B
• verschiedene Regeln und Elemente im Profil EXTENDED

Außerdem wird ausdrücklich darauf hingewiesen, dass leere XML-Elemente vermieden werden müssen. Wenn optionale Felder keinen Inhalt haben, sollen sie nicht leer in die XML-Datei geschrieben werden, sondern vollständig entfallen. Sonst kann bei der Prüfung die Meldung erscheinen:

„Document MUST not contain empty elements“

Das ist eine technische Validierungsregel und betrifft vor allem die korrekte Erzeugung der XML-Daten im Hintergrund.

Warum viele Änderungen für RechnungFertig-Nutzer kaum spürbar sind

Ein großer Teil der Neuerungen betrifft das Profil EXTENDED. Dort wurden unter anderem neue Angaben für Steuerbefreiungsgründe, Zahlungsinformationen, Zahlungen im Auftrag Dritter und bestimmte Referenz-Codelisten ergänzt.

Diese Erweiterungen sind vor allem für komplexere Geschäftsvorfälle, internationale Anforderungen und die Interoperabilität mit der französischen B2B-E-Rechnungspflicht gedacht.

Für typische RechnungFertig-Nutzer, die einfache, gesetzeskonforme Rechnungen schreiben möchten, ist das meist nicht entscheidend. RechnungFertig konzentriert sich auf den praktischen Kern: Rechnungen korrekt erstellen, E-Rechnungspflichten erfüllen und dabei einfach bedienbar bleiben.

Was bleibt wichtig

Für Nutzer zählt vor allem:

ZUGFeRD 2.5 ist rückwärtskompatibel.
Die neue Version ist technisch weiterentwickelt, bricht aber nicht grundsätzlich mit bisherigen Versionen.

Das Profil EN16931 bleibt der zentrale Orientierungspunkt.
Für die meisten gesetzeskonformen E-Rechnungen ist nicht das maximal umfangreiche EXTENDED-Profil entscheidend, sondern die saubere Umsetzung der EN16931-Anforderungen.

Formate wie XRechnung und ZUGFeRD bauen auf dieser Norm auf. Deshalb ist die neue Fassung EN 16931-1:2026 auch für alle interessant, die sich mit der E-Rechnungspflicht beschäftigen – vom großen Unternehmen bis zum kleinen Einzelunternehmer.

Die gute Nachricht vorweg:
Für viele kleine Selbstständige, Freelancer und Einzelunternehmer dürfte sich durch die neue Norm im Alltag erst einmal wenig ändern. Die neue Fassung bringt vor allem mehr Klarheit und technische Erweiterungen für komplexere Geschäftsvorfälle. Wer nur wenige einfache Rechnungen im Monat schreibt, wird von dieser zusätzlichen Komplexität meist kaum direkt betroffen sein.

Was ist die EN 16931 überhaupt?

Die EN 16931 beschreibt das europäische Datenmodell für elektronische Rechnungen. Vereinfacht gesagt: Sie definiert, welche Pflichtangaben und Datenstrukturen eine elektronische Rechnung enthalten muss, damit sie europaweit verstanden und verarbeitet werden kann.

Dazu gehören zum Beispiel:

• Angaben zu Rechnungsaussteller und Rechnungsempfänger
• Rechnungsnummer und Rechnungsdatum
• Leistungsbeschreibung
• Beträge, Steuersätze und Steuerbeträge
• Zahlungsinformationen
• Referenzen wie Bestellnummern oder Lieferangaben

Damit bildet die Norm die fachliche Grundlage für E-Rechnungsformate wie XRechnung und ZUGFeRD. Diese Formate sorgen dafür, dass Rechnungen nicht nur als PDF lesbar sind, sondern auch strukturierte Daten enthalten, die von Software automatisch verarbeitet werden können.

Was ist neu an der EN 16931-1:2026?

Die neue Version der Norm wurde erstmals seit 2017 umfassend überarbeitet. Ziel war es, die Norm näher an die Praxis heutiger Geschäftsprozesse anzupassen und sie gleichzeitig auf kommende europäische Anforderungen vorzubereiten.

Ein Schwerpunkt liegt auf der besseren Abbildung komplexerer B2B-Geschäftsvorfälle. Die neue Norm kann zum Beispiel differenzierter mit mehreren Bestellungen, mehreren Lieferungen oder verschiedenen Referenzen innerhalb einer Rechnung umgehen. Auch Zahlungsbedingungen, Rollen der beteiligten Parteien und Identifikatoren wurden präziser beschrieben.

Für größere Unternehmen, Lieferketten, öffentliche Auftraggeber oder Branchen mit komplexen Rechnungsprozessen ist das wichtig. Dort kommt es häufig vor, dass eine Rechnung mehrere Vorgänge zusammenfasst oder viele Referenzen enthalten muss.

Weniger Interpretationsspielraum, bessere Verarbeitung

Ein weiteres Ziel der neuen Norm ist mehr Eindeutigkeit. Viele Begriffe und sogenannte Business Terms wurden überarbeitet, genauer definiert oder technischer sauberer beschrieben.

Das ist vor allem für Softwareanbieter und größere Organisationen relevant. Je klarer die Regeln sind, desto geringer ist das Risiko, dass verschiedene Systeme dieselbe Rechnung unterschiedlich interpretieren.

Für die Praxis bedeutet das: E-Rechnungen sollen zuverlässiger verarbeitet werden können. Fehler durch unterschiedliche Auslegungen sollen seltener auftreten. Gerade bei automatisierten Prozessen ist das ein wichtiger Schritt.

Vorbereitung auf ViDA und digitale Umsatzsteuer-Meldungen

Die neue EN 16931-1:2026 bereitet außerdem auf kommende europäische Vorgaben wie ViDA vor. ViDA steht für „VAT in the Digital Age“ und beschreibt europäische Pläne zur Digitalisierung der Umsatzsteuerprozesse.

Langfristig sollen elektronische Rechnungen nicht nur zwischen Unternehmen ausgetauscht werden, sondern auch eine Grundlage für digitale, transaktionsbasierte Steuer- und Umsatzsteuer-Meldungen bilden.

Die neue Norm enthält deshalb zusätzliche Datenpunkte und Strukturen, die künftig für solche Meldepflichten wichtig werden könnten. Die E-Rechnung wird damit zunehmend zu einem zentralen Baustein digitaler Steuerprozesse.

Fazit

Die neue EN 16931-1:2026 ist ein wichtiger Schritt für die europäische E-Rechnung. Sie macht das Datenmodell robuster, klarer und besser vorbereitet auf kommende digitale Meldepflichten. Für große Unternehmen und Softwarehersteller ist das eine relevante technische Weiterentwicklung.

Was bedeutet das für Einzelunternehmer und kleine Selbstständige? Für die meisten Nutzer von RechnungFertig sind die unmittelbaren Auswirkungen eher gering.

Warum Vereine Rechnungen ausstellen

Viele Vereine finanzieren sich durch Mitgliedsbeiträge, Spenden und Zuschüsse – Einnahmen, die steuerfrei sind. Daneben können sie aber auch Umsätze erwirtschaften, die eine ordnungsgemäße Rechnung erfordern. Dazu gehören zum Beispiel:

• Vermietung von Vereinsräumen oder Sportplätzen an Mitglieder und externe Unternehmen.
• Verkauf von Fanartikeln, Trikots oder Vereinschroniken.
• Teilnahmegebühren für Turniere, Konzerte oder Trainingskurse.
• Werbeflächen und Sponsoring wie Bandenwerbung bei Fußball‑ oder Schützenfesten, die mit dem vollen Umsatzsteuersatz abgerechnet werden müssen.

In den ersten drei steuerlichen Bereichen (ideeller Bereich, Vermögensverwaltung und Zweckbetrieb) sind Einnahmen meist steuerfrei. Dagegen unterliegt der wirtschaftliche Geschäftsbetrieb der Umsatzsteuer, sodass dort Rechnungen mit korrekter Mehrwertsteuer notwendig werden. Genau in diesem Bereich greift die neue E‑Rechnungspflicht.

Die E‑Rechnungspflicht für Vereine ab 2025

Deutschland setzt ab dem 1. Januar 2025 die EU‑Vorgaben zur elektronischen Rechnung (E‑Rechnung) um. Wirtschaftsvereine müssen ihre Rechnungen an Unternehmen oder Organisationen ab diesem Stichtag elektronisch im strukturierten Format (XRechnung oder ZUGFeRD) ausstellen. Das bedeutet: Ein PDF per E‑Mail reicht künftig nicht mehr; die Rechnung muss maschinenlesbar sein. Privatpersonen und ehrenamtliche Mitglieder sind davon ausgenommen.

Es gelten Übergangsfristen: Vereine dürfen bis Ende 2026 weiter Papierrechnungen oder einfache PDFs versenden, sofern der Empfänger zustimmt. Darüber hinaus haben Vereine mit einem Umsatz unter 800 000 € (was wahrscheinlich die meisten betreffen wird ;-)) Zeit bis Ende  2027. Ab 2028 müssen alle Vereine, die im wirtschaftlichen Bereich tätig sind, E‑Rechnungen versenden. Unabhängig vom Umsatz müssen alle ab 2025 in der Lage sein, E‑Rechnungen zu empfangen.

Für folgende Rechnungen gibt es keine E‑Rechnungspflicht:

• Rechnungen an Privatpersonen (Mitgliedsbeiträge, Spendenbescheinigungen).
• Umsatzsteuerfreie Umsätze wie Seminargebühren.
• Kleinbetragsrechnungen bis 250 €.
• Geschäfte mit ausländischen Kunden.
• Vereine, die die Kleinunternehmerregelung (Umsatz bis 25 000 €/Jahr) anwenden.

Welche Vereine sind betroffen?

Die Pflicht betrifft insbesondere Vereine, die wirtschaftlich tätig sind, beispielsweise:

• Sportvereine, die Vereinsheime vermieten oder Werbeflächen für Sponsoren abrechnen
• Musikvereine und Chöre, die Konzertkarten oder Merchandise in größeren Stückzahlen verkaufen.
• Schachvereine mit Turniergebühren oder Kursangeboten für Mitglieder und Gäste.
• Schützenvereine, die Schießstände vermieten, Veranstaltungen ausrichten oder Gastronomie betreiben.

Warum eine E‑Rechnung?

E‑Rechnungen sind nicht nur gesetzliche Pflicht, sie bieten auch Vorteile:

• Automatische Verarbeitung: Die maschinenlesbare Struktur (XML) ermöglicht eine automatische Buchung und Archivierung.
• Zeitersparnis und weniger Fehler: Weder beim Empfänger noch beim Verein müssen Daten manuell erfasst werden.
• Transparenz und Nachvollziehbarkeit: Behörden können schneller prüfen, was Steuerbetrug erschwert.

Wie können Vereine die Umstellung meistern?

Die Umstellung erfordert geeignete Software. Für wenige Rechnungen lohnt sich jedoch häufig keine teure Cloud‑Lösung. Hier kann daher RechnungFertig eine Alternative sein:

• Einmal kaufen statt Abo: Für Vereine mit kleinem Budget fallen keine laufenden Kosten an.
• Lokale Speicherung ohne Cloud: Alle Daten bleiben auf dem Vereinsrechner bzw. in der eigenen Infrastruktur – ideal für Vereine, die Datenschutz schätzen.
• E‑Rechnung per XRechnung oder ZUGFeRD: RechnungFertig generiert strukturierte E‑Rechnungen gemäß geltenden Standards. Zusätzlich wird ein lesbares PDF produziert, sodass der Kassierer die Rechnung prüfen kann.
• Weiterverwendung von Word‑Vorlagen: Vereine können ihre bestehenden Word‑Rechnungsvorlagen weiterhin nutzen und automatisch mit Daten befüllen.
• Einfach und offline: Die Software ist intuitiv, funktioniert ohne Internet und eignet sich für wenige Rechnungen pro Monat

Fazit

Ab 2025 wird die elektronische Rechnung zur Pflicht für wirtschaftlich tätige Vereine. Übergangsfristen erleichtern den Einstieg, ab 2028 ist die elektronische Rechnung allerdings für alle Pflicht.

Weiterführende Links

• Deutsches Ehrenamt – Die vier steuerlichen Sphären im Verein
• FeRD (ZUGFeRD / Factur-X, Standards & Downloads): https://www.ferd-net.de/en/standards/zugferd/factur-x

Variablen in Rechnungsvorlagen einsetzen

Die Templatesprache funktioniert standardmässig mit Platzhaltern in geschweiften Klammern.

Beim Generieren der Rechnung ersetzt die Software diese Variablen automatisch mit den passenden Daten.

Damit das Befüllen der Rechnungsvorlage effizient ablaufen kann, kann man innerhalb des Programms über die Einstellungen auf der Rechnungsseite die Schlüsselwörter zu den Feldern sichtbar machen. Ein Klick auf das Schlüsselwort führt dazu, dass das Wort mit der korrekten Platzhalterformatierung in die Zwischenablage kopiert wird, so dass man es von da aus in der Word-Vorlage gleich einfügen kann:

Datumsformat richtig darstellen (fdate)

Mit Hilfe der Funktion fdate() lässt sich das Datum mit führenden Nullen darstellen:

Beispiel:

{fdate(rdatum)} für 13.6.2026 wird zu 13.06.2026

Internationale Datumsformate

Die Funktion unterstützt auch lokalisierte Datumsformate.

Beispiel:

{fdate(rdatum, 'de-DE')}    // 13.06.2026
{fdate(rdatum, 'fr-FR')}    // 13/06/2026

Dadurch passt sich die Darstellung automatisch an landesspezifische Konventionen an.

Geldbeträge korrekt formatieren (fnum)

Geldbeträge können mit der Funktion fnum() dargestellt werden, durch die Tausendertrenner und Dezimalstellen für Cent-Beträge korrekt formatiert werden.

Beispiel:

{fnum(totalbrutto)} €

Das Ergebnis wird automatisch korrekt formatiert:

1.250,00 €

Auch hier lässt sich optional ein Locale-Code verwenden, um die Beträge an länderspezifische Darstellungsweisen anzupassen.

{fnum(totalbrutto, 'de-DE')}
{fnum(totalbrutto, 'en-US')}

Damit ändern sich automatisch:

• Dezimaltrennzeichen
• Tausendertrennzeichen

Rechnungspositionen automatisch erzeugen

Listen, insbesondere für Rechnungspositionen und für Abschläge, können dynamisch erzeugt

Im Template wird dafür eine Schleife verwendet:

{FOR p in positions}

{$p.anr}
{$p.aname}
{$p.amenge}
{fnum($p.anetto)} €
{fnum($p.asum)} €

{END-FOR p}

Dadurch werden alle Rechnungspositionen automatisch eingefügt. Wird der innere Teil der Schleife in einer Tabellenzeile benutzt, so wird diese Tabellenzeile automatisch wiederholt.

Und so sieht die Schleife für Abschläge aus.

{FOR a in abschlaege}

{$a.abgrund}: {fnum($a.abbetrag)} €

{END-FOR a}

Dadurch erscheinen diese Informationen nur dann auf der Rechnung, wenn sie tatsächlich vorhanden sind.

Eigene Logik mit JavaScript im Template

Innerhalb der Rechnungsvorlagen kann klassisches Javascript benutzt werden, um komplexere oder speziellere Anforderungen zu erfüllen. Da leider die geschweiften Klammern der Standardeinstellungen mit den geschweiften Klammern im Javascript-Kollidieren, ist daher zu empfehlen, dass zuerst die Markierungszeichen für die Platzhalter in RechnungFertig umgestellt werden. Das geht in den Einstellungen

Danach können zum Beispiel Javascript-Funktionen definiert werden:

+++! days = (a,b) =>{
const p=s=>{let[d,m,y]=s.split('.');return new Date(y,m-1,d, 0, 0, 0)};
return Math.ceil((p(b)-p(a))/86400000)
} ;---

Tage bis Fälligkeit: +++days(bt2,bt9)---

In der gerenderten Rechnung wird der Javascript-Code nicht angezeigt, aber die Funktionen können genutzt werden, um, wie oben gezeigt, die Differenz in Tagen zwischen zwei Datumsangaben zu berechnen. Im gerenderten Template erscheint dann zum Beispiel:

Tage bis Fälligkeit: 30

Dieses Code-Beispiel zeigt auch, dass das Datum in bt2 und bt9 bereits als gerenderter String in den Rechnungsvorlagen vorliegt in der Form D.M.YYYY und deshalb im Template erneut geparst und in ein Date-Objekt umgewandelt werden muss. Das liegt daran, dass ohne die Vorumwandlung des Datums-Objekt vor dem Rendervorgang weniger technisch versierte Nutzer sich standardmässig um die Konvertierung des Datums in ein String-Objekt kümmern müssten.

Rechnungstypen

Ein Kernpunkt sind Rechnungen mit verschiedenen Rechnungstypen (Business Term 3). Damit lassen sich unterschiedliche Geschäftsfälle klarer abbilden, ohne Workarounds oder manuelle Umbenennungen im Dokument. Durch ein Popup, das über das Fragezeichensymbol aufrufbar ist, gibt es zudem weitere Erklärungen dazu, wie insbesondere Gutschriften bzw. negative Rechnungen je nach Kontext erstellt werden sollten.

XRechnung

XRechnungen können nun explizit erzeugt werden. Das ist vor allem relevant, wenn Sie für öffentliche Auftraggeber arbeiten (B2G), denn dort ist die strukturierte E-Rechnung mitlerweile Pflicht. Wenn also Ihre Kunden XRechnung verlangen, müssen Sie nicht mehr auf externe Umwege ausweichen, sondern können den Prozess direkt abbilden.

Weitere Neuerungen

Zu den weiteren Neuerungen gehört, dass Rechnungen nun im CSV-Format exportiert werden können. Der CSV-Export beinhaltet dabei wirklich alle Daten der Rechnung, so dass nachgelagerte Use Cases von EÜR bis Verkaufsartikelanalysen durchgeführt werden können. Außerdem gehört jetzt das Email-Feld auf Käuferseite dazu, was insbesondere bei XRechnungen wichtig ist. Last-but-not-least wurde das Dark-Theme vervollständigt, so dass Nutzer, die eher in den Abendstunden arbeiten, nun eine etwas augenschonendere Oberfläche am Abend aktivieren können.

Der entscheidende ZUGFeRD-Punkt wird oft unterschätzt: Das „schöne“ PDF ist nur die Sicht für Menschen – maßgeblich für die E-Rechnung ist der strukturierte XML-Teil. Das BMF stellt klar, dass umsatzsteuerliche Pflichtangaben im strukturierten Teil enthalten sein müssen. Heißt für Kleinunternehmer: Auch wenn du keine Umsatzsteuer ausweist, darf deine Rechnung nicht „irgendwie abgespeckt“ sein. Ein Klassiker ist: Im PDF steht korrekt „§ 19“, aber im XML fehlen Pflichtfelder oder es stehen noch 19 % drin, weil die Software ein Standard-Steuerprofil gezogen hat. Ergebnis: Der Empfänger kann nicht automatisiert buchen – und du hast unnötigen Aufwand.

Ein häufiger Irrtum lautet: „Als Kleinunternehmer muss ich keinen Steuersatz angeben, also kann ich Umsatzsteuer komplett ignorieren.“ Richtig ist: Du stellst ohne Umsatzsteuerausweis in Rechnung, aber der Grund muss erkennbar sein – der Kleinunternehmer-Hinweis gehört sauber auf die Rechnung. Seit 01.01.2025 werden die Anforderungen für Kleinunternehmer-Rechnungen zudem praktisch über die Sonderregel § 34a UStDV greifbarer, weshalb sich ein eigenes Template lohnt (statt eine „normale USt-Rechnung“ nur auf 0 zu setzen). Für deine Vorlagen bedeutet das: Im PDF keine USt-Beträge und keine Prozent-Steuersätze anzeigen, aber den §-19-Hinweis klar platzieren (z. B. im Fußbereich oder unter der Summenzeile).

Damit es in ZUGFeRD wirklich „wasserdicht“ ist, musst du den Hinweis zweigleisig denken: sichtbar im PDF und konsistent im XML. Im PDF haben sich kurze, eindeutige Formulierungen bewährt, z.B.:
– „Gemäß § 19 UStG wird keine Umsatzsteuer berechnet.“
– „Rechnungsstellung ohne Ausweis der Umsatzsteuer gemäß § 19 UStG.“
Optional (gerade bei B2B hilfreich, um Rückfragen zu vermeiden): „Ein Vorsteuerabzug ist aus dieser Rechnung nicht möglich.“
Im XML wiederum darfst du die Umsatzsteuerlogik nicht „leer lassen“ oder widersprüchlich befüllen: Typische Implementierungen arbeiten mit 0-Werten (Steuerbetrag/Steuersatz) plus Befreiungs-/Begründungstext (Exemption Reason). Entscheidend ist weniger die Wortwahl, sondern dass PDF-Aussage und XML-Daten dasselbe sagen – und dein Export eine EN-16931-Validierung besteht.

Der wichtigste Anwendungsunterschied ist also das Einsatzszenario: B2G (Rechnung an Behörden/öffentliche Auftraggeber) ist der Bereich, in dem XRechnung in der Praxis verlangt wird – inklusive Pflichtangaben wie Leitweg-ID/Buyer Reference oder Bestellbezug, sonst wird die Rechnung schnell abgewiesen. Im B2B-Alltag (Agenturen, KMU, andere Selbständige) liessen sich XRechnungen theoretisch auch verwenden, aber ZUGFeRD ist hier eher die stressfreiere Lösung, weil sich Rechnungen intern leichter prüfen, weiterleiten und „auf Sicht“ freigeben lassen – und trotzdem bereits die strukturierten Daten für die Buchhaltung/ERP enthalten. Wichtig: Beide Formate können grundsätzlich EN 16931-konform sein, entscheidend ist also weniger „legal oder nicht“, sondern was Ihr Kunde akzeptiert und technisch verarbeitet.

Rechtlich hat sich der Druck seit 2025 klar erhöht (Stand 16.01.2026): Unternehmen müssen seit 01.01.2025 grundsätzlich E-Rechnungen empfangen können, während es fürs Ausstellen im B2B-Bereich Übergangsregeln gibt. Praktisch heißt das für Freiberufler: Sie sollten spätestens jetzt in der Lage sein, strukturierte E-Rechnungen zu erzeugen – auch wenn Sie in der Übergangszeit ggf. noch mit klassischen PDFs arbeiten dürfen (oft aber nur mit Zustimmung des Empfängers). Spätestens wenn Kunden aktiv E-Rechnungen anfordern oder ihre Buchhaltung auf automatisierte Prozesse umstellt, wird ein „nur-PDF“-Workflow auf Dauer schwierig.

Die klassische Gutschrift (Typ 381) ist die richtige Wahl, wenn Sie dem Empfänger einen Betrag gutschreiben möchten (z.B. Rückerstattung, Bonus, Preisnachlass nachträglich, Kulanz), ohne zwingend eine bestehende Rechnung „zu stornieren“. Wichtig dabei: Die Gutschriftwirkung entsteht ausschließlich über den Dokumenttyp 381 – nicht dadurch, dass Sie Beträge negativ ausweisen. In der typischen ZUGFeRD/EN-16931-Umsetzung werden Positionswerte (Netto/Steuer/Brutto) ganz normal positiv befüllt, so wie bei einer normalen Rechnung. Das ist ein häufiger Stolperstein, weil manche Anwender intuitiv alles „ins Minus drehen“ – was dann je nach Empfängerprozess zu Rückfragen oder Ablehnungen führen kann.

Eine Negativrechnung (Typ 380) wird oft dann genutzt, wenn Sie technisch eine „normale Rechnung“ senden wollen, deren Gesamtbetrag negativ ist – zum Beispiel bei Schlussrechnungen nach Vorauszahlungen/Abschlägen oder in Verrechnungslogiken. In diesem Kontext ist also eine Negativrechnung eine ganz normale Rechnung, aber eben mit einem negativen Endergebnis. Die gängige Modellierung ist hier: Netto-Beträge bleiben positiv, aber die Menge wird negativ angegeben, sodass sich der negative Gesamtbetrag rechnerisch ergibt. Das kann funktionieren, ist aber in der Praxis sensibler, weil nicht jedes Portal oder jeder Workflow negative Endbeträge in einer „normalen Rechnung“ gleich gut akzeptiert. Wenn Sie häufig an öffentliche Auftraggeber oder über streng validierende Kanäle schicken, ist diese Variante besonders sorgfältig zu testen.

Wenn Sie hingegen eine konkrete, bereits gestellte Rechnung stornieren oder korrigieren müssen, ist meist die Rechnungskorrektur (Typ 384) der sauberste Weg. Auch hier werden die Beträge in den Positionsfeldern typischerweise positiv geführt; die Korrekturwirkung wird häufig über negative Mengen (oder über die Differenzlogik, je nach Prozess) abgebildet. Der entscheidende Punkt bei 384 ist aber weniger „Vorzeichen-Tricks“, sondern die eindeutige Referenz auf das Original: Die zu korrigierende Rechnung muss im Dokument korrekt referenziert werden (Preceding Invoice Reference / BG-3), damit Empfänger-Systeme die Korrektur automatisiert zuordnen können und nicht „zwei unabhängige Dokumente“ sehen.

Als Merkhilfe für Ihren Arbeitsalltag: 381 verwenden, wenn Sie eine Gutschrift als solche ausstellen (Gutschriftwirkung über den Typcode, nicht über Minus-Beträge). 384 verwenden, wenn Sie eine bestimmte Rechnung stornieren/korrigieren (inkl. Referenz auf das Original). 380 negativ nur dann nutzen, wenn Ihr Prozess bewusst mit negativen Rechnungen arbeitet und Sie sicher sind, dass der Empfängerkanal das akzeptiert. Und noch ein Sprach-Fallstrick: Im deutschen Steuerkontext bedeutet „Gutschrift“ manchmal das Gutschriftsverfahren/Selbstfakturierung – das ist technisch ein eigener Typcode (häufig 389) und etwas anderes als eine „kaufmännische Gutschrift“ im Sinne von 381.

Weiterführende Links / Quellen

• ZUGFeRD-Spezifikation 2.4: „0_FACTUR-X 1.08 2025 12 04 DE.pdf“, 7.1.6 Umgang mit Gutschrift, S. 38f
• ZUGFeRD/Factur-X Spezifikation (GEFEG), Abschnitt zu Invoice type code (BT‑3) und Typcodes (380/381/384):
  https://portal3.gefeg.com/projectdata/invoice/deliverables/installed/publishingproject/zugferd%202.0.1%20-%20facturx%201.03/en%2016931%20%E2%80%93%20facturx%201.03%20%E2%80%93%20zugferd%202.0.1%20-%20comfort.scm/html/de/0213.htm
• FAQ E‑Rechnung Bund: Credits und Rechnungskorrekturen in EN 16931/XRechnung (Praxis- und Interpretationshinweise):
  https://e-rechnung-bund.de/en/faq/how-should-i-indicate-credits-and-invoice-corrections/

Zur Erinnerung: Seit 01.01.2025 wird die E‑Rechnung im inländischen B2B-Umfeld zum neuen Standard (mit Übergangsregelungen), und eine „E‑Rechnung“ ist eben nicht einfach nur ein PDF, sondern ein strukturiertes elektronisches Format (z. B. XRechnung/XML oder ZUGFeRD mit eingebettetem XML), das automatisiert verarbeitet werden kann. Für die Aufbewahrung bedeutet das: Mindestens der strukturierte Teil muss im Original erhalten bleiben. Wenn Sie nur ein hübsches PDF ablegen, aber das XML fehlt oder wird nachträglich verändert, wird es im Zweifel kritisch. Deshalb sollte Ihr Workflow so aufgebaut sein, dass Sie mit RechnungFertig die E-Rechnungen generieren, die Sie danach konsequent ins Archiv überführen.

Eine Archivierungslösung dafür kann ein USB-WORM-Stick (Write Once, Read Many) sein: Er ist darauf ausgelegt, Dateien einmalig zu speichern. Danach sind sie nicht lösch- oder überschreibbar. Das ist für GoBD-relevante Anforderungen wie „Unveränderbarkeit“ ein großer Pluspunkt – und für kleine Betriebe attraktiv, weil keine Cloud nötig ist und keine laufenden Kosten entstehen. Der verlinkte Stick (16 GB) eignet sich für die Archivierung von E-Rechnungen (XRechnung/ZUGFeRD/Factur-X) und funktioniert unter Windows/Linux (aktuell leider nicht unter MacOS). Entscheidend: WORM ist ein starkes technisches Element – ersetzt aber nicht die organisatorischen Pflichten. In der Praxis funktioniert das Setup am besten mit einem festen Mini-Prozess: (1) Rechnung in RechnungFertig erstellen, (2) als E-Rechnung (XRechnung XML oder ZUGFeRD-PDF) speichern/exportieren, (3) vor dem Archivieren kurz validieren, ob die E-Rechnung technisch korrekt ist (damit Sie nicht fehlerhafte Dateien unveränderbar „einbetonieren“), und (4) dann ab auf den WORM-Stick – mit einem klaren Ablageschema. So erreichen Sie „Wiederauffindbarkeit“ auch ohne teures DMS, weil Sie über Ordnerstruktur und Dateinamen schnell suchen können.

Was Sie trotzdem einplanen müssen: GoBD-Konformität ist nicht nur Technik, sondern auch Nachvollziehbarkeit. Sie brauchen eine kurze Verfahrensdokumentation (für Kleinstbetriebe reichen oft wenige Seiten), in der steht: Wer erstellt Rechnungen? Welche Formate sind das „Original“? Wie werden Dateien benannt/abgelegt? Wie stellen Sie Vollständigkeit sicher (Checkliste „Rechnung erstellt → exportiert → validiert → archiviert“)? Und ganz wichtig: Ein WORM-Stick ist kein Backup. Wenn er verloren geht oder defekt ist, ist Ihr Archiv weg. Die pragmatische Lösung ist eine zweite, getrennt verwahrte Archivkopie nach festem Rhythmus (z. B. monatlich) – mit dem Ziel, dass auch diese Kopie die unveränderten Originale enthält und Sie im Notfall ausweichen können.

—

Weiterführende Links / Quellen

• BMF FAQ zur E‑Rechnung (Definition, Aufbewahrung, Übergang): https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html
• USB‑WORM‑Stick (Produktseite): https://erechnungs-validator.de/produkt/e-rechnung-archiv-usb-worm-stick-16gb/
• Hinweis-/Praxisartikel zur revisionssicheren Archivierung von E‑Rechnungen (Anbieter): https://erechnungs-validator.de/e-rechnungen-xrechnung-zugferdarchivieren-rechtssicher-revisionssicher-gesetzeskonform/
• Hintergrund zu XRechnung/ZUGFeRD in der Praxis (Einordnung strukturierter Daten): https://www.dr-weiss.com/eingangsrechnungsbearbeitung/tipps-zur-einfuehrung-xrechnung-und-zugferd-verarbeitung.html

Die für viele praktischste Neuerung: Unterpositionen (Sub‑Line Items) im Profil EXTENDED sind jetzt umsatzsteuerkonform abbildbar. Gerade in Handwerk, Bau, Agenturen, Sets/Bundles oder bei Leistungsaufteilungen war das bisher oft ein Medienbruch: In der PDF hübsch dargestellt, im strukturierten Teil bislang nicht möglich. Mit 2.4 bekommen Positionen/Unterpositionen eine klarere Logik, u. a. mit eindeutiger Kennzeichnung, ob etwas umsatzsteuerlich relevant ist. Das reduziert Interpretationsspielräume beim Empfänger – und damit Rückfragen, manuelles Nachbuchen und potenzielles Steuer-Chaos.

Technisch spannend (und für Software-Anbieter relevant, aber auch für dich als Anwender indirekt spürbar): ZUGFeRD 2.4 basiert jetzt auf UN/CEFACT CII D22B – bleibt dabei aber abwärtskompatibel zu D16B. UN/CEFACT CII D22B ist eine spezifische Version des internationalen Standards Cross Industry Invoice (CII), entwickelt von den Vereinten Nationen (UN/CEFACT), um elektronische Rechnungen branchenübergreifend und strukturiert (im XML-Format) auszutauschen, insbesondere als eine der beiden zulässigen Grammatiken für E-Rechnungen gemäß der europäischen Norm EN 16931. Es handelt sich um eine standardisierte „Sprache“ für den elektronischen Rechnungsverkehr, die maximale Datenintegrität gewährleistet.

Eine weitere Neuerung der neuen ZUGFeRD-Spezifikation ist: Die Validierung wurde neu sortiert. Alle fünf Profile haben jetzt eigene XSD- und Schematron-Artefakte, aktualisiert im Einklang mit EN 16931, und die Validierungsregeln wurden überarbeitet. Profilbezogen wird jetzt also klarer, was „gültig“ ist – gleichzeitig können Rechnungen, die früher „irgendwie durchgerutscht“ sind, plötzlich Fehler werfen.

Außerdem ist die internationale Schiene stärker denn je: Weil ZUGFeRD 2.4 = Factur‑X 1.08 ist und gemeinsam mit Frankreich (FNFE‑MPE) weiterentwickelt wird, wurden im Profil EXTENDED auch Elemente ergänzt, die die Interoperabilität mit der französischen B2B‑E‑Rechnungsverpflichtung unterstützen.

—

Weiterführende Links / Quellen

FeRD / ZUGFeRD Community: Veröffentlichung ZUGFeRD 2.4 / Factur‑X 1.08 (04.12.2025) inkl. Inkrafttreten (15.01.2026) und Neuerungen: https://www.zugferd-community.net/de/blog/2025-12-05-ferd_veroeffentlicht_zugferd_2_4_factur-x_1_08