XRechnung im TMS einrichten: Schritt für Schritt
So richten Sie XRechnung/ZUGFeRD-Versand im TMS ein: Felder, Peppol-Anbindung, KoSIT-Validierung und GoBD-Archivierung – Schritt für Schritt erklärt.
Warum das jetzt dringend wird
Wer Frachtrechnungen noch als PDF per E-Mail verschickt, hat weniger Zeit als gedacht. Ab dem 1. Januar 2027 müssen Unternehmen mit einem Vorjahresumsatz von mehr als 800.000 Euro im B2B-Bereich E-Rechnungen versenden. Ab dem 1. Januar 2028 gilt die Versandpflicht dann unabhängig vom Umsatz für alle inländischen B2B-Unternehmen. Die Empfangspflicht gilt bereits länger: Seit dem 1. Januar 2025 sind alle inländischen B2B-Unternehmen verpflichtet, elektronische Rechnungen empfangen zu können. 2026 ist damit das Jahr, in dem Speditionen und Verlader ihre Fakturierung im TMS testen und stabilisieren müssen, bevor der Stichtag 2027 verbindlich wird.
Eine Randnotiz, die in der Praxis oft übersehen wird: der aktuelle Stand ist, dass das EDI-Verfahren auch über 2028 hinaus weiter genutzt werden kann, sofern ab dem 1. Januar 2028 aus der EDI-Rechnung ein Meldedatensatz gemäß dem Umsatzsteuergesetz korrekt und vollständig extrahiert werden kann. Für Speditionen, die seit Jahren EDIFACT-Rechnungssätze mit Verladern austauschen, ist das eine Erleichterung, aber keine Ausrede. Sie müssen trotzdem nachweisen können, dass der Meldedatensatz vollständig extrahierbar ist.
Wichtig für die Formatwahl: Die Frachtrechnung an einen privaten Verlader ist eine B2B-Transaktion, keine B2G-Transaktion. XRechnung ist zwingend nur bei Behördenkunden oder öffentlichen Ausschreibungen vorgeschrieben. Für den Großteil der Speditionskunden ist ZUGFeRD im Profil EN 16931 der praktikablere Weg, weil es PDF-Lesbarkeit mit strukturierten Daten verbindet.
Was Sie vor dem Start brauchen
Bevor Sie im TMS irgendetwas konfigurieren, müssen folgende Voraussetzungen stehen:
- Eine TMS- oder ERP-Version mit E-Invoicing-Modul oder Schnittstelle. In der Praxis begegnen Sie hier SAP mit Document and Reporting Compliance (DRC), Soloplan CarLo, WinSped, ecovium TMS oder vergleichbaren Speditions-ERPs. Multi-Carrier-Plattformen wie Cargoson liefern in der Regel die strukturierten Auftragsdaten zu, die Fakturierung selbst läuft über das angebundene ERP.
- Vollständige Stammdaten: USt-IdNr., IBAN, ggf. Leitweg-ID bei Behördenkunden.
- Eine vertragliche Klärung mit jedem relevanten Kunden, welches Format er akzeptiert – ZUGFeRD ab Profil EN 16931 oder XRechnung.
- Zugang zu einem Validierungswerkzeug. Der Standard hierfür ist der KoSIT Validator, downloadbar von GitHub (itplr-kosit), auch zugänglich über den ecosio-Online-Wrapper.
- Eine Entscheidung, ob Sie einen eigenen Peppol Access Point betreiben oder einen Service-Provider nutzen.
Die Einrichtung: acht Schritte im TMS
Die folgende Abfolge hat sich in DACH-Projekten bewährt, unabhängig davon, ob Sie ein Speditions-ERP oder SAP als Fakturasystem einsetzen.
- Rechnungsprozesse der Top-Kunden erfassen. Prüfen Sie pro Kunde, ob er Peppol-fähig ist, welches ZUGFeRD-Profil er erwartet oder ob er ausschließlich XRechnung akzeptiert.
- Format je Kundengruppe festlegen. Öffentliche Auftraggeber erhalten XRechnung bzw. das passende CIUS-Profil, private Verlader in der Regel ZUGFeRD im Profil EN 16931.
- Stammdaten im TMS/ERP hinterlegen. Dazu gehören die USt-IdNr. (BT-31), IBAN (BT-84) und die Buyer Reference (BT-10). Für B2B ist das oft eine Bestellnummer oder Vertragsreferenz, die der Käufer verlangt. Ergänzen Sie ein Zusatzfeld für die Frachtbrief- oder CMR-Referenz, damit der Verlader die Rechnung seiner Sendung zuordnen kann.
- E-Invoicing-Modul aktivieren. Bei SAP ist das DRC, bei On-Premise-Installationen häufig über einen Cloud Connector zum Peppol Access Point. Bei Speditions-ERPs wie ecovium ist die E-Rechnungsfunktion meist als Erweiterung der bestehenden Fakturierung angelegt.
- Testrechnung erzeugen und validieren. Prüfen Sie jede Testrechnung gegen den KoSIT-Validator bzw. das Schematron-Regelwerk, bevor überhaupt ein Kunde involviert wird.
- Pilotversand an zwei bis drei Kunden. Sammeln Sie Rückmeldungen zu Ablehnungen systematisch, nicht ad hoc per E-Mail-Verlauf.
- Rollout auf den gesamten Kundenstamm. Dokumentieren Sie parallel einen Fallback-Prozess für Kunden, die noch keine E-Rechnungen verarbeiten können.
- GoBD-konforme Archivierung einrichten. Erst hier ist der Prozess wirklich abgeschlossen – dazu mehr im Abschnitt weiter unten.
Woran Sie erkennen, dass es funktioniert
Der Test ist einfach, aber unbequem, wenn er fehlschlägt: Das Validierungsprotokoll muss ohne Fehler durchlaufen, und Sie brauchen eine Zustellbestätigung – entweder über den Peppol-Access-Point oder eine Empfangsquittung des Kunden. Der eigentliche Beweis ist aber operativ: Der Kunde kann die Rechnung automatisiert verbuchen, ohne manuelle Nachbearbeitung und ohne Rückfragen zu fehlenden Referenzen. Wenn Ihre Buchhaltung stattdessen wöchentlich Anrufe wegen fehlender Auftragsnummern bekommt, ist die Einrichtung nicht abgeschlossen, auch wenn die Rechnung technisch valide war.
Format-Vergleich: ZUGFeRD, XRechnung, Peppol BIS
| Kriterium | ZUGFeRD (CII) | XRechnung | Peppol BIS Billing 3.0 |
|---|---|---|---|
| Format oder Profil | immer CII-basiert, kombiniert PDF-Darstellung mit eingebetteten strukturierten XML-Daten | kein eigenes Datenformat, sondern ein Anforderungsprofil, technisch auf CII oder UBL basierend | basiert auf UBL 2.1 als Standard-Syntax mit CIUS-Implementierung der EN 16931 |
| Einsatzbereich | B2B, Frachtrechnung an private Verlader | verpflichtend für Behörden (B2G) | grenzüberschreitendes B2B und B2G über das Netzwerk |
| Profile/Varianten | Profil EN 16931 oder EXTENDED zwingend; MINIMUM und BASIC-WL reichen für die gesetzliche Pflicht nicht aus | CII- oder UBL-Variante, jeweils eigene Prüfregeln | strengere Business-Rules zusätzlich zur EN 16931 |
| Validierung | KoSIT-Validator (auch XML-Teil), Mustang Project | KoSIT-Validator, Schematron | Peppol-spezifische Schematron-Regeln, teils strenger als nationale Prüfung |
| Übertragungsweg | meist E-Mail | E-Mail, Portal, Peppol | ausschließlich über Peppol-Netzwerk (4-Corner-Modell) |
Der häufigste Fehler: abgelehnte Rechnung wegen fehlendem Pflichtfeld
In der Praxis scheitern die meisten Frachtrechnungen nicht an grundsätzlicher Formatwahl, sondern an Details, die im Testlauf übersehen wurden. Zwei Muster wiederholen sich:
Erstens die fehlende Leitweg-ID bei Behördenkunden. Die Leitweg-ID ist die Routing-Kennung, die von der öffentlichen Stelle vergeben wird, die Sie in Rechnung stellen; ohne gültige Leitweg-ID wird die Rechnung von Regierungsportalen abgelehnt. Das betrifft Speditionen, die auch Kommunen, Landesbehörden oder öffentliche Verkehrsbetriebe beliefern.
Zweitens die falsche Profilwahl bei ZUGFeRD. Wird eine Rechnung im Profil BASIC statt EN 16931 oder EXTENDED erzeugt, fehlt die Datentiefe, die für eine Peppol-Konvertierung oder die gesetzliche Pflicht notwendig ist. Ein technisch gültiges Dokument in ZUGFeRD oder XRechnung ist nicht automatisch Peppol-konform, und selbst ein UBL-Dokument, das die XSD-Validierung besteht, kann im Peppol-Netzwerk an einer länderspezifischen Schematron-Regel scheitern. Seit dem BMF-Schreiben vom 15.10.2025 ist zudem verbindlich geregelt, dass jede E-Rechnung drei Validierungsstufen durchlaufen muss – Formatprüfung (XSD), Geschäftsregeln (Schematron), Inhaltsprüfung – wobei Fehler der Klasse A (Formatfehler) und B (Geschäftsregelverletzung) dazu führen, dass die E-Rechnung nicht als gültige E-Rechnung verarbeitet werden kann.
Die Lösung dafür ist organisatorisch, nicht nur technisch. Setzen Sie einen Profile Checker vor jeden Versand, definieren Sie eine klare Eskalationsroute – im Zweifel die Rechnung zurückhalten statt fehlerhaft versenden – und dokumentieren Sie jeden abgelehnten Testfall, damit sich Fehler nicht in der Breite wiederholen. Klären Sie außerdem intern, wer bei einer Ablehnung reagiert: Buchhaltung, IT oder der ERP-Dienstleister. In vielen Unternehmen ist das nicht eindeutig geregelt, was Fehlerkorrekturen unnötig verzögert.
GoBD-Archivierung: was zusätzlich zur Formaterstellung gehört
Die technisch korrekte E-Rechnung ist nur die halbe Miete. Die andere Hälfte ist die Aufbewahrung, und hier gilt eine wichtige Neuerung: seit 2025 gelten acht Jahre Aufbewahrungsfrist für Rechnungen nach § 14b UStG und BEG IV, während für ältere Belege und für Handelsbücher weiterhin zehn Jahre gelten. Die Frist beginnt nicht mit dem Rechnungsdatum, sondern mit dem Ende des Kalenderjahres, in dem die Rechnung ausgestellt wurde – eine Rechnung vom April 2025 muss also bis zum 31. Dezember 2035 aufbewahrt werden.
Für hybride Formate wie ZUGFeRD gibt es eine praxisrelevante Erleichterung aus dem BMF-Schreiben vom 14. Juli 2025: bei E-Rechnungen reicht die Aufbewahrung des strukturierten Teils, etwa der XML-Datei; der menschenlesbare PDF-Teil ist nur aufzubewahren, wenn er abweichende oder steuerlich relevante Zusatzinformationen enthält, andernfalls muss das PDF-Bild nicht zusätzlich gespeichert werden. Das reduziert den Speicheraufwand, ändert aber nichts an der Kernanforderung: elektronische Rechnungen stellen originär elektronische Unterlagen dar, die im Ursprungsformat aufzubewahren sind, und sind mit Blick auf den Vorsteuerabzug stets unveränderbar aufzubewahren.
Für die Praxis im TMS heißt das konkret:
- Original-XML unveränderbar speichern, keine Konvertierung ohne dokumentierten Prozess.
- Bei ZUGFeRD die komplette PDF/A-3-Datei mit eingebettetem XML aufbewahren, wenn der PDF-Teil zusätzliche Informationen trägt.
- Ein Anzeigeprogramm (Viewer) vorhalten, weil Rechnungen in Formaten wie XML oder EDIFACT für das prüferische Auge lesbar dargestellt werden können müssen und ein geeignetes Anzeigeprogramm empfohlen wird.
- Eine Verfahrensdokumentation führen, die für einen sachverständigen Dritten in angemessener Zeit nachprüfbar ist – sie muss über die gesetzliche Aufbewahrungsfrist in der jeweiligen Versionierung vorgehalten werden.
- Rollen klar zuweisen: Wer archiviert eingehende, wer ausgehende Rechnungen, wer verantwortet die Freigabe im internen Kontrollverfahren.
Wo Cargoson und andere TMS-Plattformen im Prozess ansetzen
Speditions-ERPs bringen die E-Invoicing-Logik oft nativ mit. Bei ecovium etwa wird für die E-Rechnung eine Import-Funktion bereitgestellt, die die Datei direkt in das TMS als Eingangsbeleg übernimmt, wodurch die Erfassung von Eingangsbelegen stark vereinfacht wird oder als manuelle Tätigkeit entfällt. Für den Ausgang gilt: bis spätestens 2028 müssen auch die Ausgangsbelege direkt aus dem TMS als E-Rechnung versendet werden, wofür der Belegabschluss in der Fakturierung um ein neues Ausgabeformat erweitert wird.
Multi-Carrier- und Frachtmanagement-Plattformen wie Cargoson, Alpega, MercuryGate oder Transporeon setzen an einer anderen Stelle an: Sie liefern primär die strukturierten Auftrags- und Sendungsdaten – Referenzen, Kostenstellen, Frachtbriefnummern – die als Pflichtfelder in die E-Rechnung einfließen müssen. Die eigentliche Rechnungsstellung läuft in der Regel über das angebundene ERP- oder Faktura-System. Wenn Sie ein TMS oder eine Multi-Carrier-Plattform evaluieren, lohnt sich deshalb ein genauer Blick darauf, wie sauber diese Referenzdaten exportierbar sind – nicht nur, ob ein Anbieter „E-Invoicing“ auf der Featureliste stehen hat.
Nächste Schritte
Beginnen Sie mit einer Bestandsaufnahme Ihrer zehn umsatzstärksten Frachtkunden: Welches Format erwarten sie, welche Referenzfelder verlangen sie, und ist Ihr TMS heute überhaupt in der Lage, diese Felder korrekt zu befüllen? Parallel dazu klären Sie mit Ihrem ERP- oder TMS-Anbieter, ob das E-Invoicing-Modul bereits produktiv nutzbar ist oder erst für 2026 angekündigt wurde. Wer diesen Test jetzt macht, hat bis zum verbindlichen Stichtag 2027 genug Zeit, Ablehnungsfehler auszumerzen, statt sie im Echtbetrieb zu entdecken.
