Configure SAP Concur as a data pipeline source ​

Set up SAP Concur as a data pipeline source to extract and sync expense reports, invoices, users, lists, and related travel and expense records from the SAP Concur APIs to your destination.

Use this guide to review the features and prerequisites, generate SAP Concur credentials, connect SAP Concur as a data pipeline source, configure the pipeline, and understand the supported objects, sync modes, schema handling, sensitive data handling, and limitations.

Features supported ​

The following features are supported when you use SAP Concur as a pipeline source:

• Cloud connectivity: Connects to the SAP Concur APIs over https. SAP Concur is a cloud-hosted platform, so an on-prem agent isn't required. The connector routes each request to your assigned SAP Concur data center automatically.
• Production and sandbox support: Connect to a production instance or to an implementation (sandbox) instance through the Implementation instance setting.
• Object-level selection: Choose the supported objects you plan to sync when you configure the pipeline.
• Sync modes: The report, payment_request, and travel_request objects sync incrementally. All other objects use full sync.
• Delete tracking: A subset of objects carries a source-driven soft-delete signal. Full-sync objects reflect deletions through destination-side snapshot comparison.
• Schema drift handling: Choose to auto-sync or block newly added fields in the source.
• Field-level data protection: Replicate field values as is or hash sensitive values before they reach your destination.
• Configurable sync frequency: Schedule syncs with time-based or cron-based schedules. The minimum interval is 15 minutes.

Prerequisites ​

Complete the following requirements before you configure SAP Concur as a data pipeline source:

• A SAP Concur account with the modules you plan to sync licensed. SAP Concur licenses Expense, Invoice, Travel, and Request as separate modules. Refer to Module licensing for more information.
• An OAuth 2.0 application in SAP Concur, with a client ID and client secret and at minimum the EXPRPT scope. Refer to Create an OAuth 2.0 application for setup steps.
• Credentials for your chosen authentication method:
  • Authorization code grant: A SAP Concur user who can authorize the connection through the browser sign-in flow, plus a custom OAuth profile in Workato that stores your client ID and client secret.
  • Password grant: Your SAP Concur username and password, plus the client ID and client secret from your OAuth application.
  • Refresh token grant: A refresh token generated from a company request token, plus the client ID and client secret from your OAuth application.

Supported connection types ​

SAP Concur data pipelines support OAuth 2.0 authentication through the following grant types:

• Authorization code grant: Authorizes the connection through the SAP Concur browser sign-in flow. Select this method to authenticate as the signing-in user without storing a username and password in Workato.
• Password grant: Authenticates with your SAP Concur username and password, plus your OAuth application's client ID and client secret. A password grant connection is user-typed. Use this method to sync the payment_type object.
• Refresh token grant: Authenticates with a refresh token generated from a company request token, plus your OAuth application's client ID and client secret. A refresh token grant connection is company-typed. Use this method to sync the user object.

The connection's token type determines which objects it can sync. No single connection syncs both user and payment_type. Refer to Connection type determines object availability for more information.

Connect to SAP Concur ​

Complete the following steps to connect to SAP Concur:

ATTEND
CONFIG
expense.report.read
expense.report.readwrite
EXPRPT
identity.user.core.read
identity.user.coreenterprise.writeonly
identity.user.coresensitive.read
identity.user.enterprise.read
identity.user.externalID.writeonly
identity.user.ids.read
identity.user.sap.read
IMAGE
INVPMT
INVVEN
LIST
openid
spend.list.read
spend.list.write
spend.listitem.delete
spend.listitem.read
spend.listitem.write
spend.user.general.read
spend.user.general.writeonly
travel.user.general.read
travel.user.private.read
user.provision.read
user.provision.write
user.read
user.write

Configure the pipeline ​

Complete the following steps to configure SAP Concur as your data pipeline source:

[minute] [hour] [day of month] [month] [day of week]

0 8 * * *

Supported objects ​

SAP Concur data pipelines sync data from the SAP Concur Expense, Invoice, Request, Identity, Lists, and Common Locations APIs. Each object syncs as a separate table in your destination. Child objects sync as separate normalized tables. Each child table uses a single-column id primary key and carries a parent-reference column, such as payment_request_id on payment_request_line or list_id on list_item. Join on the parent-reference column to relate a child table back to its parent.

The following tables list the supported objects, grouped by category:

Expense reports and expenses ​

The following objects describe expense reports and the expense entries, allocations, itemizations, and attendees attached to them. The expense_entry, allocation, itemization, and entry_attendee_association objects are child records of the expense report structure, extracted at tenant scope and synced as separate tables. These objects require the Expense module.

Expense configuration ​

The following objects describe the expense configuration reference data for your SAP Concur tenant:

Invoices and vendors ​

The following objects describe payment requests (invoices) and vendor master data. These objects require the Invoice module. The vendor bank, group, and status objects are extracted through the vendor response. The payment_request object syncs incrementally, but payment_request_line reloads in full on each run.

