SAP Travel Management in S/4HANA: Migration, Erweiterungen und Perspektiven für Bestandskunden

SAP Travel Management: So gelingt die Migration zu S/4HANA

Wer auf S/4HANA 2025 wechselt, muss auch über die Reisekosten entscheiden. SAP Travel Management bleibt verfügbar, wird aber kaum noch weiterentwickelt. Dieser Beitrag zeigt, was das Release bringt, was entfällt und worauf Projekte achten sollten.

Situation analysieren

Ausgangslage

Reisemanagement (FI-TV) läuft in vielen SAP ECC Systemen seit Jahren unauffällig: Reiseantrag, Reiseplanung, Spesenabrechnung, Übergabe an Finanzbuchhaltung und Payroll. Bei der Conversion nach S/4HANA stellt sich deshalb regelmäßig die Frage, was aus dieser Komponente wird.

Die Kurzfassung nach SAP-Hinweis 3617075 und der SAP-Präsentation zu S/4HANA 2025: SAP Travel Management ist Teil von S/4HANA on-premise und als Option in der Private Cloud Edition (PCE) verfügbar. Der Funktionsumfang entspricht im Wesentlichen dem Compatibility Scope auf Basis ECC 6.0 EHP8, ergänzt um neue Fiori-Apps. Die strategische Weiterentwicklung im Reisekostenumfeld liegt bei SAP Concur.

Hinweis: SAP unterscheidet die ältere FI-TV-Lösung im Compatibility Scope vom seit S/4HANA 2022 verfügbaren SAP Travel Management for SAP S/4HANA. Die FI-TV-Lösung im Compatibility Scope wird in diesem Beitrag nicht weiter betrachtet, da Ende 2025 ausgelaufen ist.

Lösungswahl

Einordnung: Concur oder SAP Travel Management?

In der SAP S/4HANA Cloud, Public Edition steht ausschließlich SAP Concur zur Verfügung. In der Private Edition ist Travel Management eine Option für Kunden aus ECC oder S/4HANA, die nicht sofort auf Concur wechseln können oder wollen. SAP richtet das Angebot an die Installed Base, nicht an Neukunden. On-premise gehört Travel Management zum S/4HANA-Standard und folgt der Wartungsstrategie von S/4HANA bis 2040. Zum Vergleich: Für ECC (Business Suite 7) endet die Standardwartung Ende 2027, optional erweiterte Wartung ist bis Ende 2030 vorgesehen (Hinweis 2881788).

	SAP Concur	Travel Management (PCE)	Travel Management (On-Premise)
Bereitstellung	Cloud	Option in S/4HANA Cloud, Private Edition	im S/4HANA-Standard
Einordnung durch SAP	strategische Lösung	Bestandsschutz	Bestandsschutz
Weiterentwicklung	Investitionsschwerpunkt	selektiv	selektiv

Neue Funktionen

Funktionsumfang und Neuerungen in 2025

Funktionsumfang. FI-TV besteht aus den Teilkomponenten Reiseantrag, Reiseplanung und Reisekosten- bzw. Spesenabrechnung. Die Abrechnung ist die Ankerkomponente und lässt sich unabhängig von den anderen einsetzen. Reisende erfassen ihre Daten dezentral, oder die Spesenabteilung erfasst sie zentral. Genehmigt wird per SAP Business Workflow, über das Genehmigungsprogramm oder, in den neuen Apps, über My Inbox. Die Abrechnung folgt den hinterlegten Reiseregelungen. Die Ergebnisse gehen an Finanzbuchhaltung, Controlling, Haushaltsmanagement und, für die Versteuerung, an die Personalabrechnung. Ausgezahlt wird über FI, Payroll oder Datenträgeraustausch. Ergänzt wird das durch Kreditkartenclearing, Beleg-Wizard und Reisestatistiken.

