Credit card provider
PartnerConnect – Integration layer for Corporate Travel
Synchronizes travel data between different Travel Management Systems as well as between TMS, ERP, and financial systems – in both directions.
Why "Keep the Core Clean" is also crucial for SAP Concur integrations
Integration in the target system vs. integration via upstream integration layer
Integration in the target system
Individual logic is implemented directly in the target system (e.g. SAP Concur)
External data sources:
Individual fields
Workflows
Validations
Reports
Integration via upstream integration layer
PartnerConnect processes integration logic before data reaches the target system
External data sources:
Transformation
Validation
Structuring
Routing
PartnerConnect keeps the integration logic outside the target system. Changes are implemented in the integration layer before data
reach SAP Concur or other systems.
Where the integration logic lies determines stability,
maintenance effort, and update capability.
Why integrations in the system become a problem
The problem arises in operation: changes rarely come from the system itself, but from the data sources – for example, when credit card providers change formats or tax requirements are adjusted. Internal system logic assumes stable inputs. The reality is the opposite – data formats are constantly changing. The consequence: adjustments, faulty processing, or manual rework. In companies with multiple Concur instances, this doesn’t happen just once, but in parallel across several countries and systems.
How PartnerConnect solves the problem as an upstream integration layer
PartnerConnect addresses this beforehand. The integration logic lies outside the system. Data is structured and validated before transfer. Changes are implemented once and apply immediately to all connected Concur instances of a company.
Further details about the architecture
Why the problem is cross-system
This logic is not limited to SAP Concur. It affects all systems in which integration logic is implemented directly. Changes always have a local effect there and must be adjusted on the system side.
What “Keep the Core Clean” means in practice
This is exactly where “Keep the Core Clean” applies: If the integration logic is external, the target system remains stable. Changes affect the integration layer—not the system itself.
Why international setups multiply the effort
In practice, this is particularly evident with international setups: companies often operate multiple Concur tenants. Changes to external data formats – such as new VAT rates or local tax rules – must be implemented separately in each tenant. The effort is repeated and accumulates across all instances.
How PartnerConnect Centralizes Customizations
PartnerConnect centralizes this logic. Adjustments are made once and take effect immediately for all connected systems of a company. This reduces repetitive effort and prevents inconsistent configurations. Additionally, system-related limitations can be bypassed. If data cannot be fully processed via Concur, it is transferred directly to downstream systems such as SAP FI and consistently further processed there or made available for other processes.
Why the architecture remains stable in the long term
This architecture remains stable even as systems evolve. SAP Concur has changed significantly in recent years – for example in authentication, data flows, or user interfaces. This development will continue. Since PartnerConnect operates in front of the system, the integration logic is largely unaffected. Only the interface is adjusted – not the entire architecture. This approach corresponds to the architecture of modern SAP system landscapes. Extensions are implemented outside the core systems – for example via the SAP Business Technology Platform or the AI layer Joule. HighPots is certified for both SAP BTP and SAP Joule and develops PartnerConnect according to these principles.
Why the approaches differ economically
Both approaches can be found on the market, but they are unevenly distributed. Internal system integration is the norm. External system integration is the exception – but it offers decisive advantages: less adjustment effort, higher stability, and a clean basis for automated and AI-supported processes.
Travel data does not flow automatically between the systems
In a corporate travel process, data is generated at
different points.
Travel provider
Deliver bookings and invoices in different formats and structures.
Travel Management Systems (TMS)
Consolidate data, but expect standardized and complete information.
ERP systems
Combine data from TMS, travel providers, and payment systems (e.g., credit card providers) – often with differing structure and logic.
Financial accounting
Requires consistent, correctly assigned data for closing and reporting.
These systems are optimized for their respective functions, not for seamless collaboration. Data is structured, enriched, and processed with time delays in different ways. With each additional branch, new provider, and further regulatory requirement, the complexity of data flows increases.
An integration gap arises between the data source and the target system. Typical consequences are:
Data must be available across systems in the correct format, with the correct structure, and at the right time.
The operational requirement remains constant: Data must be available across systems in the correct format, with the correct structure, and at the right time.
PartnerConnect: neutral integration layer for the corporate travel ecosystem
PartnerConnect connects travel data sources with the target systems of the corporate travel ecosystem. Data is generated by travel providers,
in companies (such as directly booked trips or submitted receipts) and – in certain constellations – also in TMS systems themselves.
Target systems are TMS, ERP, financial accounting, and expense management.
Adapter Framework
The platform is built as an adapter framework. Data sources and target systems are connected via defined adapters and remain interchangeable. New integrations arise through the addition of further adapters, not by rebuilding the platform. The integration effort thus remains manageable, even with a growing system landscape.
Bidirectional architecture
PartnerConnect is designed to be bidirectional. Data flows from data sources to target systems, for example from travel providers and companies to TMS and ERP. At the same time, aggregated and analytical data are fed back from the target systems via the same integration path. These return flows are part of the platform architecture and enable cross-system analysis along existing data flows.
Neutrality
Neutrality is structurally anchored. PartnerConnect is not tied to individual TMS providers nor to specific ERP systems or travel provider types. Productive integrations exist in SAP Concur and Cytric by Amadeus; additional integrations are created on a project-specific basis. The platform is suitable for constellations with one or more target systems in parallel, for example in internationally grown corporate structures.
Productive in use
The platform is in productive use and not an experimental system. Integrations with SAP Concur are certified.
Regulatory requirements are part of the data flow –
not a subsequent step
Data sources
GDPR / revDSG
AI Act
CSRD
Invoice Formats
Integration layer
(incl. regulatory logic)
Target systems (simplified)
Without regulatory classification, new gaps arise in integrated system landscapes – for example, in data protection, invoice formats, or reporting obligations. Data protection for personal travel profiles, country-specific invoice formats, reporting obligations for emissions from business travel, and the classification of used AI components all concern the same data flows that are technically integrated. PartnerConnect therefore does not treat regulatory classification as a separate service, but as an integral part of integration planning.
Without regulatory classification, new gaps arise in integrated system landscapes – for example, in data protection, invoice formats, or reporting obligations. Data protection for personal travel profiles, country-specific invoice formats, reporting obligations for emissions from business travel, and the classification of used AI components all concern the same data flows that are technically integrated. PartnerConnect therefore does not treat regulatory classification as a separate service, but as an integral part of integration planning.
Frame
Relevance in the travel integration context
EU GDPR / revDSG Switzerland
Missing or incorrect assignment of personal data in cross-system processes
EU AI Act
Unclear classification of deployed AI components in the data flow
EU CSRD
Incomplete or inconsistent data basis for emission and reporting obligations
Country-specific invoice formats
Incompatible data formats between systems due to national regulations
In practice, a gap often arises between regulatory analysis and technical implementation. Consulting firms provide methodology and classification but do not execute. Pure integration service providers execute without carrying out regulatory classification. HighPots works at this interface: regulatory classification and technical implementation from a single source, within a cost framework that is viable for medium-sized businesses and mid-sized corporations.
Specifically, this means: integrations are set up in compliance with the GDPR, invoice formats follow the current national requirements, and AI components are classified according to the requirements of the EU AI Act. PartnerConnect does not replace legal advice. The assessment in individual cases remains with internal legal departments or external consultants – the technical implementation takes this classification into account.
Application fields in productive use
In practice, integration problems occur in recurring patterns.
The following application fields show typical situations from productive use. They differ in the systems involved, the direction of data, and the structure of integration between the parties involved. The following sections describe the initial situation, the specific service, and verifiable references from productive use for each field.
Travel provider → TMS
Multiple TMS systems (corporate structures)
Invoice formats and billing
Integration from a business perspective
ESG and data enrichment
Travel provider integration in TMS landscapes
Travel providers must transfer bookings, invoices, and receipts in a structured manner into the TMS systems of their corporate clients. Different data formats, incomplete information, and varying processes regularly lead to manual rework and integration problems. At the same time, data is generated in different system contexts and is often not aligned with the requirements of the target systems.
PartnerConnect serves this field in two modes. For providers with high booking volumes to the TMS, the connection is made as an OBE integration (Online Booking Engine), where booking functions are provided directly in the TMS context. Below this volume threshold, the Punch-Out integration operates: users book on the provider’s website, and the data then flows back into the TMS via PartnerConnect. Both modes provide complete data integration for reporting and billing. The volume threshold does not apply to invoicing and receipt flows; these are transmitted regardless.
This application area is the historically established core application. More than 2 million hotel transactions have been processed productively through it. Productive integrations exist in the categories of hotel, flight, rail, rental car, and mobility services. The rail integration can be activated based on customer needs. It primarily serves multi-seat corporations for which standardized rail integrations are structurally insufficient.
Integrate specialized travel providers outside the TMS
International corporations often operate multiple TMS systems in parallel. The reasons are historically grown, regionally conditioned, or regulatory motivated – for example, when an acquired company retains its existing TMS or individual country subsidiaries use their own systems. Consolidated reporting, seamless travel expense accounting, and reconciliation across system boundaries are structurally made more difficult as a result.
PartnerConnect enables the transfer of data between TMS systems in customer-driven constellations. The end customer activates the integration in their target TMS – for example, via the SAP Concur App Center – thereby defining the data flow from another TMS such as Cytric. PartnerConnect acts as a neutral integration layer; the data flows result from the end customer’s decisions, not from direct coordination between TMS providers. A productive reference case exists in an international corporation where invoice data from Cytric is made available in SAP Concur.
Parallel to the cross-TMS integration, this field addresses the reconciliation between TMS and ERP, particularly in SAP environments. This includes the matching of credit card feeds and receipts. Standard mechanisms within TMS systems – such as SmartMatching in SAP Concur – cover the normal case. In complex corporate structures, for example with multiple credit card providers, mixed currencies, or heterogeneous booking areas, additional reconciliation requirements arise. PartnerConnect complements these scenarios with alternative reconciliation paths, for example through direct transfer of structured receipt data to SAP FI or through upstream data preparation.
Enterprise-driven niche provider integration
International corporations often operate multiple TMS systems in parallel. The reasons are historically grown, regionally conditioned, or regulatory motivated – for example, when an acquired company retains its existing TMS or individual country subsidiaries use their own systems. Consolidated reporting, seamless travel expense accounting, and reconciliation across system boundaries are structurally made more difficult as a result.
PartnerConnect enables the transfer of data between TMS systems in customer-driven constellations. The end customer activates the integration in their target TMS – for example, via the SAP Concur App Center – thereby defining the data flow from another TMS such as Cytric. PartnerConnect acts as a neutral integration layer; the data flows result from the end customer’s decisions, not from direct coordination between TMS providers. A productive reference case exists in an international corporation where invoice data from Cytric is made available in SAP Concur.
Parallel to the cross-TMS integration, this field addresses the reconciliation between TMS and ERP, particularly in SAP environments. This includes the matching of credit card feeds and receipts. Standard mechanisms within TMS systems – such as SmartMatching in SAP Concur – cover the normal case. In complex corporate structures, for example with multiple credit card providers, mixed currencies, or heterogeneous booking areas, additional reconciliation requirements arise. PartnerConnect complements these scenarios with alternative reconciliation paths, for example through direct transfer of structured receipt data to SAP FI or through upstream data preparation.
Two AI products that operate on the transported data
Travel dates
AI systems
TravelPolicyNavigatorAI
Evaluated structured data objects
AnyAgent
Operates processes
Reporting, compliance and analysis
Evaluations based on integrated travel data
Two complementary AI systems with clearly separated functions operate on the data transported by PartnerConnect: TravelPolicyNavigatorAI evaluates data, AnyAgent handles processes. Both are operated on-premises – models and data processing take place within the customer environment. This allows addressing requirements where travel data should not be outsourced to external cloud services. Both systems are independent HighPots products and are presented here in the travel context.
TravelPolicyNavigatorAI
Evaluated structured data objects
Checks policies and compliance
TravelPolicyNavigatorAI is a standalone HighPots product and an on-premises AI system that works directly on the travel data transported by PartnerConnect. It evaluates bookings, invoices, and receipts against defined policies and delivers results back to the responsible roles within the company – such as Travel Management, Accounting, or Audit. The system does not serve software but analyzes structured data.
Three functions cover different phases of the travel management cycle:
The system is production-ready and is currently primarily used internally, with a focus on continuous improvement. External use within the framework of PartnerConnect projects is being gradually developed.
AnyAgent in the travel context
Performs system actions
Connects systems without interfaces
Connects systems without interfaces
AnyAgent not only replaces missing interfaces but also performs the required system actions itself – just as they would otherwise be carried out by users in the respective applications. The system works via existing user interfaces and is not limited to browser applications – it can operate any desktop systems.
Defined process steps are fully automated, including data entry, verification, and transfer between systems.
Two use cases are relevant in the travel context:
The functional distinction from TravelPolicyNavigatorAI remains clear: PolicyNavigator evaluates structured data objects, AnyAgent performs system actions. Both can be used in the same project.
ESG-related data enrichment in the travel context
ON-PREMISES (Customer Environment)
TravelPolicyNavigatorAI
Analysis System
Evaluation of structured data
Analyzes travel data
Reporting, compliance and analysis
Evaluations based on integrated travel data
Execution of system actions
Operates software interfaces
ESG evaluation and reporting
Productive Use and Certifications
The following reference points are based on productive deployments of PartnerConnect. They come from ongoing or
completed operational environments and are not derived from test or pilot configurations.
The following key figures show real volumes, not theoretical capacities.
2Mio.+
Hotel transactions
in productive operation
10M+
Plausibility checks
Travel data
6 months
Stable productive operation
Rental car integration
Certified
SAP Concur Integration
continuously maintained
Clarification of your specific integration situation
Whether and how an integration makes sense always depends on your specific system landscape: existing TMS systems, data flows, regulatory requirements, and organizational structure.
In the initial conversation, we clarify whether and how PartnerConnect can be usefully deployed in your configuration – and where typical integration boundaries lie.