Enterprise Travel Expenses: SAP Concur Limits

SAP Concur Is Good - for What It Was Built For

SAP Concur is the world’s most widely used travel expense software. Receipt capture via mobile app, approval workflows, integration with SAP systems - for organisations with standardised domestic travel, it works reliably.

The problem starts where standard processes end. For enterprises operating across collective agreements, multiple jurisdictions and industry-specific complexity, every pure capture tool hits its limits - not just Concur, but also Circula, Rydoo or HR Works.

The reason: these tools solve the capture problem. Not the decision problem.

The Decision Problem: 40 to 120 Micro-Decisions per Transaction

A travel expense report is not receipt capture. Behind every transaction sit 40 to 120 micro-decisions:

• Which per diem rate applies (government rate schedule, valid on the travel date)?
• Does a collective agreement override the statutory rate?
• How are meal deductions calculated (breakfast, lunch, dinner)?
• Which cost centre bears the transaction?
• What is the tax treatment (tax-exempt, flat-rate taxed, fully taxable)?
• What happens when the itinerary changes mid-trip?

SAP Concur captures the receipt. But who makes these decisions? In most enterprises: a clerk in the Shared Service Center, manually, per transaction, without documented decision logic.

That is expensive. The GBTA Foundation puts the average cost per manually processed travel expense report at $58 - with an error rate of 19 percent and correction costs of $52 per error (source: GBTA Foundation / HRS, “Expense Reporting: Global Practices and Pain Points”, 2015).

Where Standard Expense Tools Hit Their Limits

Collective Agreements Override Statutory Rates

Government per diem rates set the statutory baseline. Under German law, that means EUR 14 for arrival days and EUR 28 for full absence days domestically (2026 rates). Under Nordic collective frameworks, separate per diem structures exist entirely. Many collective agreements define higher rates - sometimes significantly so.

An airline group with 10,000 crew members typically maintains 2 to 5 parallel collective agreements: cockpit, cabin, ground staff, maintenance. Each agreement defines its own per diem rates, its own deduction rules, its own exceptions for provided meals.

SAP Concur has no concept of collective agreements. The software calculates using statutory rates - or a single company-wide flat rate. The agreement-compliant calculation of per diem allowances happens outside the tool: manually, in spreadsheets, or through clerks in the Shared Service Center who transfer the result back into the system by hand.

This is not just inefficient. It is error-prone. When the clerk applies the wrong collective agreement to crew group 3, systematic errors emerge that go undetected across thousands of transactions - until the next tax audit.

Multi-Jurisdiction in a Single Transaction

A crew member on a European route touches 3 to 5 countries in a single day. The per diem rate depends on the country where the travel day ends, or on the midnight rule for multi-day trips. Standard expense tools calculate one country per trip. Multi-jurisdiction within a single transaction - with border crossings tracked to the minute - lies outside their data model.

This is not limited to airlines:

• Logistics: Drivers cross multiple borders daily. The per diem rate changes at every border, and calculation must be precise to the minute - particularly for midnight crossings. Add the documentation requirements of the EU Mobility Package (Directive 2020/1057).
• Sales: Field representatives visit clients across multiple countries per week. Monday Vienna, Wednesday Zurich, Friday Munich - three jurisdictions, three per diem rates, one transaction.
• Consulting: Consultants work in rotating engagements. A weekly rhythm with three clients in two countries creates splitting requirements that no standard tool can map.

Irregular Operations and Unplanned Changes

10 to 20 percent of all flights are affected by irregularities - delays, diversions, crew repositioning (source: EUROCONTROL / US DOT BTS, 2024). Every irregularity changes the expense calculation: different per diem due to a different destination country, different accommodation entitlement, different cost centre.

No standard expense tool processes irregular operations (IROP) automatically. The correction happens manually - if it is recognised at all. With 100,000 crew transactions per year and an IROP rate of 15 percent, that means 15,000 transactions requiring manual rework. Each one carrying the risk that the correction itself is erroneous.

The Governance Gap