Länderversionen gibt es für Deutschland, Österreich, Großbritannien, Italien, Frankreich, Dänemark, Norwegen, Spanien, Schweden, Tschechien, die Slowakei, Polen, Russland, die Ukraine, die USA, Kanada, Mexiko und Japan. Für den öffentlichen Dienst existieren Versionen für Deutschland (alle 16 Bundesländer) und Österreich.

Neu mit S/4HANA 2025. Kern der Neuerungen sind neue Fiori-Apps für Reiseanträge:

„My Travel Requests (Version 4) for Business Traveler“ (F6015A) und „Travel Requests (Version 4) for Travel Assistant“ (F0409C), gebaut mit SAP Fiori elements für OData V4 und dem RAP-Framework. Die Vorgänger F6015 und F0409B gelten als deprecated.

Anlagen werden über das Harmonized Document Management (HDM) verwaltet.

Concurrent Employment ist integriert: Über „Select Employment“ wechseln Nutzer zwischen ihren Beschäftigungsverhältnissen.

Das Produkt wird an S/4HANA-Standards angeglichen: DSGVO-Framework für Archivierung und Löschung, Barrierefreiheit, Performance, einheitliche Darstellung.

Es gibt kein neues Customizing. Die Genehmigung läuft über einen neuen OData-Service für My Inbox, die bestehende Konfiguration bleibt nutzbar.

Insgesamt stehen zwei Rollen mit diesen Fiori-Apps zur Verfügung:

Business Traveler (My Travel Requests, My Credit Card Transactions, My Travel and Expenses) und

Traveler Assistant (Maintain Employee List, Travel Requests, Travel and Expenses).

Die Spesen-Apps folgen später: V4-Versionen (F6190A, F0584C) sind laut SAP mit 2025 FPS2 geplant, also Ende 2026 und unverbindlich. Bis dahin bleiben die bisherigen Spesen-Apps im Einsatz.

Funktionsverlust

Was entfällt: Deprecated und Obsolete

SAP unterscheidet zwei Stufen. „Deprecated“ heißt: Die Funktion läuft und wird unterstützt, wird aber nicht mehr verbessert, und ein Nachfolger ist benannt. „Obsolete“ heißt: Die Funktion soll nicht mehr genutzt werden. Sie ist eingeschränkt oder nicht mehr unterstützt, und ihre Ausführung sollte gesperrt werden.

Die Reiseplanung als Ganzes ist deprecated, SAP plant hier keine Investitionen oder Erweiterungen mehr. Einen Nachfolger gibt es nicht. Deprecated sind konkret die Web-Dynpro-Anwendung FITP_PLANNING sowie die Fiori-Apps F6768 und F6771 (Reisepläne). SAP nimmt weder Weiterentwicklungen noch Anpassungen vor, wenn ein angebundenes Online-Buchungssystem wegfällt oder inkompatibel wird. Hintergrund ist unter anderem die Abkündigung von cytric AMI, dokumentiert in KBA 3602093. Die Abkündigung gilt ab 2022 SPS06, 2023 SPS04 und 2025.

Obsolet, also nicht mehr zu verwenden, sind unter anderem:

die Planungs- und Buchungstransaktionen der Reiseplanung selbst: TP01 bis TP60, TPLP, TPPR, TPQ0 sowie die Bypass-Transaktionen für Buchungssysteme (Amadeus, Apollo, Galileo, Sabre),

alte Erfassungs- und Hilfstransaktionen: PR01 und PR20 (Nachfolger PR05), PRTS (PRTE), PRAA (BP), PRCT (SPRO), PTRV_RTREE (SE43),

die Offline-Varianten PRWW und PTRV_OFFLINE sowie die PR_WEB_*-Dialoge,

die mit alter Technologie gebauten V2-Apps, etwa F0409A (Nachfolger F0409B) und F0584 (Nachfolger F0584A).

