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.

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/