Überprüft im Juni 2026. Die Termine für E-Rechnungspflichten sind zeitkritisch und mehrere wurden bereits verschoben — die folgenden Daten sind als Orientierung zu verstehen, nicht als unumstößliche Wahrheit. Prüfen Sie das aktuelle Datum, Format und die jeweilige Schwelle für jeden Ihrer Märkte mit Ihrem Steuerberater oder der zuständigen nationalen Steuerbehörde, bevor Sie danach handeln. Dies ist praktische Orientierung, keine Rechts- oder Steuerberatung.

Hier liegt der Punkt, den die meisten PrestaShop-Händler falsch einschätzen: Eine PDF-Rechnung per E-Mail zu versenden ist keine E-Rechnung. Ein PDF — selbst ein sauber gestaltetes, umsatzsteuerlich korrektes direkt aus Ihrem Backoffice — ist ein Bild einer Rechnung, das ein Mensch liest. Eine echte elektronische Rechnung ist eine strukturierte Datendatei (meist XML), die von einer Maschine gelesen, validiert und direkt in eine Buchhaltungssoftware gebucht wird, übermittelt über einen staatlich zugelassenen Kanal. Beides ist nicht austauschbar, und in ganz Europa verfestigt sich die rechtliche Definition rund um die zweite Variante. Italien setzt sie bereits durch. Frankreich, Deutschland, Polen und Spanien haben feste Termine im Kalender. Wenn Sie B2B in einen dieser Märkte verkaufen, ist das eine Frist zur Einhaltung gesetzlicher Vorgaben — kein Vielleicht-irgendwann-Thema.

Dieser Leitfaden beantwortet eine konkrete Frage: Welche europäischen Länder verlangen E-Rechnungen, ab wann, in welchem Format — und was Ihr PrestaShop-Shop tun muss, um vorbereitet zu sein. Es geht nicht um das Layout Ihrer PDF-Rechnung (das behandelt die Rechnungsanpassung in PrestaShop) und auch nicht um Umsatzsteuersätze und OSS/IOSS (das behandelt Umsatzsteuer in der EU). Es geht um genau das, was E-Rechnungen tatsächlich von Ihnen verlangen: saubere, vollständige, strukturierte Rechnungsdaten — und einen Weg, sie durch den richtigen Kanal zu schicken.

Digitale Rechnung vs. E-Rechnung — der Unterschied, der alles entscheidet

Wenn Sie diesen Unterschied falsch verstehen, ist jede weitere Entscheidung falsch. Die folgende Tabelle zeigt die gesamte Frage der rechtskonformen Umsetzung im Kleinen.

Digitale Rechnung (PDF)Elektronische Rechnung (E-Rechnung)
FormatPDF — für Menschen gestaltetStrukturiertes XML (oder hybrides PDF+XML) nach einem definierten Standard (EN 16931)
Gelesen vonEiner PersonEiner Maschine — automatisch validiert und gebucht
ZustellungE-Mail-AnhangStaatliche Plattform oder zertifiziertes Netzwerk (SDI, KSeF, PDP…)
Eine konforme strukturierte E-Rechnung?Nein — ein PDF kann im allgemeinen umsatzsteuerlichen Sinn eine elektronische Rechnung sein, ist aber keine konforme strukturierte E-Rechnung für EN-16931-/Clearance-VerfahrenJa

Was bedeutet das also für Ihren Shop? PrestaShop erzeugt standardmäßig die linke Spalte. Jede Bestellung generiert ein PDF über den AdminPdfController und die Klasse HTMLTemplateInvoice (classes/pdf/HTMLTemplateInvoice.php), gerendert aus der Vorlage in pdf/invoice.tpl. Dieses PDF ist eine völlig brauchbare digitale Rechnung — in Ländern mit E-Rechnungspflicht ist es für sich allein aber keine konforme elektronische Rechnung. Diese Lücke zu schließen ist die eigentliche Aufgabe, und fast die gesamte Arbeit besteht darin, sicherzustellen, dass die Daten in der Rechnung vollständig und korrekt sind, denn das strukturierte Format verzeiht fehlende Felder nicht.