Praxistipp: Vor der Conversion prüfen, welche dieser Objekte tatsächlich genutzt werden. Nutzungsdaten und eine Custom-Code-Prüfung zeigen das schnell, besonders bei angebundenen Buchungssystemen.

Strategisch lohnt sich außerdem, Reiseplanung und Reiseantrag/-abrechnung getrennt zu bewerten. Auch wenn die klassische Buchungsanbindung ausläuft, lässt sich Travel Management für Antrag und Abrechnung weiterbetreiben, während die Buchung über ein Drittsystem oder bereits über Concur läuft.

Migrationsstrategie

Migration: Was das für das Projekt bedeutet

Die Ausgangslage ist günstig: SAP beschreibt den Übergang als vergleichbar mit einer neuen Release-Installation. Die Architektur bleibt gleich. Zentrale Datenbanktabellen, Berechtigungskonzept, IMG-Customizing, Business-Objekt-Definitionen bleiben weitgehend erhalten. Trotzdem gibt es Punkte, die früh geklärt sein sollten.

Betriebsmodell: Travel Management kann eingebettet oder auf einer separaten S/4HANA-Instanz laufen. Die Migration auf SAP HANA ist Voraussetzung. Als Wege nennt SAP Systemkonvertierung, Neuimplementierung und Selective Data Transition, in der PCE zusätzlich Lift & Shift.

Daten: Bei der Migration aus ECC nennt SAP ausdrücklich Anlagen (GOS- und ArchiveLink-Verknüpfungen) und BOR-Objekte, etwa BUS2089 für die Reise. Deren Tabellen werden oft von anderen Anwendungen mitgenutzt. Nach der Migration muss der Zugriff auf alle Daten gesichert sein. Sinnvoll ist außerdem, abgeschlossene Reisen vorab zu archivieren, um das Datenvolumen zu begrenzen.

Systemlandschaft: Die Dokumentation unterscheidet vier Konstellationen für Reisemanagement, Payroll und Rechnungswesen (in einem System oder getrennt, verbunden über ALE). Laufen die Komponenten heute getrennt, sollte das Zielbild geprüft werden. Das gilt auch für die Payroll-Integration (Merkmal TRVPA, Teilschemata) und die Replikation der Personalstammdaten (u. a. Infotypen 0001, 0002, 0006, 0009, 0017, 0105).

Testschwerpunkte: Abrechnungslauf, Buchungslauf in die Finanzbuchhaltung einschließlich Korrekturen und Stornos, Übergabe an die Payroll samt Versteuerung, Zahlungen per DTA, Kreditkartenclearing, Formulare, Berechtigungen (Objekt P_TRAVL) und Workflows.

Scope-Fragen: Den Rahmen des Compatibility Scope dokumentiert Hinweis 2269324.

Kritische Punkte

Stolpersteine und Erweiterbarkeit

Der eigentliche Aufwand entsteht selten in der technischen Migration, sondern bei Erweiterungen und Randprozessen, wenn Travel Management im Laufe der Jahre kundenspezifisch erweitert wurde. Und das ist bei langjährig eingesetzten SAP-Travel-Lösungen eher die Regel als die Ausnahme.

Erweiterbarkeit. Die neuen V4-Apps basieren auf Fiori elements und RAP und ersetzen die frei programmierten V2-Apps. Die Enhancement Spots und BAdIs der V2-Apps (etwa PAOC_MTR_BADI oder SRA004_BADI_MY_TRAVEL_REQ für Reiseanträge) lassen sich dort nicht mehr verwenden. Neue Enhancement Spots liefern die Hinweise 3296253 und 3260453, ergänzt durch 3520926 und 3520927. Hinzu kommen die RAP-Erweiterungen für Datenmodell, Verhalten und Knoten. Bestehende User-Exits und BAdIs der Web-Dynpro-ABAP-Anwendungen bleiben für die Backend-Logik verfügbar.

