ZUGFeRD direkt aus Shopware: Was die Standardrechnung kann

Am 1. Januar 2027 endet für viele B2B-Shops die Übergangszeit der E-Rechnung: Wer im Vorjahr mehr als 800.000 Euro Gesamtumsatz hatte, darf Unternehmen im Inland grundsätzlich keine Papier- oder PDF-Rechnungen mehr schicken (§ 27 Abs. 38 Nr. 2 UStG). Die naheliegende Frage lautet dann, ob der Shop dafür eine Erweiterung braucht. Für ZUGFeRD aus Shopware ist die Antwort in vielen Fällen: nein. Seit Version 6.6.10.0 erzeugt die Standardrechnung E-Rechnungen im ZUGFeRD-Format, als eigene XML-Datei oder eingebettet in die gewohnte PDF-Rechnung (Shopware). Dieser Beitrag zeigt, was die Funktion im Detail kann, woher sie ihre Daten nimmt und an welchen Stellen ein Shopware-Shop trotzdem eine Ergänzung braucht.

Was ab dem 1. Januar 2027 für Rechnungsaussteller gilt

Seit dem 1. Januar 2025 muss jedes inländische Unternehmen den Empfang von E-Rechnungen sicherstellen; dafür reicht bereits ein E-Mail-Postfach (BMF). Beim Ausstellen gilt dagegen eine gestaffelte Übergangszeit. In den Jahren 2025 und 2026 können sich alle Rechnungsaussteller noch für eine sonstige Rechnung entscheiden, also für Papier oder, mit Zustimmung des Empfängers, etwa ein PDF per E-Mail (BMF).

Ab 2027 trennt eine Umsatzgrenze die Shops. Nur wer im vorangegangenen Kalenderjahr einen Gesamtumsatz von höchstens 800.000 Euro hatte, darf Papier oder ein anderes elektronisches Format bis zum 31. Dezember 2027 weiter nutzen (§ 27 Abs. 38 Nr. 2 UStG). Für Rechnungen per elektronischem Datenaustausch (EDI) gilt eine eigene Frist bis Ende 2027 (§ 27 Abs. 38 Nr. 3 UStG). Erst nach Ablauf dieser Übergangsfristen ist die E-Rechnung zwischen inländischen Unternehmen tatsächlich verpflichtend (BMF), mit Ausnahmen etwa für Kleinbetragsrechnungen und Kleinunternehmer (BMF). Die übrigen Termine des Jahres im Zusammenhang zeigt unser Fristenkalender 2027 für Onlineshops.

Für den reinen Endkundenshop ändert sich wenig, denn die Regeln zur verpflichtenden E-Rechnung gelten nur, wenn überhaupt eine umsatzsteuerliche Pflicht zur Rechnung besteht, und Rechnungen an Endverbraucher gehören nicht dazu (BMF). Betroffen ist jeder Shop, der auch an Unternehmen im Inland verkauft, etwa über Firmenkundenkonten, Rechnungskauf oder Angebotsanfragen im B2B-E-Commerce. In genau diesen Shops entsteht die Rechnung häufig direkt im Shop, und damit wird die Frage nach der Standardfunktion konkret.

Was als E-Rechnung zählt und warum ZUGFeRD dazugehört

Das Umsatzsteuergesetz bestimmt die E-Rechnung über ihre Form: Sie wird in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen und ermöglicht eine elektronische Verarbeitung (§ 14 Abs. 1 UStG). Das Format muss der europäischen Norm für die elektronische Rechnungsstellung entsprechen, also der EN 16931, oder zwischen den Beteiligten vereinbart sein und die vollständige Extraktion der Pflichtangaben erlauben (§ 14 Abs. 1 UStG). Ein einfaches PDF erfüllt das nicht, weil es kein strukturiertes Format hat (BMF).

Nach Auffassung der Finanzverwaltung erfüllen insbesondere XRechnung und ZUGFeRD ab Version 2.0.1 die umsatzsteuerlichen Voraussetzungen, mit Ausnahme der Profile MINIMUM und BASIC-WL (BMF). ZUGFeRD ist ein hybrides Format: Ein PDF, das ein Mensch lesen kann, trägt eine XML-Datei mit den strukturierten Rechnungsdaten in sich. Mit der verpflichtenden E-Rechnung hat sich dabei die Rangfolge der beiden Teile umgekehrt.

