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

Beim Versenden ist 2026 oft noch ein Übergangsjahr: Viele dürfen im B2B-Umfeld je nach Konstellation weiterhin „sonstige Rechnungen“ (PDF/Papier) nutzen – teils an Bedingungen geknüpft, etwa an die Zustimmung des Empfängers. Aber genau hier lauert der Praxis-Fallstrick: Große Kunden, Konzerne und öffentliche Auftraggeber stellen ihre Prozesse um und akzeptieren zunehmend nur noch strukturierte Rechnungen oder verarbeiten sie bevorzugt. Heißt für dich: Auch wenn du rechtlich vielleicht noch „dürftest“, kann es 2026 schon geschäftlich unklug sein, bei reinen PDF-Rechnungen zu bleiben – weil du sonst im schlimmsten Moment (wenn ein wichtiger Kunde umstellt) hektisch nachrüsten musst.

Technisch sind 2026 vor allem drei Begriffe wichtig: XRechnung, ZUGFeRD 2.x (z. B. 2.2) und „hybride PDFs“. XRechnung ist ein reines XML-Format (basierend auf EN 16931) und besonders im B2G-Bereich Standard, schwappt aber in B2B immer stärker rüber; deine Software sollte mindestens die gängigen aktuellen XRechnung-Versionen sauber unterstützen. ZUGFeRD ist für viele Kleine der pragmatische Einstieg: PDF/A-3 + eingebettete XML-Daten – Menschen können das PDF lesen, Systeme verarbeiten die XML. Wichtig ist dabei: Nicht jedes ZUGFeRD-Profil ist „voll EN-16931“; in der Praxis gelten bestimmte Profile (z. B. MINIMUM/BASIC-WL) als nicht ausreichend für eine „vollwertige“ E-Rechnung. Und: Bei hybriden Formaten zählt steuerlich und technisch zunehmend der strukturierte Teil – das PDF ist eher Anzeige, die XML ist die Wahrheit. Abweichungen zwischen PDF und XML können unnötige Risiken und Rückfragen auslösen.

Was solltest du jetzt (2026) konkret tun – und was kann warten? Jetzt solltest du (1) einen festen Eingangskanal definieren (z. B. rechnung@…), (2) sicherstellen, dass du XRechnung/ZUGFeRD anzeigen und idealerweise validieren kannst (Viewer/Validator oder direkt im Buchhaltungstool), und (3) die Archivierung GoBD-tauglich aufsetzen – inklusive der strukturierten Datei (XML), nicht nur „PDF abheften“. Planen solltest du 2026 außerdem die Umstellung deiner Ausgangsrechnungen auf mindestens ein E-Rechnungsformat (oft ZUGFeRD als Standard + XRechnung für Kunden/Portale, die es verlangen) und deine Stammdaten disziplinieren (Adresse, USt-ID, Leistungsdatum, Steuersätze etc.), weil Validatoren Fehler gnadenlos sichtbar machen. Im Blick behalten solltest Du – je nach Geschäftsmodell – das große EU-Thema ViDA: Die EU-weiten Digital-Reporting-Pflichten für grenzüberschreitende B2B-Umsätze kommen erst später (ab 2030).

Weiterführende Quellen

• BMF – FAQ zur E-Rechnung (Deutschland, Definition/Empfangspflicht/Kleinunternehmer): https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html
• Haufe – Überblick E-Rechnungspflicht und Übergangsregelungen: https://www.haufe.de/steuern/gesetzgebung-politik/elektronische-rechnung-wird-pflicht-erechnung-im-ueberblick_168_605558.html
• EU-Kommission (TAXUD) – ViDA-Paket, Zeitplan/DRR: https://taxation-customs.ec.europa.eu/news/adoption-vat-digital-age-package-2025-03-11_en
• IHK Köln – Hinweise zu BMF-Schreiben/E-Rechnung, Profile/Abweichungen Hybridformate: https://www.ihk.de/koeln/hauptnavigation/recht-steuern/steuern/bmf-schreiben-zur-e-rechnung-vom-15-10-2025-6774012
• IHK (Entwurf/Material zu BMF-Schreiben, Validierung/Umsetzungshinweise): https://www.ihk.de/meo/recht-und-steuern/steuerrecht/downloads/beitraege/entwurf-fuer-ein-2-bmf-schreiben-zur-e-rechnungspflicht-6612416