Travel requests ​

The following object describes travel requests. It requires the Request module.

Lists ​

The following objects describe custom lists and their items:

Users ​

The users object describes user identity records from the SAP Concur Identity (SCIM) API:

Locations ​

The locations object describes location reference data:

Sync modes ​

SAP Concur data pipelines support full sync and incremental sync. The sync mode is fixed per object based on whether the SAP Concur API exposes a usable modification-time filter for that object.

Full sync ​

Full sync re-extracts the complete record set for an object on each run and overwrites the destination table. Most SAP Concur objects use full sync, because the SAP Concur APIs for those objects don't expose a modification-time filter. This includes the user object, because the SAP Concur Identity API can't filter by last-modified date.

Incremental sync ​

Incremental sync extracts only records created or updated since the previous run, using each object's last-modified timestamp as the cursor. Three objects sync incrementally:

All other objects use full sync, because the SAP Concur APIs for those objects don't expose a usable modification-time filter. Refer to the Supported objects tables to see the sync mode for each object.

Delete tracking ​

SAP Concur data pipelines track soft deletes for objects that expose a deletion signal in the source. When a record enters a deleted state, the pipeline sets the _workato_is_deleted column to true in the destination on the next sync. These objects are marked Yes (soft) in the Supported objects tables.

These objects also include SAP Concur deletion fields, which you can query directly: is_deleted on attendee_type, payment_type, list, and list_item; and is_payment_request_deleted, deleted_date, and payment_request_deleted_by on payment_request.

SAP Concur doesn't expose a deletion signal for the remaining objects. Because these objects use full sync, the destination detects deletions by comparing each run against the previous run, and sets _workato_is_deleted to true for records that no longer appear at the source.

The report and travel_request objects are an exception to this process. Both the report and travel_request objects sync incrementally without SAP Concur exposing a deletion signal, which means that the _workato_is_deleted column isn't included and the pipeline can't detect deletions for these objects.

The payment_request_line object doesn't have a source-side deletion signal of its own. Full sync still detects lines that disappear between runs. You can identify lines belonging to a payment request that SAP Concur marks as deleted while its lines remain present by joining payment_request_line to payment_request on payment_request_id and filtering on the parent's deletion state.

Schema and data type handling ​

The SAP Concur connector applies specific handling to certain SAP Concur field types when it replicates data to your destination.

Custom fields ​

SAP Concur objects include custom field slots. The number of slots and the shape of each slot vary by object:

• On report, expense_entry, itemization, allocation, and travel_request, custom fields are structured objects. The connector stores each slot as a JSON-string column.
• On attendee, entry_attendee_association, payment_request, payment_request_line, and vendor, custom fields are flat strings.

The number of slots per object is:

Custom field labels are defined per tenant in SAP Concur. The connector emits the canonical custom1 through customN column names rather than the tenant-specific labels.

Nested and child objects ​

The SAP Concur connector emits child records as separate tables rather than inlining them into the parent record. Each child table uses a single-column id primary key and includes a parent-reference column. Deeply nested arrays that remain within a record are serialized as JSON-string columns.

Per-tenant schema variability ​

Object availability and custom field labels vary per tenant, because SAP Concur licenses the Expense, Invoice, and Request modules separately and each tenant defines its own custom fields. Core object schemas are consistent across tenants.

Synthetic columns ​

Workato adds the following synthetic columns to destination tables:

Column name casing in your destination ​

Your destination adjusts column name casing when it creates tables. Snowflake stores column names in uppercase, most destinations store them in lowercase, and BigQuery and SQL Server keep them as the connector emits them.

Sensitive data handling ​

SAP Concur objects can contain personally identifiable information (PII) and sensitive financial data. The following objects commonly contain sensitive fields:

SAP Concur returns the user object's email addresses and phone numbers as arrays, which the connector stores as JSON-string column, for example, emails and phone_numbers. There is no single primary-email column.

Use the Hash option in field-level data protection during pipeline configuration to protect PII before it reaches your destination. Refer to the Configure the pipeline steps for more information.

Limitations ​

The following limitations apply when you use SAP Concur as a data pipeline source:

Module licensing ​

SAP Concur licenses Expense, Invoice, Travel, and Request as separate modules. Your account can sync objects only from the modules it licenses. The pipeline returns a permissions error if you select an object from a module your account doesn't license. Confirm your module licensing before you add objects from the Invoice, Travel, or Request categories.

Connection type determines object availability ​

A SAP Concur connection uses a single token type, which determines the objects the connection can use sync data:

• A user-typed connection can sync the payment_type object but not the user object. Password grant produces a user-typed connection.
• A company-typed connection can sync the user object but not the payment_type object. Refresh token grant produces a company-typed connection.

A single connection can't sync both user and payment_type. You must create a separate connections for user and payment_type and use these connections in separate pipelines to sync both objects.

Minimum sync frequency ​

The minimum supported sync interval is 15 minutes. You can't trigger syncs more frequently than this.