Unterscheidet sich der strukturierte Rechnungsteil vom Bildteil, sind nunmehr die Daten des strukturierten Teils maßgebend.

Bundesministerium der Finanzen, Fragen und Antworten zur Einführung der obligatorischen E-Rechnung, Frage 12a

Für die Praxis heißt das: Weichen XML und PDF-Ansicht voneinander ab, gelten die Daten der XML (BMF). Ein Zahlungsziel, das nur auf dem PDF steht, oder eine Adresse, die nur im Druckbild korrigiert wurde, zählt nicht. Genau deshalb lohnt der Blick darauf, woher Shopware die Inhalte der XML bezieht. Wie ZUGFeRD und XRechnung zueinander stehen und welches Profil wofür passt, beschreibt unser Beitrag zur E-Rechnungspflicht für Online-Shops.

Seit wann Shopware ZUGFeRD im Standard erzeugt

Seit Version 6.6.10.0 erstellt Shopware E-Rechnungen im ZUGFeRD-Format, konform zur EN 16931 (Shopware). Die Rechnungsdaten werden entweder in die bekannte PDF-Rechnung eingebettet oder als separate XML-Datei bereitgestellt (Shopware). Mit Version 6.7.9.0 kamen weitere Dokumente im ZUGFeRD-Format hinzu (Shopware): Gutschrift und Stornorechnung, jeweils ebenfalls als XML oder eingebettet. Zusammen sind das sechs Varianten, die im Dialog zum Erstellen eines Dokuments zur Auswahl stehen.

Die Bezeichnungen in der Tabelle sind die Dokumenttypen, die Shopware per Migration in der Datenbank anlegt (Shopware-Quelltext). Die Linie 6.5 enthält dagegen keine ZUGFeRD-Erzeugung; im letzten Stand 6.5.8.19 findet sich kein entsprechender Code (Shopware-Quelltext). Wer noch auf 6.5 arbeitet, hat damit einen zweiten Grund für das Update. Warum dort auch die Sicherheitsupdates auslaufen, steht in unserem Beitrag zu Shopware 6.5 und dem Ende der Sicherheitsupdates.

Was in der XML steht: CII, EN 16931 und das XRechnung-Profil

Shopware nutzt für ZUGFeRD-Dokumente den Standard CII (Cross Industry Invoice), der im ZUGFeRD-Format integriert ist (Shopware). Im Quelltext legt der Baustein für die XML auch das Profil fest: Er erzeugt jedes Dokument mit dem Profil XRechnung 3 der eingebundenen ZUGFeRD-Bibliothek (Shopware-Quelltext). Die überarbeitete Dokumentenerzeugung, die im Kern bereits hinter einem Funktionsschalter liegt, schreibt als Kennung ausdrücklich XRechnung 3.0 in den Dokumentkontext (Shopware-Quelltext).

Das hat zwei praktische Folgen. Erstens richtet sich die XML nach den Regeln der XRechnung, die die EU-Norm um 21 nationale Geschäftsregeln ergänzt (E-Rechnung Bund). Zweitens genügt die Syntax CII: Rechnungssteller können sich eine der erlaubten Syntaxen aussuchen, nur Rechnungsempfänger der öffentlichen Verwaltung müssen beide annehmen (KoSIT). Dass Shopware keine XML in der zweiten Syntax UBL erzeugt, ist für die Rechtslage deshalb kein Mangel.