Land für Land: Wer sie verlangt, wann und in welchem Format

Termine und Schwellenwerte bewegen sich in diesem Bereich — mehrere wurden bereits einmal verschoben — behandeln Sie die Zeitleiste daher als Orientierung und bestätigen Sie das genaue Datum und Format für Ihre Märkte mit Ihrem Steuerberater oder der nationalen Steuerbehörde, bevor Sie handeln. Was nicht zweifelhaft ist: Jede große EU-Volkswirtschaft steuert auf verpflichtende strukturierte E-Rechnungen zu.

LandStatus / wichtige TermineFormatÜbertragungskanal
ItalienSeit 2019 verpflichtend (B2B, B2C und B2G); 2024 auf Pauschal-/Kleinsteuerpflichtige ausgeweitetFatturaPA (XML)SDI (Sistema di Interscambio)
FrankreichStufenweise: zuerst Empfangsfähigkeit und Ausstellung durch Großunternehmen, danach Ausstellungspflicht für alle Unternehmen (derzeit etwa 2026–2027 anvisiert — bestätigen Sie dies, da französische Termine bereits einmal verschoben wurden)Factur-X (hybrides PDF/XML), UBL, CIIPDP — Plateforme de Dématérialisation Partenaire (zertifizierte Plattformen)
DeutschlandB2B-Empfang ab Januar 2025 verpflichtend; die Ausstellungspflicht wird nach Umsatz bis etwa 2027–2028 stufenweise eingeführtXRechnung (XML) und ZUGFeRD (hybrid)Dezentral — direkter Austausch oder über Dienstleister
PolenKSeF für B2B verpflichtend, stufenweise Einführung — große Steuerpflichtige ab Februar 2026, alle übrigen ab April 2026 (diese Termine wurden bereits verschoben; prüfen Sie den aktuellen Zeitplan)Strukturiertes XML (FA_VAT-Schema)KSeF (Krajowy System e-Faktur)
SpanienB2B-Pflicht nach "Crea y Crece", stufenweise nach Unternehmensgröße — Durchführungsregeln zum Zeitpunkt der Überprüfung noch ausstehendFacturae ist für B2G etabliert; die B2B-Pflicht wartet noch auf Durchführungsregeln und kann Facturae-kompatible strukturierte Formate mit Plattform-Interoperabilität umfassen — prüfen Sie die aktuellen spanischen Regeln vor der UmsetzungÖffentliche + private Plattformen
BelgienB2B-Pflicht für 2026 geplantPeppol BIS (EN 16931)Peppol-Netzwerk
RumänienRO e-Factura für B2B und B2G verpflichtendStrukturiertes XML (EN 16931)RO e-Factura-Plattform

Zwei Muster aus dieser Tabelle sind besonders wichtig. Erstens ist fast jedes neue Format eine Variante von EN 16931 — dem gemeinsamen semantischen Standard der EU — sodass Investitionen in saubere, vollständige Daten über Grenzen hinweg tragen, auch wenn sich die Dateihüllen unterscheiden. Zweitens kommt in den meisten Einführungen der Empfang vor der Ausstellung: Die erste Frist, die Sie trifft, ist häufig die Pflicht, strukturierte Rechnungen von Ihren Lieferanten zu empfangen. Das ist ein Thema für Einkauf und Buchhaltung, nicht etwas, das Ihre Shopoberfläche erzeugt.

Die EU-weite Richtung: ViDA

Keines dieser nationalen Systeme ist ein Einzelfall. Sie sind der Vorlauf zu VAT in the Digital Age (ViDA), der EU-Initiative zur Standardisierung der E-Rechnung und zur Einführung nahezu echtzeitnaher digitaler Meldungen für innergemeinschaftliche Transaktionen. Die Anforderungen an strukturierte Rechnungen zielen auf die zweite Hälfte dieses Jahrzehnts. Praktisch gelesen für Shopbetreiber: Das nationale Format, das Sie jetzt umsetzen, ist ein Zwischenschritt, keine Sackgasse, weil alle auf denselben EN-16931-Kern zulaufen. Ihre Rechnungsdaten korrekt zu bekommen ist die langfristige Investition; die Übertragungshülle ist der Teil, den Sie höchstwahrscheinlich auslagern.

