Expand +



A Look at a Project to Integrate Concur and an SAP System

by Darrick Arora, Consultant, SAP FI/CO, Infosys Ltd.

May 17, 2016

Learn how to integrate Concur’s travel management solution, which is now a part of SAP, with your SAP system. See how to replace the conventional travel management (claim management) solution with Concur and the best practices to follow during the implementation.

My client wanted to enhance and transform the company’s travel and expense process, including, leveraging mobile device platforms to capture expenses using smartphones. The number of users was around 18,000. The company was using an old application for travel and expense. It had a customized front-end portal to provide the user interface for expenses.

The previous solution was available only for desktop or laptop users and there was no mobile interface, which in some cases delayed the submission and approval of claims. Employees were not able to access submission, approval, and error reports.

The client conducted a study of commercially available solutions and decided to replace the system with Concur to provide a travel and expenses solution via a software-as-a-service (SaaS) model. Concur, which is now an SAP company, provides integrated travel and expense management solutions via a cloud-based service that updates and upgrades automatically. It provides a suite of tools on the web for employees, including use of a smartphone or a tablet. Concur offers a desktop as well as a mobile-based application that can book expenses and claims and manage them. It has an in-built approval workflow mechanism and provides a range of reports.

Implementation Options Considered

The most confusing and time-consuming part of the implementation was to formulate the implementation approach. We compared two options during an extensive analysis phase:

  • Use Concur as a front end for booking expenses and claims and use the SAP system as the back end to manage the trips and expenses as well as the accounting tasks
  • Use Concur as a total travel management solution and the SAP system only for accounting

The research required to determine the implementation approach took a great deal of time in the analysis as well as in the implementation phase as the client has highly customized systems. Following is the process outlined for the two options:

  • Expenses created and submitted in Concur
  • Necessary business and financial approvals done in Concur
  • Standard accounting extract (SAE) interfaced. This has all the details regarding the claim created in Concur and it is considered as the master data file from Concur that the SAP system needs to create corresponding trips for Concur expenses. Option 1 has the claim replicated in SAP as a trip through a new custom program. The trip accounting entry is done in the SAP system by using the standard trip posting program. Option 2 has no claim recorded in SAP. No trip data would be recorded in the SAP system; only financial documents would be created in the SAP system through a new program.
  • Employee vendors’ payment and remittance advice sent through the SAP system
  • Expense-paid indicator sent to Concur from the SAP system
Drilling Down to a Particular Option

We compared both the options, mainly based on the parameters shown in Table 1.


in SAP