<rsm:CrossIndustryInvoice>
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>[Rechnungsnummer aus dem Nummernkreis]</ram:ID>
    <ram:TypeCode>[Belegart: Rechnung, Gutschrift oder Korrektur]</ram:TypeCode>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:ApplicableHeaderTradeAgreement>
      <ram:BuyerReference>[Bestellnummer des Shops]</ram:BuyerReference>
      <ram:SellerTradeParty>[Geschäftseinstellungen]</ram:SellerTradeParty>
      <ram:BuyerTradeParty>[Kunde und Rechnungsadresse]</ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:SpecifiedTradeSettlementPaymentMeans>[nur bei Rechnung, Vorkasse, Bargeld]</ram:SpecifiedTradeSettlementPaymentMeans>
      <ram:SpecifiedTradePaymentTerms>[Fälligkeit der Zahlung]</ram:SpecifiedTradePaymentTerms>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Vor der Ausgabe prüft Shopware das zusammengesetzte Dokument mit einem Validator. Findet er Verstöße, bricht die Erzeugung mit einer Fehlermeldung ab, statt eine fehlerhafte Datei abzulegen (Shopware-Quelltext). Für die Entwicklung des Kerns gibt es zusätzlich eine Prüfung, die erzeugte Musterdokumente mit dem Validator der KoSIT gegen die Geschäftsregeln der EN 16931 abgleicht (Shopware-Quelltext). Die Finanzverwaltung empfiehlt eine Validierung bereits bei Erstellung und Versand, auch wenn sie keine Voraussetzung für die steuerliche Anerkennung ist (BMF). Für den eigenen Shop heißt das: Eine Testrechnung je Zahlungsart durch einen Validator zu schicken, gehört vor den Echtbetrieb.

Die Datenbasis: Geschäftseinstellungen und Bestelldaten

Die Inhalte der ZUGFeRD-Dokumente pflegt der Shop nicht in einem eigenen Bereich. Grundlage sind die Einstellungen des jeweiligen Standarddokuments unter Einstellungen > Handel > Dokumente; die dort hinterlegten Geschäftseinstellungen übernimmt Shopware für die Erstellung der ZUGFeRD-Dokumente (Shopware). Im Quelltext lässt sich nachvollziehen, welche Angaben in die XML wandern (Shopware-Quelltext):

• Verkäufer: Geschäftsname, Straße, Postleitzahl, Stadt und Land aus den Geschäftseinstellungen
• Steuerangaben: Geschäfts-Steuernummer und Geschäfts-USt-ID, beide als Steuerregistrierung des Verkäufers
• Kontakt: Geschäfts-E-Mail-Adresse, Geschäfts-Telefon und der Eintrag unter Geschäftsführer als Ansprechperson
• Bankverbindung: IBAN und BIC, allerdings nur bei den Zahlungsarten Rechnung und Vorkasse
• Käufer: Vor- und Nachname, Firmenname, Kundennummer, E-Mail-Adresse und Rechnungsadresse aus der Bestellung
• Käuferreferenz: die Bestellnummer des Shops

Zwei Punkte verdienen besondere Aufmerksamkeit. Der erste ist die Fälligkeit. Shopware setzt das Zahlungsziel der XML aus dem Feld „Fälligkeit der Zahlung“; ist es leer, rechnet der Code mit 30 Tagen ab Erstellung (Shopware-Quelltext). Der Wert erscheint ausschließlich in der XML und nicht auf der Rechnung selbst, und er braucht ein vorangestelltes Pluszeichen (Shopware), also etwa „+14 days“ statt „14 days“. Weil bei hybriden Rechnungen die XML maßgebend ist (BMF), sollte das Feld zu den Zahlungsbedingungen passen, die im PDF-Text stehen. Sonst trägt die Rechnung zwei verschiedene Zahlungsziele, und das rechtlich maßgebende ist das unsichtbare.

Der zweite Punkt ist die Bankverbindung. IBAN und BIC schreibt Shopware nur bei Rechnungskauf und Vorkasse in die XML, bei Barzahlung einen Hinweis auf Bargeld; bei allen anderen Zahlungsarten bleibt die Zahlungsangabe leer (Shopware-Quelltext). Für bereits bezahlte Bestellungen vermerkt die XML den gezahlten Betrag (Shopware-Quelltext). Wie sich der Rechnungskauf im Firmenkundengeschäft absichern lässt, beschreibt unser Beitrag zu Kreditlimits beim Kauf auf Rechnung; was die einzelnen Zahlarten den Shop kosten, rechnet der Beitrag Zahlarten kalkulieren vor.