Was Ihr PrestaShop-Shop dafür tatsächlich leisten muss

PrestaShop-Dashboard zur Nummerierung von Rechnungen und Gutschriften mit Audit-Zählern
Konforme elektronische Rechnungsstellung beginnt mit einer sauberen, fortlaufenden Belegnummerierung über Rechnungen und Gutschriften hinweg.

Wenn man die Abkürzungen beiseitelässt, verlangt die E-Rechnung drei konkrete Dinge von Ihnen. Nur das erste ist wirklich Aufgabe Ihres Shops — und genau dort passieren die meisten Fehler.

1. Qualität der Rechnungsdaten (das sind 90% der Arbeit)

Systeme für strukturierte E-Rechnungen weisen Rechnungen mit fehlenden oder falsch formatierten Feldern direkt ab — am anderen Ende sitzt kein Mensch, der mit den Schultern zuckt und es korrigiert. Eine FatturaPA-Datei ohne USt-IdNr. des Käufers wird nicht nachgefragt; sie prallt ab. Die grundlegende Aufgabe besteht also darin, sicherzustellen, dass jede PrestaShop-Rechnung den vollständigen EN-16931-Feldsatz enthält:

  • Umsatzsteuer-/Steuerkennzeichen von Verkäufer und Käufer — und im B2B muss die Kennung des Käufers vorhanden und gültig sein. PrestaShop speichert diese Daten in der Adresse (vat_number, plus company und siret/dni, wo zutreffend), aber sie werden nur ausgefüllt, wenn Ihre Kasse danach fragt und Sie sie validieren.
  • Vollständige strukturierte Adressen — Straße, Postleitzahl, Ort, Ländercode, jeweils in einem eigenen Feld (das XML erwartet sie getrennt, nicht als einen freien Textblock).
  • Steueraufschlüsselung pro Position und pro Steuersatz — die gesamte Umsatzsteuer muss zu den Zwischensummen je Steuersatz passen, und genau dort rächt sich eine lockere Steuerkonfiguration. Wenn Ihre Sätze und Regeln nicht sauber sind, wird die strukturierte Datei nicht validiert; Steuerkonfiguration in PrestaShop behandelt, wie Sie das an der Quelle richtig einrichten.
  • Eine eindeutige fortlaufende Rechnungsnummer — mit erklärten Lücken, wo lokales Recht oder Buchhaltungspraxis dies verlangt. Viele Steuersysteme verlangen eindeutige fortlaufende Nummern, aber ob eine Sequenz strikt lückenlos sein muss, hängt vom Land und den Buchhaltungsregeln ab; XML-Validierungssysteme weisen eine Rechnung in der Regel nicht allein deshalb ab, weil eine andere Nummer fehlt. Der Standardzähler von PrestaShop ist pro Shop geführt und wird auf Arten zurückgesetzt oder verzweigt, die viele überraschen; die ausführlichere Behandlung finden Sie in Anpassung von Rechnungs- und Bestellnummern.
  • Klare Produktbeschreibungen, Codes und Zahlungsbedingungen — generische Positionstexte und fehlende Zahlungs- oder Bankdaten sind häufige Ablehnungsgründe.

