Kreditkartenanbieter
PartnerConnect – Integrationslayer für Corporate Travel
Synchronisiert Reisedaten zwischen unterschiedlichen Travel Management Systemen sowie zwischen TMS, ERP- und Finanzsystemen – in beide Richtungen.
Warum „Keep the Core Clean" auch für SAP Concur-Integrationen
entscheidend ist
Integration im Zielsystem vs. Integration über vorgelagerte Integrationsschicht
Integration im Zielsystem
Individuelle Logik wird direkt im Zielsystem umgesetzt (z. B. SAP Concur)
Externe Datenquellen:
Individuelle Felder
Workflows
Validierungen
Reports
Integration über vorgelagerte Integrationsschicht
PartnerConnect verarbeitet Integrationslogik, bevor Daten das Zielsystem erreichen
Externe Datenquellen:
Transformation
Validierung
Strukturierung
Routing
PartnerConnect hält die Integrationslogik außerhalb des Zielsystems. Änderungen werden in der Integrationsschicht umgesetzt, bevor Daten
SAP Concur oder andere Systeme erreichen.
Wo die Integrationslogik liegt, entscheidet über Stabilität,
Wartungsaufwand und Update-Fähigkeit.
Warum Integrationen im System zum Problem werden
Das Problem entsteht im Betrieb: Änderungen kommen selten aus dem System selbst, sondern aus den Datenquellen – etwa wenn Kreditkartenanbieter Formate ändern oder sich steuerliche Anforderungen anpassen. Systeminterne Logik geht von stabilen Eingaben aus. Die Realität ist das Gegenteil – Datenformate verändern sich permanent. Die Folge: Anpassungen, fehlerhafte Verarbeitung oder manuelle Nacharbeit. In Unternehmen mit mehreren Concur-Instanzen passiert das nicht einmal, sondern parallel über mehrere Länder und Systeme hinweg.
Wie PartnerConnect als vorgelagerte Integrationsschicht das Problem löst
PartnerConnect setzt davor an. Die Integrationslogik liegt außerhalb des Systems. Daten werden vor der Übergabe strukturiert und validiert. Änderungen werden einmal umgesetzt und gelten sofort für alle angebundenen Concur-Instanzen eines Unternehmens.
Weitere Details zur Architektur
Warum das Problem systemübergreifend ist
Diese Logik ist nicht auf SAP Concur beschränkt. Sie betrifft alle Systeme, in denen Integrationslogik direkt implementiert wird. Änderungen wirken dort immer lokal und müssen systemseitig nachgezogen werden.
Was „Keep the Core Clean“ in der Praxis bedeutet
Genau hier greift „Keep the Core Clean“: Liegt die Integrationslogik außerhalb, bleibt das Zielsystem stabil. Änderungen betreffen die Integrationsschicht – nicht das System selbst.
Warum internationale Setups den Aufwand vervielfachen
In der Praxis zeigt sich das besonders bei internationalen Setups: Unternehmen betreiben oft mehrere Concur-Tenants. Änderungen an externen Datenformaten – etwa neue Mehrwertsteuersätze oder lokale Steuerregeln – müssen in jedem Tenant einzeln umgesetzt werden. Der Aufwand entsteht wiederholt und kumuliert über alle Instanzen.
Wie PartnerConnect Anpassungen zentralisiert
PartnerConnect zentralisiert diese Logik. Anpassungen erfolgen einmal und wirken sofort für alle angebundenen Systeme eines Unternehmens. Das reduziert Wiederholungsaufwand und verhindert inkonsistente Konfigurationen. Zusätzlich lassen sich systembedingte Grenzen umgehen. Wenn Daten nicht vollständig über Concur verarbeitet werden können, werden sie direkt in nachgelagerte Systeme wie SAP FI überführt und dort konsistent weiterverarbeitet oder für weitere Prozesse bereitgestellt.
Warum die Architektur langfristig stabil bleibt
Diese Architektur bleibt auch dann stabil, wenn sich Systeme weiterentwickeln. SAP Concur hat sich in den letzten Jahren deutlich verändert – etwa bei Authentifizierung, Datenflüssen oder Benutzeroberflächen. Diese Entwicklung wird sich fortsetzen. Da PartnerConnect vor dem System arbeitet, bleibt die Integrationslogik davon weitgehend unberührt. Angepasst wird nur die Schnittstelle – nicht die gesamte Architektur. Diese Vorgehensweise entspricht der Architektur moderner SAP-Systemlandschaften. Erweiterungen werden außerhalb der Kernsysteme umgesetzt – etwa über die SAP Business Technology Platform oder die KI-Schicht Joule. HighPots ist sowohl für SAP BTP als auch für SAP Joule zertifiziert und entwickelt PartnerConnect entlang dieser Prinzipien.
Warum sich die Ansätze wirtschaftlich unterscheiden
Im Markt sind beide Ansätze anzutreffen, aber ungleich verteilt. Systeminterne Integration ist die Norm. Systemexterne Integration ist die Ausnahme – bietet aber entscheidende Vorteile: geringerer Anpassungsaufwand, höhere Stabilität und eine saubere Grundlage für automatisierte und KI-gestützte Prozesse.
Travel-Daten fließen nicht von allein zwischen den Systemen
In einem Corporate-Travel-Prozess entstehen Daten an
unterschiedlichen Stellen.
Reiseprovider
Liefern Buchungen und Rechnungen in unterschiedlichen Formaten und Strukturen.
Travel-Management-Systeme (TMS)
Konsolidieren Daten, erwarten jedoch standardisierte und vollständige Informationen.
ERP-Systeme
Führen Daten aus TMS, Reiseprovidern und Payment-Systemen (z. B. Kreditkartenanbieter) zusammen – oft mit abweichender Struktur und Logik.
Finanzbuchhaltung
Benötigt konsistente, korrekt zugeordnete Daten für Abschluss und Reporting.
Diese Systeme sind auf ihre jeweilige Funktion optimiert, nicht auf durchgängige Zusammenarbeit. Daten werden unterschiedlich strukturiert, angereichert und zeitlich versetzt verarbeitet. Mit jeder zusätzlichen Niederlassung, jedem neuen Provider und jeder weiteren regulatorischen Anforderung steigt die Komplexität der Datenflüsse.
Zwischen Datenquelle und Zielsystem entsteht eine Integrationslücke. Typische Folgen sind:
Daten müssen systemübergreifend im richtigen Format, mit der richtigen Struktur und zum richtigen Zeitpunkt vorliegen.
Die operative Anforderung bleibt konstant: Daten müssen systemübergreifend im richtigen Format, mit der richtigen Struktur und
zum richtigen Zeitpunkt vorliegen.
PartnerConnect: neutraler Integrationslayer für das Corporate-Travel-Ökosystem
PartnerConnect verbindet Travel-Datenquellen mit den Zielsystemen des Corporate-Travel-Ökosystems. Daten entstehen bei Reiseprovidern,
in Unternehmen (etwa bei direkt gebuchten Reisen oder nachgereichten Belegen) und – in bestimmten Konstellationen – auch in TMS-Systemen selbst.
Zielsysteme sind TMS, ERP, Finanzbuchhaltung und Spesen-Management.
Adapter-Framework
Die Plattform ist als Adapter-Framework aufgebaut. Datenquellen und Zielsysteme werden über definierte Adapter angebunden und bleiben austauschbar. Neue Integrationen entstehen durch Ergänzung weiterer Adapter, nicht durch Neubau der Plattform. Der Integrationsaufwand bleibt dadurch kalkulierbar, auch bei wachsender Systemlandschaft.
Bidirektionale Architektur
PartnerConnect ist bidirektional ausgelegt. Daten fließen von Datenquellen in Zielsysteme – etwa von Reiseprovidern und Unternehmen in TMS und ERP. Gleichzeitig werden aggregierte und analytische Daten aus Zielsystemen über denselben Integrationspfad zurückgeführt. Diese Rückflüsse sind Teil der Plattform-Architektur und ermöglichen eine systemübergreifende Auswertung entlang der bestehenden Datenflüsse.
Neutralität
Neutralität ist strukturell verankert. PartnerConnect bindet sich weder an einzelne TMS-Anbieter noch an spezifische ERP-Systeme oder Reiseprovider-Typen. Produktive Integrationen bestehen in SAP Concur und Cytric von Amadeus; weitere Integrationen entstehen projektspezifisch. Die Plattform eignet sich für Konstellationen mit einem oder mehreren Zielsystemen parallel, etwa in international gewachsenen Konzernstrukturen.
Produktiv im Einsatz
Die Plattform ist produktiv im Einsatz und kein experimentelles System. Integrationen in SAP Concur sind zertifiziert.
Regulatorische Anforderungen sind Teil des Datenflusses –
nicht ein nachgelagerter Schritt
Data sources
GDPR / revDSG
AI Act
CSRD
Invoice Formats
Integration layer
(inkl. regulatorischer Logik)
Target systems (simplified)
Ohne regulatorische Einordnung entstehen in integrierten Systemlandschaften neue Brüche – etwa bei Datenschutz, Rechnungsformaten oder Reportingpflichten. Datenschutz bei personenbezogenen Reiseprofilen, länderspezifische Rechnungsformate, Berichtspflichten zu Emissionen aus Geschäftsreisen und die Einordnung eingesetzter KI-Komponenten betreffen dieselben Datenflüsse, die technisch integriert werden. PartnerConnect behandelt regulatorische Einordnung deshalb nicht als separate Leistung, sondern als integralen Bestandteil der Integrationsplanung.
Die wichtigsten regulatorischen Rahmen im Kontext von PartnerConnect sind:
Rahmen
Relevanz im Travel-Integrations-Kontext
EU DSGVO / revDSG Schweiz
Fehlende oder falsche Zuordnung personenbezogener Daten in systemübergreifenden Prozessen
EU AI Act
Unklare Einordnung eingesetzter KI-Komponenten im Datenfluss
EU CSRD
Unvollständige oder inkonsistente Datenbasis für Emissions- und Reportingpflichten
Länderspezifische Rechnungsformate
Inkompatible Datenformate zwischen Systemen aufgrund nationaler Vorgaben
Zwischen regulatorischer Analyse und technischer Umsetzung entsteht in der Praxis häufig eine Lücke. Beratungsgesellschaften liefern Methodik und Einordnung, realisieren aber nicht. Reine Integrationsdienstleister realisieren, ohne regulatorische Einordnung mitzuführen. HighPots arbeitet in dieser Schnittstelle: regulatorische Einordnung und technische Realisierung aus einer Hand, in einem Kostenrahmen, der für Mittelstand und mittelgroße Konzerne tragfähig ist.
Konkret bedeutet das: Integrationen werden DSGVO-konform aufgesetzt, Rechnungsformate folgen den jeweils aktuellen nationalen Vorgaben, und KI-Komponenten werden entlang der Anforderungen des EU AI Act eingeordnet. PartnerConnect ersetzt keine rechtliche Beratung. Die Bewertung im Einzelfall bleibt bei internen Rechtsabteilungen oder externen Beratern – die technische Umsetzung greift diese Einordnung auf.
Anwendungsfelder im produktiven Einsatz
In der Praxis treten Integrationsprobleme in wiederkehrenden Mustern auf.
Die folgenden Anwendungsfelder zeigen typische Situationen aus dem produktiven Einsatz. Sie unterscheiden sich in den beteiligten Systemen, in der Datenrichtung und in der Struktur der Integration zwischen den beteiligten Parteien. Die folgenden Abschnitte beschreiben für jedes Feld die Ausgangslage, die konkrete Leistung und belegbare Referenzen aus dem produktiven Einsatz.
Reiseprovider → TMS
Mehrere TMS-Systeme (Konzernstrukturen)
Rechnungsformate und Fakturierung
Integration aus Unternehmenssicht
ESG- und Datenanreicherung
Reiseprovider-Integration in TMS-Landschaften
Reiseprovider müssen Buchungen, Rechnungen und Belege strukturiert in die TMS-Systeme ihrer Firmenkunden übertragen. Unterschiedliche Datenformate, unvollständige Informationen und abweichende Prozesse führen dabei regelmäßig zu manueller Nachbearbeitung und Integrationsproblemen. Gleichzeitig entstehen Daten in unterschiedlichen Systemkontexten und sind oft nicht auf die Anforderungen der Zielsysteme abgestimmt.
PartnerConnect bedient dieses Feld in zwei Modi. Bei Providern mit hohem Buchungsvolumen zum TMS erfolgt die Anbindung als OBE-Integration (Online Booking Engine), bei der Buchungsfunktionen direkt im TMS-Kontext bereitgestellt werden. Unterhalb dieser Volumenschwelle arbeitet die Punch-Out-Integration: Nutzer buchen auf der Provider-Website, die Daten fließen anschließend über PartnerConnect zurück ins TMS. Beide Modi liefern vollständige Datenintegration für Reporting und Abrechnung. Für Rechnungs- und Belegflüsse gilt die Volumenschwelle nicht; sie werden unabhängig davon übertragen.
Dieses Anwendungsfeld ist die historisch etablierte Kernanwendung. Mehr als 2 Millionen Hoteltransaktionen wurden darüber produktiv abgewickelt. Produktive Integrationen bestehen in den Kategorien Hotel, Flug, Bahn, Mietwagen und Mobilitätsdienste. Die Bahn-Integration ist auf Kundenbedarf aktivierbar. Sie bedient insbesondere Multi-Sitz-Konzerne, für die standardisierte Rail-Integrationen strukturell nicht ausreichen.
Spezialisierte Reiseprovider außerhalb des TMS integrieren"
Internationale Konzerne betreiben häufig mehrere TMS-Systeme parallel. Die Gründe sind historisch gewachsen, regional bedingt oder regulatorisch motiviert – etwa wenn ein übernommenes Unternehmen sein bestehendes TMS beibehält oder einzelne Ländergesellschaften eigene Systeme einsetzen. Konsolidiertes Reporting, durchgängige Reisekostenabrechnung und Reconciliation über Systemgrenzen hinweg werden dadurch strukturell erschwert.
PartnerConnect ermöglicht die Übertragung von Daten zwischen TMS-Systemen in kundengesteuerten Konstellationen. Der Endkunde aktiviert die Integration in seinem Ziel-TMS – etwa über das SAP Concur App Center – und definiert damit den Datenfluss aus einem weiteren TMS wie Cytric. PartnerConnect arbeitet dabei als neutraler Integrationslayer; die Datenflüsse entstehen durch Entscheidungen des Endkunden, nicht durch direkte Abstimmung zwischen TMS-Anbietern. Ein produktiver Referenzfall besteht in einem internationalen Konzern, in dem Rechnungsdaten aus Cytric in SAP Concur verfügbar gemacht werden.
Parallel zur TMS-übergreifenden Integration adressiert dieses Feld die Reconciliation zwischen TMS und ERP, insbesondere in SAP-Umgebungen. Dazu gehört der Abgleich zwischen Kreditkarten-Feeds und Belegen. Standardmechanismen innerhalb von TMS-Systemen – etwa SmartMatching in SAP Concur – decken den Regelfall ab. In komplexen Konzernkonstellationen, etwa bei mehreren Kreditkarten-Providern, gemischten Währungen oder heterogenen Buchungskreisen, entstehen zusätzliche Abstimmungsanforderungen. PartnerConnect ergänzt diese Szenarien durch alternative Reconciliation-Pfade, beispielsweise durch direkte Übergabe strukturierter Belegdaten an SAP FI oder durch vorgelagerte Datenaufbereitung.
Enterprise-getriebene Nischen-Provider-Integration
Internationale Konzerne betreiben häufig mehrere TMS-Systeme parallel. Die Gründe sind historisch gewachsen, regional bedingt oder regulatorisch motiviert – etwa wenn ein übernommenes Unternehmen sein bestehendes TMS beibehält oder einzelne Ländergesellschaften eigene Systeme einsetzen. Konsolidiertes Reporting, durchgängige Reisekostenabrechnung und Reconciliation über Systemgrenzen hinweg werden dadurch strukturell erschwert.
PartnerConnect ermöglicht die Übertragung von Daten zwischen TMS-Systemen in kundengesteuerten Konstellationen. Der Endkunde aktiviert die Integration in seinem Ziel-TMS – etwa über das SAP Concur App Center – und definiert damit den Datenfluss aus einem weiteren TMS wie Cytric. PartnerConnect arbeitet dabei als neutraler Integrationslayer; die Datenflüsse entstehen durch Entscheidungen des Endkunden, nicht durch direkte Abstimmung zwischen TMS-Anbietern. Ein produktiver Referenzfall besteht in einem internationalen Konzern, in dem Rechnungsdaten aus Cytric in SAP Concur verfügbar gemacht werden.
Parallel zur TMS-übergreifenden Integration adressiert dieses Feld die Reconciliation zwischen TMS und ERP, insbesondere in SAP-Umgebungen. Dazu gehört der Abgleich zwischen Kreditkarten-Feeds und Belegen. Standardmechanismen innerhalb von TMS-Systemen – etwa SmartMatching in SAP Concur – decken den Regelfall ab. In komplexen Konzernkonstellationen, etwa bei mehreren Kreditkarten-Providern, gemischten Währungen oder heterogenen Buchungskreisen, entstehen zusätzliche Abstimmungsanforderungen. PartnerConnect ergänzt diese Szenarien durch alternative Reconciliation-Pfade, beispielsweise durch direkte Übergabe strukturierter Belegdaten an SAP FI oder durch vorgelagerte Datenaufbereitung.
Zwei KI-Produkte, die auf den transportierten Daten operieren
Reisedaten
AI systems
TravelPolicyNavigatorAI
Bewertet strukturierte Datenobjekte
AnyAgent
Bedient Prozesse
Reporting, Compliance und Analyse
Auswertungen auf Basis integrierter Travel-Daten
Auf den Daten, die PartnerConnect transportiert, operieren zwei ergänzende KI-Systeme mit klar getrennter Funktion: TravelPolicyNavigatorAI bewertet Daten, AnyAgent bedient Prozesse. Beide werden on-premises betrieben – Modelle und Datenverarbeitung finden innerhalb der Kundenumgebung statt. Damit können Anforderungen adressiert werden, in denen Travel-Daten nicht in externe Cloud-Dienste ausgelagert werden sollen. Beide Systeme sind eigenständige HighPots-Produkte und werden hier im Travel-Kontext dargestellt.
TravelPolicyNavigatorAI
Bewertet strukturierte Datenobjekte
Prüft Richtlinien und Compliance
TravelPolicyNavigatorAI ist ein eigenständiges HighPots-Produkt und ein On-Premises-KI-System, das unmittelbar auf den von PartnerConnect transportierten Travel-Daten arbeitet. Es bewertet Buchungen, Rechnungen und Belege gegen definierte Richtlinien und spielt Ergebnisse an die zuständigen Rollen im Unternehmen zurück – etwa Travel Management, Accounting oder Audit. Das System bedient keine Software, sondern analysiert strukturierte Daten.
Drei Funktionen decken unterschiedliche Phasen des Travel-Management-Zyklus ab:
Das System ist produktreif und wird derzeit primär intern eingesetzt, mit Fokus auf kontinuierlicher Verbesserung. Die externe Nutzung im Rahmen von PartnerConnect-Projekten wird schrittweise aufgebaut.
AnyAgent im Travel-Kontext
Führt Systemhandlungen aus
Verbindet Systeme ohne Schnittstellen
AnyAgent ist ein eigenständiges HighPots-Produkt mit Anwendungen über den Travel-Kontext hinaus. Im Travel-Kontext wird es dort eingesetzt, wo Zielsysteme keine geeigneten Schnittstellen bereitstellen oder deren Integration wirtschaftlich nicht sinnvoll ist.
AnyAgent ersetzt nicht nur fehlende Schnittstellen, sondern führt auch die erforderlichen Systemhandlungen selbst aus – so, wie sie sonst durch Nutzer in den jeweiligen Anwendungen durchgeführt würden. Das System arbeitet über bestehende Benutzeroberflächen und ist nicht auf Browser-Anwendungen beschränkt – es kann beliebige Desktop-Systeme bedienen.
Definierte Prozessschritte werden vollständig automatisiert ausgeführt, einschließlich Dateneingabe, Prüfung und Übertragung zwischen Systemen.
Zwei Anwendungsfälle sind im Travel-Kontext relevant:
Die funktionale Abgrenzung zu TravelPolicyNavigatorAI bleibt klar: PolicyNavigator bewertet strukturierte Datenobjekte, AnyAgent führt Systemhandlungen aus. Beide können im selben Projekt eingesetzt werden.
ESG-bezogene Datenanreicherung im Travel-Kontext
ON-PREMISES (Customer Environment)
TravelPolicyNavigatorAI
Analyse-System
Bewertung strukturierter Daten
Analyzes travel data
Reporting, Compliance und Analyse
Auswertungen auf Basis integrierter Travel-Daten
Ausführung von Systemhandlungen
Operates software interfaces
ESG-Auswertung und Reporting
Produktiver Einsatz und Zertifizierungen
Die folgenden Referenzpunkte basieren auf produktiven Einsätzen von PartnerConnect. Sie stammen aus laufenden oder
abgeschlossenen Betriebsumgebungen und sind nicht aus Test- oder Pilotkonstellationen abgeleitet.
Die folgenden Kennzahlen zeigen reale Volumina, nicht theoretische Kapazitäten.
2Mio.+
Hoteltransaktionen
im produktiven Betrieb
10M+
Plausibilitätsprüfungen
Travel-Daten
6 Monate
Stabiler Produktivbetrieb
Mietwagen-Integration
Zertifiziert
SAP Concur Integration
laufend gepflegt
Klärung Ihrer konkreten Integrationssituation
Ob und wie eine Integration sinnvoll ist, hängt immer von Ihrer konkreten Systemlandschaft ab: bestehende TMS-Systeme, Datenflüsse, regulatorische Anforderungen und organisatorische Struktur.
Im ersten Gespräch klären wir, ob und wie PartnerConnect in Ihrer Konstellation sinnvoll eingesetzt werden kann – und wo typische Integrationsgrenzen liegen.