• Geschäftsname und vollständige Anschrift sind gepflegt, einschließlich Land
• Steuernummer und USt-ID stehen in den Geschäftseinstellungen
• Die Geschäfts-E-Mail-Adresse führt in ein Postfach, das Rückfragen zu Rechnungen bearbeitet
• IBAN und BIC sind hinterlegt, sobald der Shop Rechnungskauf oder Vorkasse anbietet
• Die Fälligkeit der Zahlung entspricht dem Zahlungsziel im PDF und beginnt mit dem Pluszeichen
• Firmenkunden geben bei der Registrierung den Firmennamen an, damit er in der Käuferangabe erscheint; wie sich das prüfen lässt, zeigt unser Beitrag zur Gewerbeprüfung bei der Registrierung

Automatisch erzeugen: der Flow zur Dokumentenerstellung

Von Hand entsteht ein ZUGFeRD-Dokument in der Bestellung: Im Dialog zum Erstellen eines Dokuments blendet der Schalter „ZUGFeRD-Varianten anzeigen“ die verfügbaren Varianten ein, danach wählt man die gewünschte aus (Shopware). Varianten mit dem Zusatz „eingebettet“ enthalten die XML im PDF, die übrigen liefern sie als eigene Datei (Shopware). Für den laufenden Betrieb ist ein Handgriff je Bestellung allerdings keine Lösung.

Shopware erlaubt deshalb, die ZUGFeRD-Dokumente in den Flow zur Dokumentenerstellung aufzunehmen, sodass sie automatisch entstehen, sobald eine Bestellung einen bestimmten Status erreicht (Shopware). Gutschriften und Stornorechnungen setzen eine zuvor erstellte Rechnung voraus, weil sie auf diese verweisen (Shopware). In der XML der Stornorechnung steht der Verweis auf Nummer und Datum der ursprünglichen Rechnung, als Belegart setzt Shopware dort die Rechnungskorrektur (Shopware-Quelltext). Wie sich Storno, Gutschrift und Korrektur fachlich unterscheiden, erklärt unser Beitrag zu ZUGFeRD-Stornorechnungen und -Gutschriften.

1. Auslöser wählen: einen Flow für den passenden Zeitpunkt anlegen oder öffnen, etwa einen Wechsel des Bestell- oder Zahlungsstatus
2. Variante festlegen: in der Aktion zur Dokumentenerstellung die ZUGFeRD-Variante ergänzen, für Firmenkunden in der Regel die eingebettete Rechnung
3. Kreis begrenzen: über eine Bedingung festlegen, dass der Ablauf nur für Firmenkunden greift, etwa über die Kundengruppe
4. Versand verbinden: die Mail-Aktion des Flows mit dem erzeugten Dokument als Anhang ausstatten
5. Testen: je Zahlungsart eine Testbestellung durchlaufen lassen und prüfen, ob XML und PDF dieselben Beträge, Fälligkeiten und Adressen tragen

Wie Auslöser, Bedingungen und Aktionen grundsätzlich zusammenspielen, erklärt unser Beitrag zum Shopware Flow Builder. Für die E-Rechnung genügt in der Regel ein einziger zusätzlicher Flow oder eine Erweiterung des vorhandenen Rechnungsflows.

Wo der Standard aufhört

Für Rechnungen, die der Shop selbst an Unternehmen im Inland stellt, deckt der Standard in der Regel ab, was das Umsatzsteuerrecht verlangt. Vier Konstellationen gehen darüber hinaus. Die Übersicht zeigt, wo der Standard reicht und wo eine Ergänzung ansetzt.

Rechnungen an Bundesbehörden mit Leitweg-ID

Wer an die Bundesverwaltung liefert, muss neben den umsatzsteuerlichen Pflichtangaben unter anderem eine Leitweg-Identifikationsnummer, die Bankverbindungsdaten, die Zahlungsbedingungen und eine E-Mail-Adresse angeben (§ 5 ERechV). Die Leitweg-ID gehört im Standard XRechnung in das Feld Käuferreferenz (BT-10) und ist dort Pflicht (E-Rechnung Bund). Shopware schreibt in genau dieses Feld die Bestellnummer des Shops (Shopware-Quelltext). Für Rechnungen an Unternehmen ist das zulässig, denn dort können Empfänger ihren Lieferanten für das Feld einen Bezeichner ihrer Wahl mitgeben (KoSIT). An eine Bundesbehörde lässt sich die Rechnung ohne Leitweg-ID dagegen nicht zustellen; formal fehlerhafte Rechnungen lehnt die Plattform automatisiert ab (§ 4 ERechV).