Was heißt das konkret? Wenn Ihre Rechnungen die USt-IdNr. des Käufers bereits erfassen und validieren, saubere Steueraufschlüsselungen je Steuersatz enthalten und fortlaufend nummerieren, sind Sie größtenteils bereit für E-Rechnungen — unabhängig davon, an welchen nationalen Kanal Sie sich am Ende anschließen. Denn jeder dieser Kanäle will dieselben zugrunde liegenden Daten. Genau hier leisten die richtigen Module ihren Beitrag: Financial Revolution erstellt Rechnungen mit dem vollständigen Feldsatz, den die europäischen Vorgaben erwarten, Invoice Number erzwingt die strenge fortlaufende Nummerierung, die diese Systeme verlangen, und Automatic EU VAT Checker validiert die USt-IdNr. des Käufers an der Kasse gegen VIES, damit eine falsche Nummer gar nicht erst auf einer Rechnung landet, die gleich maschinell abgelehnt würde. Der Nutzen ist nicht abstrakte "Rechtskonformität" — sondern dass Ihre Rechnungsdaten sauber sind, bevor eine Frist Druck macht, nicht danach.

2. Formatkonvertierung (XML-Erzeugung)

Ihre sauberen PrestaShop-Daten müssen trotzdem zu einer FatturaPA-, XRechnung-, Factur-X- oder KSeF-XML-Datei werden. Es gibt zwei realistische Wege dorthin, und für die meisten Händler ist der zweite der richtige:

Länderspezifisches PrestaShop-ModulExterner E-Rechnungsanbieter
Was es tutErzeugt das nationale XML innerhalb von PrestaShopÜbernimmt Ihre Rechnungsdaten und erstellt + übermittelt die Datei für Sie
Am besten, wennEin oder zwei Märkte, planbares VolumenMehrere Länder oder Sie die Pflege der Formate nicht selbst tragen möchten
KompromissSie sind für Updates verantwortlich, wenn sich jedes Schema ändertGebühr pro Rechnung, aber der Anbieter verfolgt die Schemaänderungen

3. Übertragung

Die Datei muss anschließend über den zugelassenen Kanal laufen — Italiens SDI, Polens KSeF, Frankreichs PDP-Netzwerk, das Peppol-Netzwerk für Belgien und andere. Eine direkte Integration mit diesen Systemen ist tatsächlich komplex und zertifikatslastig. Deshalb ist es bei kleinen und mittleren Händlern der mit Abstand häufigste Ansatz, die Übertragung einem Vermittler zu überlassen (oft demselben Anbieter, der auch die Formatkonvertierung übernimmt), gegen eine Gebühr pro Rechnung. Die Verantwortung Ihres Shops endet bei der Bereitstellung korrekter Daten; die des Anbieters ist, sie durch den Kanal zu bringen und mit einer Empfangsbestätigung zurückzuliefern.

B2C: größtenteils noch nicht, aber verlassen Sie sich nicht darauf, dass es so bleibt

Heute betreffen die Pflichten überwiegend B2B (und B2G). Die meisten B2C-Rechnungen sind ausgenommen oder vereinfacht — mit Italien als wichtiger Ausnahme, wo die Pflicht bereits Verbraucherverkäufe umfasst. Die pragmatische Haltung: Selbst dort, wo B2C-E-Rechnungen für Sie nicht vorgeschrieben sind, kostet es Sie nichts zusätzlich, die oben beschriebene Datenqualität auf strukturbereitem Niveau zu halten. Und es bedeutet, dass eine künftige B2C-Ausweitung in einem Ihrer Märkte eher eine Konfigurationsänderung ist als ein Notfall. Beachten Sie außerdem, dass der Fernabsatz an Verbraucher unabhängig von E-Rechnungen eigene Dokumentationspflichten mit sich bringt — siehe Fernabsatzvorschriften.

Ihr Aktionsplan

