Die Frage kommt meist am Rand eines anderen Termins. Jemand aus der Geschäftsführung fragt, ob das mit der E-Rechnung sie überhaupt betrifft, und nennt dann eine Zahl aus dem Shop-Dashboard. Brutto, alle Kanäle, inklusive OSS-Umsätze aus Österreich und Frankreich. Diese Zahl ist für die Frage weitgehend unbrauchbar.
Die Versandpflicht ab dem 1. Januar 2027 hängt am Gesamtumsatz des Vorjahres, also an 2026. Das läuft gerade. Wer im Dezember auf den Jahresabschluss wartet, hat vier Wochen für eine Umstellung, die im ERP je nach Ausgangslage mehrere Wochen dauert.
Die Zahl, an der es hängt, steht nicht im Shop-Dashboard
Maßgeblich ist der Gesamtumsatz im Sinne des Umsatzsteuergesetzes: netto, ohne Umsatzsteuer, und über alle Kanäle hinweg. B2C zählt mit. Marktplatzumsätze zählen mit. Innergemeinschaftliche Lieferungen an Geschäftskunden zählen mit, obwohl sie steuerfrei sind.
Umsätze, die du über das OSS-Verfahren in anderen EU-Ländern versteuerst, sind in Deutschland nicht steuerbar und gehen nach dem Wortlaut nicht in den Gesamtumsatz ein. Das ist bei Händlern mit starkem EU-Geschäft der Unterschied zwischen "betroffen" und "nicht betroffen", und es ist der Punkt, an dem wir auf die Steuerberatung verweisen. Wir bauen Schnittstellen, wir geben keine Auskunft zur Bemessungsgrundlage.
Praktisch heißt das: Frag nach der Kennzahl aus der Umsatzsteuer-Voranmeldung, nicht nach dem Wert aus dem Reporting. Und rechne den Wert nach dem dritten Quartal 2026 hoch, nicht erst im Januar.
Wenn 2026 unter 800.000 Euro liegt, gilt die Übergangsfrist noch bis Ende 2027. Ab dem 1. Januar 2028 sendet jeder strukturiert. Die Frage ist also nicht, ob, sondern ob ein Jahr früher.
Empfangen musst du längst
Seit dem 1. Januar 2025 muss jedes inländische Unternehmen E-Rechnungen von anderen inländischen Unternehmen annehmen und verarbeiten können, ohne Schwelle und ohne Übergangsfrist. In der Praxis reicht dafür ein Postfach und ein Prozess dahinter. Auffällig oft finden wir genau das nicht: Die XML-Datei landet im Sammelpostfach, jemand öffnet das beigelegte PDF, und die strukturierten Daten werden nie ausgelesen.
Das ist kein Formfehler mit Bußgeld, aber ein Archivierungsproblem. Aufbewahrungspflichtig ist der strukturierte Teil, unverändert, seit 2025 für acht Jahre. Wer nur das Sichtformat aus einem ZUGFeRD-PDF ablegt und das Original löscht, hat die Rechnung formal nicht aufbewahrt.
Die Leitweg-ID brauchst du wahrscheinlich nicht
In fast jedem Gespräch zu dem Thema fällt der Begriff Leitweg-ID, meist verbunden mit der Sorge, man müsse sie künftig von allen Geschäftskunden einsammeln. Muss man nicht. Die Leitweg-ID ist ein Adressierungsmerkmal öffentlicher Auftraggeber. Im B2B-Verkehr ist das Feld BT-10 (Buyer reference) optional, und dort steht in der Praxis eher die Bestellnummer des Kunden.
Zweite verbreitete Annahme: Man brauche Peppol. Auch nicht. Der Übertragungsweg ist zwischen den Beteiligten frei vereinbar. Eine XRechnung als Anhang einer normalen E-Mail erfüllt die Anforderung. Peppol, AS2 oder ein Kundenportal sind Komfort- und Skalierungsthemen, keine gesetzlichen.
Zulässig sind XRechnung und ZUGFeRD, sofern das Profil der europäischen Norm entspricht. Bei ZUGFeRD gilt das ab Profil BASIC. Die Profile MINIMUM und BASIC WL genügen nicht, weil dort Angaben fehlen, die eine Rechnung im Sinne des UStG braucht. Wer heute schon ZUGFeRD ausliefert, sollte nachsehen, welches Profil die Ausgabevorlage tatsächlich erzeugt. Wir haben Setups übernommen, in denen es MINIMUM war, weil das beim Testen am wenigsten Ärger machte.
Wo es im ERP klemmt: Nummernkreise und Stammdaten
Das Format ist selten das Problem. Shopware, JTL-Wawi und PlentyONE können strukturiert ausgeben, teils nativ, teils über Erweiterungen. Was hakt, sitzt eine Ebene tiefer.
Erstens die Rechnungsnummern. Sobald Rechnungen an mehr als einer Stelle entstehen, gibt es doppelte Nummern. Typische Konstellation: Das ERP nummeriert den eigenen Versand, Amazon erzeugt über VCS eigene Rechnungen, und ein Fulfiller schreibt für Retouren Korrekturen mit eigenem Kreis. Solange PDFs verschickt wurden, ist das nie aufgefallen. Ein strukturierter Empfänger prüft BT-1 auf Eindeutigkeit und lehnt die zweite Rechnung mit derselben Nummer ab. Wer Amazon mit aktiviertem VCS nutzt, sollte hier ohnehin hinsehen: JTL-Wawi 1.10, stabil seit dem 1. Oktober 2025, hat die VCS-Verarbeitung komplett neu gebaut und erkennt jetzt selbst, ob VCS, VCS Lite oder IDU vorliegt. Das ändert, welche Belege überhaupt im eigenen Nummernkreis landen.
Zweitens die Kundenstammdaten. XRechnung verlangt eine elektronische Adresse des Käufers, Feld BT-49. In Kundendatensätzen, die über Marktplätze oder einen alten Import entstanden sind, steht dort nichts oder eine anonymisierte Weiterleitungsadresse. Dazu kommen Länderkennzeichen im falschen Format, fehlende Postleitzahlen und Firmennamen, die im Feld "Vorname" stehen. Bei einem Bestand von einigen Tausend B2B-Kunden ist das kein Nachmittag Arbeit, sondern eine Bereinigung mit Rückfragen an den Vertrieb.
Drittens die Unterscheidung B2B und B2C. Die Pflicht gilt nur für inländische Umsätze zwischen Unternehmen. Das ERP muss also sicher wissen, welcher Auftrag welcher ist. "Hat eine USt-IdNr. eingetragen" ist als Kriterium schwach, weil Kleinunternehmer keine haben und Privatkunden gelegentlich eine eintragen, die sie irgendwo gefunden haben. Wir setzen das in Projekten über ein eigenes Kundengruppen- oder Attributfeld, das an der Ausgabelogik hängt, nicht über eine Heuristik im Template.
Kleinbetragsrechnungen bis 250 Euro dürfen weiter als sonstige Rechnung gehen. Für einen Ersatzteilversand mit vielen kleinen B2B-Belegen ist das eine echte Entlastung. Zwei Rechnungswege parallel zu betreiben ist trotzdem meist teurer als einer.
Rundungsdifferenzen sind der häufigste Ablehnungsgrund
Wenn die erste Testrechnung durch einen Validator läuft, kommt selten ein Formatfehler zurück. Es kommt eine Rechenregel. Am häufigsten diese:
[BR-CO-13] Invoice total amount without VAT (BT-109) = Σ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108)
Dahinter steckt fast immer dasselbe: Der Shop rechnet mit vier Nachkommastellen pro Position, das ERP rundet auf zwei, und bei zwanzig Positionen fehlt ein Cent. Oder ein prozentualer Rabatt wird pro Position verteilt, aber auf Dokumentebene noch einmal ausgewiesen. Solche Differenzen fielen in einem PDF niemandem auf. Die Norm akzeptiert sie nicht.
Gleiches gilt für Korrekturen. Eine Rechnungskorrektur ist selbst eine E-Rechnung, mit Dokumententyp 381 statt 380 und einem Verweis auf die Ursprungsrechnung. Systeme, die Stornos als negative Rechnung im normalen Kreis abbilden, brauchen dafür eine Anpassung.
Wer EDI fährt, hat etwas Luft: Bestehende EDI-Verfahren dürfen für Umsätze bis Ende 2027 weiterlaufen, auch wenn das Format nicht normkonform ist. Danach müssen sich die erforderlichen Angaben normkonform daraus ableiten lassen. Wie einzelne Handelsketten das in ihren EDIFACT-Strecken lösen wollen, ist im Moment noch nicht überall geklärt.
Ein realistischer Ablauf für 2026
Bis Ende des dritten Quartals steht die Umsatzprognose und damit die Antwort auf die Frage, ob 2027 oder 2028 gilt. Parallel dazu lässt sich klären, welches Profil das System heute erzeugt und wo Rechnungsnummern entstehen. Die Stammdatenbereinigung ist der Teil, der Kalenderzeit braucht, weil sie ohne Rückfragen nicht auskommt. Der technische Umbau der Ausgabe ist danach überschaubar, und Testrechnungen an drei größere Kunden bringen mehr Erkenntnis als jeder Validator, weil dort auch das ankommende System mitprüft.
Wer im Oktober anfängt, kommt hin. Wer im Dezember den Abschluss abwartet, verschickt im Januar PDFs, die formal keine Rechnungen mehr sind.
Nebenbei: Für Shopware-Betreiber lohnt im Frühjahr ein zweiter Blick auf den Releaseplan. Für 6.7.9 ist ein nativer Widerrufsbutton nach § 356a BGB angekündigt, und auch das ist eine gesetzlich getriebene Änderung, die man aktiv einbauen muss und nicht durch ein Update bekommt. Wer beides ohnehin anfasst, plant es besser in einem Fenster.
KI-generierter Inhalt.