No claim
in SAP (only


Change in

New user



New user



Change to
existing SAP Business Warehouse

No change


All reports
need to be
modified or
replaced with
Concur reports


Change in
existing SAP reports

No change


No change


Reconciliation issues

Claim data is replicated in
Central Component (ECC), so a reconciliation issue may
exist for
Concur and


Claim is not
replicated in
SAP system,
so no reconciliation needed for trip data


Table 1
A comparison of the two options

Based on the above information, it was difficult to decide on the approach. Now I take you through our subsequent reasoning process. After a few discussions with Concur we learned that Concur defines the expense types such as a relocation expense in a three-level structure as shown in Figure 1.

Figure 1
Expense structure in Concur

That is unlike the SAP system that follows a two-level hierarchy as shown in Figure 2.

Figure 2
Expense structure in the SAP system

Further discussions with Concur revealed that it would not provide the sub-expense types (relocation expense for on-site) in the inbound standard accounting extract to the SAP system. That is one of the most important fields for creating a claim or trip in an SAP system. It only provides the main expense type (relocation expense), which is not of any use in creating trips in an SAP system. In our old system we mapped general ledger (G/L) accounts to sub-expense types, and there was no concept of a main expense type. Therefore, we thought we had no choice but to go with the option to create claims in Concur and not replicate them in the SAP system, which would only be used for accounting purposes. Note that SAP considers this option to be an ideal approach and it has been implemented in most organizations.

However, our system is highly customized, so we followed the other options (replicating the claim in the ECC system). The implementation was almost started when we realized that there were a lot of SAP Business Warehouse (SAP BW) reports that needed to be modified as a part of this option. This issue was the client's main concern, as almost all the reports used standard extractors to fetch the data, and changing standard extractors is risky as well as quite complex. There were other minor issues pertaining to taxes that were blocking our way to proceed with this option.

(Note: Determining the taxes or the tax code is in ECC is done according to the G/L account and sub-expense type. As mentioned, we were not getting the sub-expense type, so we were not able to derive the tax code for value-added tax (VAT) calculations.)

Therefore, we decided to go back to Concur to suggest a new logic to allow us to get the sub-expense types in some other way that did not affect standard Concur functionality.

The Plan

A separate set of expense types was created in the SAP system for the Concur expenses. Concur sends the main expense type description and sub-expense type description, which Concur can add in the main expense type as a drill-down option. (It is a free text that does not affect the Concur functionality in any way.)

Next, we needed to determine the SAP expense type based on the above two fields (main expense type description and sub-expense type description). A new mapping table had to be created for mapping the main expense type description and sub-expense type description with the corresponding ECC expense type created. Table 2 shows the change in Concur.

Main expense

Sub-expense type
description as a

Relocation expense


Relocation expense
for on-site

Relocation expense
for off-shore

Table 2
Sample of the expense structure in Concur

We created a mapping table in the SAP system as shown in Table 3.









Relocation expense
to on-site





Relocation expense
to off-shore


Table 3
Sample of expense structure in ECC

After the discussion, Concur agreed to send the description for both main expense and sub-expense types, with which we would be able to derive the sub-expense type code (such as RE01 and RE02) that can be used to create a trip or claim in the SAP system.

(Note: Concur has its own set of G/L accounts. We ignored this field in the SAE. Based on the mapping table (Table 3) in the SAP system, we derived the accounts for posting the accounting document.)

Option Decided

Now, both options were open for us: create a claim in Concur and replicate the same in the SAP system or create the claim in Concur and create only the accounting document in the SAP system.

However, because of issues with the earlier selected option (claim in Concur and only accounting document in the SAP system) such as the change in all SAP BW reports and taxes, we finally went ahead with the option to integrate Concur with the SAP system by creating claims in Concur and replicating them in the SAP system. The standard process of trip posting and accounting document creation follows.

Implementation Approach

As noted, the design approach chosen was to recreate the expenses created in the Concur application in the SAP system to minimize the impacts on both ECC and SAP BW reporting.

We created six interfaces between Concur and the SAP system as part of this project:

  • Organizational hierarchy export. Organization master data such as line of service and cost center is sent to Concur.
  • Employee export. This interface is used to export employee information to the Concur system from the SAP system, including personal, organization, and communication details.
  • Work Breakdown Structure (WBS) export. WBS details are sent to Concur from the SAP system through this interface.
  • SAE trip import. This has all the details regarding the claim created in Concur, such as trip, accounting, tax, and mileage data. These details are needed to replicate the trips in the SAP system.
  • Payment export. Payment details are sent to Concur from the SAP system through this interface to mark the claim in Concur as paid once payment is made in the SAP system.
  • One-time data transfer during cut-over: employee data, WBS data, and organizational hierarchy data.

In addition to creating the above six interfaces, we also completed design changes in the customized front-end portal to retire the create/change expenses functionality for users who are rolled out to Concur. Figure 3 is a high-level integration diagram that explains how the ECC-Concur integration actually happens. List data (WBS) and SAE are real-time interfaces, and payment confirmation, organization hierarchy, and employee data are file-to-file based interfaces.

Figure 3
High-level integration

Here are some salient features of the integration architecture:

Process details of the WBS interface as shown in Figure 3:

  • WBS delta data is sent from ECC to Concur
  • The ECC system initiates a request to send WBS changes to the Concur system through SAP Process Integration (SAP PI) and through the proxy communication method
  • SAP PI makes a call back to Concur to get the WBS element that is needed for either amendment or deletion. The amendment or deletion is handled in the mapping logic in SAP PI.
  • Then the required data is created, updated, or deleted in Concur using the interface
  • SAP PI invokes a Concur API using the OAuth2.0 authentication method and uses the Advancto Representational State Transfer (REST) adapter to consume the Concur RESTful API.

Process details of the SAE interface as shown in Figure 3:

  • Invoices or claims posted in the Concur system are sent to ECC to create claims or trips
  • To extract the SAE file from Concur, different APIs need to be executed. The ECC system initiates the request to start the process in SAP NetWeaver Business Process Management (BPM).
  • In the final BPM step, an extract file is returned as a response and the file is placed in a temporary folder, completing the BPM process.
  • Next you create one more interface, which is a file to RFC, in SAP Process Orchestration (SAP PO). The SAP PO file sender adapter picks up the extract (text file with pipe delimited, a format of text in which the fields of a record are separated by a pipe symbol [|]). It performs the content conversion (converting to XML format) and triggers the RFC structure that was created in the ECC system using an RFC receiver communication channel.
  • The ECC system through SAP PI and RFC communication method consumes the Concur web service API for expense accounting data.
  • Consumption of Concur’s RESTful API is achieved via Advantco’s REST Adapter using the OAuth 2.0 authentication method.

The process details of payment confirmation, organization hierarchy, and employee data interfaces as shown in Figure 3:

  • Employee master data, payment export data, and organizational hierarchy data are sent from ECC to Concur
  • The comma-delimited file (CSV) file containing the data is placed in ECC for SAP PI to pick up
  • SAP PI File adapter (Network File System [NFS] protocol) keeps polling for the file at regular intervals or at a scheduled time on a daily basis
  • Once the file is available from ECC, SAP PI picks up the file and the file is then placed on the file share (folder path) available in Secure Transport, which defines a profile of RTP (Real-Time Transport Protocol), intended to provide encryption, ensure message authentication and integrity, and replay protection to the RTP data in both unicast and multicast applications.
  • The client Secure Transport tool keeps polling the folder location where the files will be placed by SAP PI. Once the files are available, Secure Transport encrypts the file using PGP (Pretty Good Privacy) encryption.

The PGP-encrypted file is then pushed to the Concur file server using secure file transport mechanisms

The Process

Here is an outline of the end-to-end process starting from creating claims in Concur through the settlement of the claim:

  • Employees submit expense claims from Concur. They are approved by the designated approver in Concur. Approvers are based on grade or designation. For instance, a Job Level 4 submitter has an approver at Job Level 5 and above. All expenses approved and processed in Concur are included in SAE from Concur. The pre-SAE validation happens in Concur through web service calls from SAP (such as WBS or cost center blocked for posting). A cost center can be locked for primary postings and WBS can be blocked for expense postings, and in these cases, the employee would not be able to create a claim on either of these two cost objects. The SAP system receives an SAE file from Concur. This file contains the details of the claims submitted and approved in Concur that are eligible for payment.
  • The details from SAE are used to create trips in the SAP system. Processes subsequent to trip creation, trip posting, and accounting document posting happen in the SAP system.
  • In the SAP system the report/claim ID is stored in the reference key at the header level in the accounting document for tracking and reconciliation purposes, and also to differentiate the Concur claims from existing claims when the need arises.
  • The entire detail in SAE is stored in a customized table in the SAP system for reporting and future enhancements, if any. An option is provided to keep the data permanently or to delete the data after the claim is posted in the SAP system.
  • Payment details are sent to Concur from the SAP system to mark the claim in Concur as paid once payment is made in the SAP system
  • The standard accounting extract data is sent from Concur to the SAP system via SAP PI as the middleware

    Best Practices

The analysis and implementation of the project derived the following best practices:

  • For us this was one of the first SaaS solutions to be implemented in the firm, so analysis was carried out in this area as part of the requirement analysis (RA) phase to better understand the options that I explained earlier to complete the implementation
  • In the event that the Concur solution is unavailable for extended periods of time, I advise that the incumbent technical solution (e.g., the conventional travel management solution) be readily available so that it can be switched on in a controlled and timely manner. It is rare for the Concur solution to be unavailable for a lengthy period of time, but just after go-live we have seen few instances in which Concur was not able to send the extract or data to ECC. For this reason we came out with a back-up plan that actually proved to be a success and that was appreciated by the client.
  • Develop a reprocess transaction or program for failed claims in the SAP system that helps to reprocess any claims if there is a failure in the first run due to issues either at Concur or in the SAP system
  • Single Sign-On to access to the Concur solution should be enabled
  • The project members and testing team should have a good understanding of the functionalities of the Concur application (ask for a few training sessions to understand what Concur has to offer). Understanding the Concur application means there is less dependency on the back-office team, which saves time and reduces resource dependency.
  • If possible follow a phased go-live strategy with migrating 10 percent of the users to Concur first, with the rest using the conventional application. After two to three months roll out all the users.

PGP encryption is always preferable. PGP encryption is an industry-recognized standard, and Concur supports the following PGP versions: PGP 5.x and higher, GnuPG v1.06 and higher, and products compliant with the OpenPCG standard.

Things to Remember

The project should be implemented and supported using the following technology stack:

  • SAP ERP – customized ECC 6.0
  • Integration layer – SAP PI 7.31 and SAP PO 7.4 Web and application server platform SAP NetWeaver
  • Security: SiteMinder R12.5 is used for end-user authentication
  • Client mobile device: Apple iPhone or iPad with iOS minimum version 6.x.x (recommended iOS 7.x.x or greater)
  • SAP PO 7.4 (PI plus SAP NetWeaver BPM software is available to implement the integration solution. Although REST support is currently not available as standard, it is achievable with SAP-certified Advantco REST Adapter (version 1.0.22).
  • Authentication via the standard SiteMinder log-in page is used to access the website
  • If the system has nightly BATCH running, then the testing of it should be covered in the regression testing to ensure nothing is affected.


Both options have their individual benefits to offer. However, it is important to keep the long-term roadmap in mind while making the decision.

Option 1 (claim replicated in SAP) may allow you to retain and use a larger portion of SAP functionality and reporting that has been developed, tried, and tested over the years. Since the bulk of the data will be replicated, this option could offer the benefit of being less dependent on external systems.

Option 2 (claim in Concur and only accounting in the SAP system) may allow you to create a single source of truth for the expense and accounting information and take better advantage of the external SaaS system’s capabilities in functionality and reporting. However, the change management in this option will be relatively higher.

Go with option 1 if:

  • The system is highly customized.
  • Standard extractors are used for most of the SAP BW reports.
  • The business is apprehensive of a higher level of change management.

Go with option 2 if:

  • Most of the processes/functionalities are in standard SAP with very few customizations.
  • You have SAP S/4HANA implemented as this does not need a separate SAP BW instance for reporting. All the analytics and business intelligence are embedded in the SAP system so there is no major effect in reporting apart from minor changes.
  • The business is ready to accept and comfortable with the change management involved.

An email has been sent to:


Darrick Arora

Darrick Arora is a consultant, SAP FI/CO, at Infosys Ltd. He has more than seven years of experience in SAP FI/CO and SAP Treasury and Risk Management. He also has worked in number of implementation and roll out projects for US as well as UK territories. He holds an MBA in finance as well as a bachelor’s degree in IT.


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!