Sie müssen nicht jedes Land auf einmal lösen. Sie müssen wissen, wo Sie betroffen sind, und Ihre Daten sauber bekommen — in genau dieser Reihenfolge.

  • Ordnen Sie Ihre B2B-Märkte den Fristen zu. Listen Sie die Länder auf, in denen Sie tatsächlich B2B-Rechnungen ausstellen, und halten Sie für jedes das aktuelle Datum und Format fest. Unmittelbar relevant: Italien (live), danach Frankreich, Deutschland, Polen, Spanien.
  • Prüfen Sie Ihre Rechnungsdaten jetzt. Ziehen Sie zehn aktuelle B2B-Rechnungen und kontrollieren Sie, ob jedes oben genannte EN-16931-Feld vorhanden und korrekt ist. Die Lücken, die Sie heute finden, sind die Ablehnungen, die Sie am Starttag treffen würden.
  • Beheben Sie die Datenprobleme an der Quelle. Validieren Sie die USt-IdNr. des Käufers an der Kasse, bereinigen Sie Ihre Steuerregeln und sichern Sie die fortlaufende Nummerierung ab — das sind die drei Aufgaben, die jedes nachgelagerte Format funktionieren lassen. Die oben genannten Module erledigen genau das aus dem Backoffice heraus, ohne Entwicklerrechnung.
  • Wählen Sie Konvertierung + Übertragung pro Markt. Ein nationales Modul, wenn Sie ein oder zwei Märkte haben und Schema-Updates selbst verantworten möchten; ein Vermittlungsanbieter, wenn Sie mehrere Märkte haben oder sich damit nicht belasten wollen.
  • Sprechen Sie mit Ihrem Steuerberater. Er sollte die genauen Termine und Schwellenwerte für Ihre konkrete Situation bereits verfolgen — dieser Leitfaden sagt Ihnen, was Sie fragen müssen, nicht was Sie einreichen sollen.
  • Prüfen Sie die Zeitleiste zweimal jährlich erneut. Mehrere dieser Termine werden noch finalisiert und wurden bereits verschoben; eine Kalendererinnerung ist besser als hektisches Nacharbeiten in letzter Minute.

Häufig gestellte Fragen

Reicht das umsatzsteuerlich korrekte PDF, das PrestaShop bereits per E-Mail verschickt, nicht aus?

Nicht in einem Land mit Pflicht zur strukturierten E-Rechnung. Dieses PDF ist eine digitale Rechnung — ein Bild für einen Menschen. Eine konforme elektronische Rechnung in Italien, Frankreich, Polen und den übrigen Ländern ist eine strukturierte XML-Datei (oft auf Basis von EN 16931), die von einer Maschine validiert und über eine staatliche Plattform oder ein zertifiziertes Netzwerk übertragen wird. PrestaShop erzeugt das PDF nativ; daraus die geforderte strukturierte Datei zu machen, ist die Lücke, die Sie schließen müssen, und dabei geht es vor allem um Datenqualität.

Wann genau wird die E-Rechnung in Frankreich und Polen verpflichtend?

Die Richtung ist klar, aber die genauen Termine sind es nicht — beide wurden bereits verschoben. Zum Zeitpunkt dieser Überprüfung ist Frankreich ungefähr für 2026–2027 anvisiert (stufenweise, zuerst Empfang und Großunternehmen), und Polens KSeF wird stufenweise eingeführt, mit großen Steuerpflichtigen ab Februar 2026 und den übrigen ab April 2026. Behandeln Sie diese Daten als Planungsanker, nicht als Zusagen: Bestätigen Sie das aktuelle Datum und den Schwellenwert für Ihre Situation mit Ihrem Steuerberater oder der nationalen Steuerbehörde (DGFiP für Frankreich, Ministerium der Finanzen / KAS für Polen), bevor Sie etwas darum herum bauen.

Brauche ich ein PrestaShop-Modul, das das XML erzeugt, oder einen externen Anbieter?

Das hängt von Ihrer Marktpräsenz ab. Ein oder zwei Märkte mit planbarem Volumen und der Bereitschaft, Schema-Updates selbst zu verantworten: Ein länderspezifisches Modul, das das nationale XML innerhalb von PrestaShop erzeugt, kann funktionieren. Mehrere Märkte oder keine Lust, Formatänderungen zu verfolgen: Ein externer E-Rechnungsanbieter, der Ihre Daten übernimmt, die Datei erzeugt und die Übertragung gegen eine Gebühr pro Rechnung abwickelt, ist die übliche Wahl. In jedem Fall besteht die eigentliche Aufgabe Ihres Shops darin, saubere Daten zu liefern.