Dazu kommen zwei Feinheiten. Die Bankverbindung landet bei Shopware nur bei Rechnungskauf und Vorkasse in der XML (Shopware-Quelltext). Und das Profil XRECHNUNG von ZUGFeRD nimmt der Bund nur als rein strukturierte XML-Datei ohne Sichtformat an (E-Rechnung Bund), also in der Variante „ZUGFeRD Rechnung“ ohne PDF. Übermittelt wird über die Rechnungseingangsplattform, unter anderem per Upload, E-Mail oder Peppol (E-Rechnung Bund); vorher ist eine Registrierung mit Nutzerkonto nötig (§ 4 ERechV). Leitweg-IDs vergeben Bund und Länder jeweils selbst (KoSIT), für Länder und Kommunen gelten deren eigene Vorgaben.

Versand über Peppol

Peppol unterstützt Shopware nicht nativ, und es gibt nach Angaben des Herstellers keine Zusage für eine native Unterstützung (Shopware). Die Begründung in der Dokumentation ist sachlich: Peppol ist ein Netzwerk, kein Format, und Deutschland schreibt Formate wie XRechnung und ZUGFeRD vor, jedoch kein Netzwerk (Shopware). Das deckt sich mit der Finanzverwaltung, nach der das Gesetz keinen bestimmten Übermittlungsweg vorsieht; auch der Versand per E-Mail kommt in Betracht (BMF). Peppol wird zum Thema, wenn Kunden im Ausland darüber empfangen wollen oder das ERP ohnehin an einen Zugangspunkt angebunden ist. Den Aufbau des Netzwerks beschreibt unser Beitrag zu Peppol für B2B-Shops.

Rechnungen aus dem ERP

Im B2B-Geschäft entsteht die Rechnung oft nicht im Shop. Nach der Herstellerdokumentation wird sie üblicherweise vom ERP- oder Finanzsystem ausgestellt (Shopware). In diesem Fall ist die ZUGFeRD-Funktion des Shops nicht der richtige Ort, denn zwei Systeme mit eigener Rechnungsnummernvergabe würden sich in die Quere kommen. Die E-Rechnung gehört dann ins maßgebliche System, der Shop übergibt die Bestelldaten. Das ist ein Schnittstellenthema, etwa bei SAP Business One oder der Übergabe an DATEV.

Steuerfreie Lieferungen ins EU-Ausland

Für Positionen mit einem Steuersatz von 0 Prozent setzt der Code die Steuerkategorie für Waren zum Nullsatz (Shopware-Quelltext). Die zugrunde liegende Codeliste kennt für steuerfreie innergemeinschaftliche Lieferungen eine eigene Kategorie, ebenso für die Steuerschuldnerschaft des Leistungsempfängers (ZUGFeRD-Bibliothek). Die USt-ID des Käufers schreibt der Standard nicht in die XML (Shopware-Quelltext). Die Pflicht zur E-Rechnung betrifft zwar nur Leistungen zwischen Unternehmen im Inland (§ 14 Abs. 2 UStG). Wer dennoch ZUGFeRD an Kunden im EU-Ausland schickt, sollte diese Fälle gezielt prüfen.

Eigenentwicklung: wo Shopware Anpassungen vorsieht

Für diese Lücken muss niemand den Kern umschreiben. Shopware löst während der Erzeugung Ereignisse aus, an denen eine Erweiterung ansetzen kann: eines je Rechnungsposition und eines, nachdem das Dokument zusammengesetzt ist und bevor es geprüft und ausgegeben wird (Shopware-Quelltext). An dieser Stelle lässt sich zum Beispiel die Käuferreferenz durch eine Leitweg-ID ersetzen, die der Kunde beim Bestellen angegeben hat.

<?php declare(strict_types=1);

namespace Beispiel\LeitwegId;

use Shopware\Core\Checkout\Document\Zugferd\ZugferdInvoiceGeneratedEvent;
use Symfony\Component\EventDispatcher\Attribute\AsEventListener;