SAP Concur documents what was submitted. It does not document why a decision was made. That is the difference between a capture tool and a governance layer.

When the tax auditor asks: “What rule was applied to calculate this per diem?” - Concur has no answer. The amount is in the system, the decision logic is not. When employee representation bodies ask: “How are travel expense decisions being made?” - the honest answer in most enterprises is: the clerk decides based on experience.

That is not an Audit Trail. That is person-dependency.

Simulation: 100,000 Crew Transactions per Year

The Baseline

For an airline group processing 100,000 crew transactions per year, the GBTA data yields:

Not included: approver time costs (managers reviewing receipts instead of leading), month-end bottlenecks in accounting, audit risk during tax audits, and employee frustration from delayed reimbursements.

The Decision Layer Approach

The Travel Decision Layer breaks every travel expense transaction into its micro-decisions and applies documented rules to each one: statutory law, collective agreement, company policy - in that hierarchy, versioned, traceable.

Rule application is deterministic. No stochastic language model decides on amounts or tax treatment. AI is used for classification - identifying receipt types, categorising IROP types, classifying entertainment purposes - but the calculation follows exact rules. For a deeper understanding of how the Decision Layer architecture separates classification from calculation, see our foundational article.

For the aviation simulation, the comparison looks like this:

Projection at 100,000 transactions: from $6.8M to under $1M per year. The savings do not come from cheaper clerks, but from eliminating manual decisions.

The Decision Flow in Detail

A single crew transaction passes through the following steps in the Decision Layer:

1. Ingest rotation data from the crew planning system
2. Determine country sequence from the rotation data
3. Look up per diem rate per country and day (government rate schedule, valid on the travel date)
4. Check collective agreement override (crew group, validity period)
5. Calculate meal deductions (breakfast, lunch, dinner - per day)
6. Classify IROP type (AI-assisted) and recalculate per diem
7. Validate hotel costs against policy (cap per city)
8. Assign cost centre (rotation, fleet, crew group)
9. Determine tax treatment (tax-exempt, flat-rate, fully taxable)
10. Generate audit record (SHA-256 signed, append-only)

Each of these steps is a documented decision with a traceable rule basis. That is the difference from an approval workflow where a human clicks “Approved” without the decision logic being recorded in the system. This Cert-Ready by Design approach ensures audit readiness is structural, not reconstructed.

Four Industries, Four Complexity Levels

The Travel Decision Layer is not limited to aviation. The core architecture - a deterministic rule engine over micro-decisions - works across industries with industry-specific configuration:

All four simulations are based on the same GBTA baseline ($58 per transaction, 19% error rate) and show industry-specific optimisation potential. The different zero-touch rates reflect industry complexity: logistics and aviation reach 95 percent because input data (GPS tracks, crew rotations) is machine-readable. Consulting sits at 85 percent because multi-client weeks may require manual allocation.

What a Solution Needs to Complement SAP Concur

SAP Concur does not need to be replaced. What is missing is the layer above it - the governance layer that decides before the receipt enters the system:

1. Collective-agreement-native rule engine - Collective agreements not as a workaround, but as a first-class concept. Configurable per employee group, with validity periods and override hierarchy.
2. Versioned decision tables - Every rule dated, every change traceable. Government per diem rates, collective agreement rates and company policies as dated changesets.
3. Gapless Audit Trail - Every micro-decision signed (SHA-256), stored in an append-only process. No overwriting, no deletion, fully reproducible.
4. Employee representation-compatible transparency - The rule set is inspectable, the decision logic traceable. No black-box AI decides on amounts. Under German co-determination law (Betriebsverfassungsgesetz), works councils have co-determination rights over automated monitoring systems - the Decision Layer’s transparency satisfies even the strictest model.
5. ERP integration - No system replacement, but input into existing ERP and payroll systems. The Decision Layer sits between data source and booking system.
6. Multi-jurisdiction per transaction - Not per trip, but per day, with border crossings tracked to the minute.

Gosign implements this governance layer as the Travel Decision Layer - configured for your industry, on your infrastructure, without external SaaS dependency.