Was ist der häufigste Grund, warum eine strukturierte E-Rechnung abgelehnt wird?

Eine fehlende oder ungültige USt-IdNr. des Käufers auf einer B2B-Rechnung, gefolgt von Steuerbeträgen, die nicht zu den Zwischensummen je Steuersatz passen. Am anderen Ende gibt es keinen Menschen, der das korrigiert — die Datei wird abgewiesen. Wenn Sie USt-IdNrn. an der Kasse gegen VIES validieren (damit eine falsche Nummer nie auf die Rechnung gelangt) und Ihre Steuerregeln sauber halten, beseitigen Sie die zwei größten Quellen für Ablehnungen am Starttag.

Ich verkaufe nur B2C — kann ich das alles ignorieren?

Größtenteils, vorerst, mit Italien als bestehender Ausnahme, wo die Pflicht bereits Verbraucherverkäufe umfasst. Klüger ist es aber, Ihre Rechnungsdaten trotzdem auf einem strukturbereiten Standard zu halten: Es kostet Sie nichts zusätzlich und macht jede künftige B2C-Ausweitung in Ihren Märkten zu einer Konfigurationsänderung statt zu einem Notfall. Und bestätigen Sie Ihre eigene Position mit Ihrem Berater — der B2C-Anwendungsbereich ist einer der Punkte, die sich weiterhin bewegen.

Die E-Rechnung ist nicht der spannendste Punkt auf der Liste eines Shopbetreibers, aber sie hat etwas, das den spannenden Themen oft fehlt: eine harte Frist. Händler, die davon überrascht werden, scheitern nicht daran, dass sie zu spät mit der Übertragung begonnen haben — das ist ein Anbieterproblem, aus dem man sich innerhalb einer Woche freikaufen kann. Sie scheitern daran, dass ihre zugrunde liegenden Rechnungsdaten unordentlich waren und sie am Morgen des Pflichtstarts feststellen, dass die Hälfte ihrer B2B-Rechnungen keine gültige USt-IdNr. des Käufers enthält oder nicht sauber nummeriert ist. Bringen Sie die Daten in Ordnung, solange es noch freiwillig ist, und die Frist ist, wenn sie kommt, das Problem eines anderen.

Verwandte Leitfäden

Schlagwörter: PrestaShop SEO Steuern
Diesen Beitrag teilen:
David Miller

David Miller

Gründer, mypresta.rocks

David Miller ist PrestaShop-Spezialist mit über einem Jahrzehnt praktischer Erfahrung und Gründer von mypresta.rocks, einem Software-Studio im polnischen Tychy. Er entwickelt und pflegt einen Katalog von 152 PrestaShop-Modulen – darunter 21 „Revolution"-Suiten für SEO, Checkout, Sicherheit, Performance, Marketing, Suche, Support und Lagerverwaltung –, die reale Shops Tag für Tag verbessern und für PrestaShop 1.7.8, 8.x und 9.x getestet sind. Darüber hinaus betreut er Produktivshops mit einem Jahresumsatz in Millionenhöhe, sodass seine Arbeit an echten Verkäufen gemessen wird und nicht an Demos. Seine Erfahrung deckt die gesamte Bandbreite des E-Commerce ab – Performance, Sicherheit, SEO und Marketing – und reicht über PrestaShop hinaus bis zu WooCommerce, Shopify und maßgeschneiderten Systemen. Im Blog schreibt er über die technische Seite von PrestaShop: was die Plattform wirklich tut, was in der Produktion bricht und welche Lösungen sich bewähren.

Hat Ihnen dieser Artikel gefallen?

Erhalten Sie unsere neuesten Tipps, Anleitungen und Modul-Updates direkt in Ihr Postfach.

Kommentare

Noch keine Kommentare. Seien Sie der Erste!

Stellen Sie als Erster eine Frage oder teilen Sie hilfreiches Feedback.

Lade ...
Nach oben