// Skizze: Leitweg-ID aus einem Zusatzfeld der Bestellung in die Käuferreferenz (BT-10) schreiben
final class BuyerReferenceListener
{
    #[AsEventListener]
    public function __invoke(ZugferdInvoiceGeneratedEvent $event): void
    {
        $leitwegId = $event->order->getCustomFields()['beispiel_leitweg_id'] ?? null;

        if (\is_string($leitwegId) && $leitwegId !== '') {
            $event->document->getBuilder()->setDocumentBuyerReference($leitwegId);
        }
    }
}

Die Skizze liest die Leitweg-ID aus einem Zusatzfeld der Bestellung und setzt sie nur, wenn sie vorhanden ist; Bestellungen ohne Leitweg-ID behalten die Bestellnummer. Auf demselben Weg lassen sich weitere Angaben ergänzen, etwa die USt-ID des Käufers. Wie das Zusatzfeld in den Checkout kommt und wer es befüllt, gehört in dieselbe Planung, denn die Leitweg-ID teilt der Auftraggeber bei der Auftragserteilung mit (E-Rechnung Bund).

Aufbewahren und im Alltag kontrollieren

Rechnungen sind acht Jahre aufzubewahren (§ 14b UStG). Bei einer E-Rechnung muss zumindest der strukturierte Teil unversehrt in seiner ursprünglichen Form vorliegen (BMF). Bei der eingebetteten Variante steckt die XML im PDF, bei der Variante als eigene Datei gehört die XML selbst ins Archiv. Shopware erzeugt die Belege im Dokumente-Bereich der jeweiligen Bestellung (Shopware); ob das als Archiv genügt, hängt vom eigenen Aufbewahrungsverfahren ab. In vielen Shops übernimmt das die Buchhaltung, wenn die Belege über die DATEV-Schnittstelle weiterlaufen.

Für Stichproben im Alltag hilft eine lesbare Ansicht der XML. Über das ELSTER-Portal stellt die Finanzverwaltung einen Viewer bereit, der Rechnungen im Format XRechnung oder ZUGFeRD lesbar darstellt (BMF). Sinnvoll ist eine kurze Prüfroutine nach jedem Update des Shops: eine Testbestellung je Zahlungsart, das erzeugte Dokument öffnen, Beträge, Steuersätze, Fälligkeit und Adressen mit dem PDF vergleichen.

Die Umstellung bis zum Jahreswechsel

Bis zum Jahreswechsel lässt sich die Umstellung in dieser Reihenfolge planen:

1. Version prüfen: Läuft der Shop auf 6.6.10.0 oder neuer? Gutschrift und Storno als ZUGFeRD gibt es ab 6.7.9.0 (Shopware).
2. Umsatzgrenze klären: Lag der Gesamtumsatz 2026 über 800.000 Euro, ist beim Ausstellen ab dem 1. Januar 2027 die E-Rechnung zu verwenden (§ 27 Abs. 38 UStG). Die Einordnung im Einzelfall übernimmt Ihre Steuerberatung.
3. Datenbasis pflegen: Geschäftseinstellungen vervollständigen und die Fälligkeit an das Zahlungsziel im PDF angleichen.
4. Ablauf automatisieren: ZUGFeRD-Varianten in den Flow zur Dokumentenerstellung aufnehmen und auf Firmenkunden begrenzen.
5. Testen und informieren: Testrechnungen validieren, Firmenkunden über das neue Format informieren und Sonderfälle wie Behörden oder Peppol gesondert planen.

So begleiten wir die Umstellung

Wir prüfen Version, Geschäftseinstellungen und Flows Ihres Shops, erzeugen Testdokumente je Zahlungsart und validieren die XML gegen die Regeln der EN 16931. Wo der Standard nicht reicht, entwickeln wir die Ergänzung individuell, etwa die Leitweg-ID für Behördenkunden oder die Übergabe an das ERP. Mehr zu unserem Vorgehen steht auf der Seite ZUGFeRD und XRechnung; Updates und Prüfungen nach jedem Versionssprung übernimmt unsere Shopware-Wartung.