Für die Spesen-Apps gilt bis zur V4-Auslieferung der bisherige Ansatz (etwa PAOC_MY_TRAVEL_EXPENSES_BADI). Danach ist dort dieselbe Neubewertung nötig. SAP formuliert es im Migrationsleitfaden deutlich: Der Kunde muss das Erweiterbarkeitskonzept für jedes Migrationsprojekt prüfen und bewerten. Empfehlenswert ist deshalb eine Inventur entlang dreier Kategorien:

Backend-Erweiterungen: User-Exits und BAdIs, die Geschäftslogik verändern, etwa Prüfungen, Ableitungen oder Abrechnungsregeln. Diese bleiben über die WD-ABAP-Schicht in der Regel nutzbar.

UI- und OData-Erweiterungen: Anpassungen, die an den bisherigen Web-Dynpro- oder V2-Fiori-Apps hängen. Sie müssen beim Wechsel auf V4 über die neuen Enhancement Spots neu aufgesetzt werden.

Zusatzfelder und Datenstrukturen: kundeneigene Felder in Reiseantrag und -abrechnung, die künftig in der RAP-Architektur abgebildet werden müssen.

Tabelle PTK99. Ihre Nutzung wird nicht unterstützt. Wer alte Daten im Cluster zur Struktur PTK99 verwaltet, muss das Mapping auf die neuen Strukturen selbst über das Extensibility-Konzept abbilden (SAP Hinweis 3296253 und 3260453).

Weitere Stolpersteine:

Kostenzuordnung: In den V4-Apps lässt sich bei 100 % Zuordnung kein neuer Eintrag anlegen. Zuerst muss der bestehende Prozentsatz reduziert werden. Das gehört in Schulung und Prozessbeschreibung.

Anlagen: Die Verwaltung läuft über HDM. Die ArchiveLink-Anbindung war laut Hinweis 3617075 mit 2025 FPS0 noch nicht verfügbar und soll per Hinweis nachgeliefert werden. Wer Belege im optischen Archiv ablegt, sollte den Stand früh klären, auch zu Hinweis 3650430.

Öffentlicher Dienst: Trennungsgeld und Umzugskosten gibt es nur in SAP-GUI-Transaktionen. Die Public-Sector-Version wird in den Fiori-Apps im Allgemeinen nicht unterstützt, Sonderfelder müssen per Erweiterung ergänzt werden.

Mehrfachbeschäftigung: Concurrent Employment ist bisher nur in der Reiseantrags-App umgesetzt. In den Spesen-Apps folgt es mit deren V4-Version.

Zugang und Betrieb: NWBC for HTML wird nicht mehr unterstützt (Hinweis 3446972). Der Zugang läuft über das Fiori Launchpad mit Anwendungskatalogen, OData-Services und Rollen. Weil die Apps Uploads erlauben, empfiehlt SAP einen Virenscanner mit restriktiven Scan-Profilen.

Buchungssysteme: Wer die Reiseplanung mit einem Drittanbieter nutzt, sollte dessen Fortbestand mit dem Anbieter klären (siehe Abschnitt 4).

Vorbereitung

Was Unternehmen vor der Migration prüfen sollten

Aus unserer Sicht sollten Unternehmen SAP Travel Management deshalb als eigenen Workstream innerhalb der S/4HANA-Transformation behandeln. Dabei sind insbesondere folgende Fragen zu beantworten:

Welche Travel-Prozesse und Anwendungen werden heute tatsächlich genutzt?

Wie ist Travel Management mit HR, Payroll, FI, CO und Drittsystemen integriert?

Welche historischen Reise-, Beleg- und Archivdaten müssen vollständig übernommen werden?

Welche eingesetzten Apps und Transaktionen sind mittlerweile deprecated oder obsolete?

Welche kundeneigenen User Exits, BAdIs, OData-Erweiterungen, UI-Anpassungen und Datenstrukturen existieren?

Welche Erweiterungen lassen sich weiterverwenden und welche müssen auf die neuen Fiori-/RAP-Mechanismen angepasst werden?

Welche Rolle soll das klassische Travel Planning zukünftig spielen?

Ist SAP Travel Management for SAP S/4HANA das längerfristige Ziel oder ein Baustein auf dem Weg zu einer anderen Travel-&-Expense-Architektur?

Wer diese Fragen vor der Conversion beantwortet, reduziert das Risiko, dass scheinbar kleine Travel-Themen erst spät im Projekt zu unerwarteten Aufwänden führen.

Häufige Fragen

FAQ: SAP Travel Management in S/4HANA 2025

Ist SAP Travel Management eine Sackgasse, oder wird es langfristig weiterentwickelt?

Technisch ist es keine Sackgasse: SAP Travel Management for SAP S/4HANA ist seit Oktober 2022 verfügbar und folgt der S/4HANA-Wartungsstrategie bis 2040. SAP empfiehlt Bestandskunden sogar ausdrücklich, auf die aktuelle Version S/4HANA 2025 zu wechseln. Strategisch investiert SAP aber nicht mehr in neue Funktionen: Der funktionale Umfang bleibt am Compatibility Scope auf Basis ECC 6.0 EHP8 orientiert, Erweiterungen gibt es nur selektiv, etwa für den öffentlichen Dienst Deutschland. Die eigentliche Innovationslinie für Travel & Expense ist SAP Concur. Travel Management ist damit gepflegter, aber funktional weitgehend eingefrorener Bestandsschutz. Also keine Sackgasse, aber auch kein Zukunftsprodukt.

Muss ich mein bestehendes Travel-Customizing bei der Migration neu aufbauen?

Nein. SAP bestätigt ausdrücklich, dass für die neuen Fiori-Apps kein neues fachliches Customizing nötig ist. Die bisherige Konfiguration aus den V2-, V3- und WebDynpro-Anwendungen wird weiterverwendet. Auch Datenbanktabellen, Berechtigungskonzept, IMG, Business-Objekt-Definitionen, Programme und Transaktionen bleiben laut SAP-Migrationsleitfaden unverändert. Einzige technische Neuerung: Die Genehmigung läuft in den neuen Apps über einen neuen OData-Service für My Inbox, ist fachlich aber auf derselben Konfiguration aufgesetzt.

Was passiert mit kundeneigenen Erweiterungen (BAdIs, Enhancement Spots), wenn ich auf die neuen Fiori-Apps wechsle?

Das hängt von der Erweiterungsebene ab. Die Enhancement Spots und BAdIs der alten V2-Apps (etwa PAOC_MTR_BADI oder SRA004_BADI_MY_TRAVEL_REQ) lassen sich in den neuen, auf Fiori elements, OData V4 und RAP basierenden V4-Apps nicht weiterverwenden – SAP liefert dafür neue Enhancement Spots sowie RAP-Erweiterungen für Datenmodell, Verhalten und Knoten. Bestehende User-Exits und BAdIs der Web-Dynpro-ABAP-Anwendungen bleiben dagegen für die Backend-Logik nutzbar. SAP weist im Migrationsleitfaden ausdrücklich darauf hin, dass Kunden das Erweiterbarkeitskonzept für jedes Migrationsprojekt selbst prüfen und bewerten müssen.

Welche Lizenz brauche ich für SAP Travel Management auf S/4HANA?

On-premise ändert sich für ECC-Bestandskunden mit klassischen Named Usern nichts: Sie nutzen weiterhin den SAP Employee User. Netto-Neukunden auf S/4HANA lizenzieren seit Oktober 2022 unbegrenzt über SAP S/4HANA Enterprise Management for Productivity Use; zuvor war die Nutzung über die Compatibility-Scope-Komponente bis Ende 2025 befristet. Für die Private Cloud Edition gibt es ein eigenes, zusätzliches Lizenzmaterial, das nach der Zahl der Spesenabrechnungen pro Jahr bepreist wird und zusätzlich zur PCE-Lizenz kommt.

Wie aufwändig ist die technische Migration von ECC nach S/4HANA 2025 für Travel Management wirklich?

Der Kernprozess ist unaufwändig: SAP vergleicht ihn mit einer normalen Release-Installation, weil Architektur, Datenbanktabellen, Customizing und Berechtigungskonzept gleichbleiben. Der eigentliche Aufwand liegt nicht im Standardprozess, sondern in drei Punkten: der Migration von Anlagen, ArchiveLink-Verknüpfungen und BOR-Objekten, der Neubewertung kundeneigener Erweiterungen für die V4-Apps und dem Abgleich der genutzten Transaktionen und Apps mit der Deprecated-/Obsolete-Liste. Wer diese drei Punkte vorab klärt, bewegt sich bei einer reinen System Conversion in der Größenordnung eines Release-Upgrades.

Zusammenfassung

Empfehlung und Fazit

Eine pauschale Empfehlung gibt es nicht. Drei Ausrichtungen sind üblich:

Concur als Ziel passt bei klarer Cloud-Strategie, standardnahen Prozessen und der Bereitschaft, Reiseprozesse anzupassen.

Travel Management als Übergang ist sinnvoll, wenn die Conversion früher ansteht als die Concur-Einführung.

Travel Management als Dauerlösung kommt bei Sonderanforderungen in Frage, etwa Länderversionen, Public-Sector-Regeln oder enger Payroll-Integration, sofern der Erweiterungsaufwand vertretbar ist.

Die drei Ausrichtungen schließen sich nicht gegenseitig aus. In der Praxis ist die Entscheidung selten ein einmaliger Schnitt, sondern ein Zielpfad: Viele Unternehmen betreiben Reiseantrag und -abrechnung zunächst weiter auf Travel Management und verlagern einzelne Ländergesellschaften oder Teilprozesse schrittweise zu Concur.

Ausschlaggebend sind Cloud-Strategie, Individualisierungsgrad, Länder- und Sonderregeln, Zeitplan (auch mit Blick auf FPS2) und Lizenzlage.

Eine kurze Checkliste hilft:

(1) Ist-Aufnahme von Apps, Transaktionen, Erweiterungen und Buchungssystemen,

(2) Abgleich mit deprecated und obsolete,

(3) Entscheidung über das Zielbild,

(4) Wahl von Migrationsweg und Landschaft,

(5) Klärung der Lizenz.

Fazit: SAP Travel Management for SAP S/4HANA bietet Bestandskunden einen Weg, etablierte Reisekostenprozesse mit hoher technischer Kontinuität weiterzuführen. S/4HANA 2025 modernisiert insbesondere die Reiseantrags-Apps. Für eine belastbare Migration müssen Unternehmen dennoch Dokumente und Integrationen, den Status älterer Anwendungen sowie kundeneigene Erweiterungen prüfen. Die klassische Reiseplanung benötigt wegen ihrer Deprecation eine eigene Entscheidung zur Zielarchitektur.

Nächste Schritte

Wir unterstützen Sie mit einer kompakten Bestandsaufnahme: Welche Funktionen, Erweiterungen und Schnittstellen sind im Einsatz, was davon ist betroffen, und welche Optionen bleiben? Sprechen Sie uns an, wir sind gern im Austausch.

Von Wiebke Sandmann, 23. Februar 2026

Dieser Beitrag basiert auf fachlicher Expertise und Praxiserfahrungen aus dem cimt-Umfeld. KI-basierte Werkzeuge wurden unterstützend bei der redaktionellen Ausarbeitung eingesetzt. Die inhaltliche Prüfung und Freigabe liegen bei den Autorinnen und Autoren.

Autorin

Wiebke SandmannSAP Senior Consultant HCM & Entwicklung