Koszty podróży w korporacji: Limity SAP Concur

SAP Concur jest dobry - w tym, do czego został zbudowany

SAP Concur to najczęściej wdrażane oprogramowanie do rozliczania kosztów podróży na świecie. Rejestracja rachunków przez aplikację, workflow zatwierdzania, integracja z SAP - dla firm ze standardowymi podróżami krajowymi działa niezawodnie.

Problem zaczyna się tam, gdzie kończą się standardowe procesy. W korporacjach z układami zbiorowymi pracy, podróżami wielojurysdykcyjnymi i branżową złożonością każde czysto rejestracyjne narzędzie trafia na swoje granice - nie tylko Concur, ale również Circula, Rydoo czy HR Works.

Powód: te narzędzia rozwiązują problem rejestracji. Nie problem decyzyjny.

Problem decyzyjny: 40 do 120 mikro-decyzji na transakcję

Rozliczenie kosztów podróży to nie rejestracja rachunków. Za każdą transakcją stoi 40 do 120 mikro-decyzji:

• Jaka dieta obowiązuje (stawki krajowe, stan na dzień podróży)?
• Czy układ zbiorowy pracy nadpisuje stawkę ustawową?
• Jak naliczana jest redukcja z tytułu zapewnionych posiłków (śniadanie, obiad, kolacja)?
• Jakie centrum kosztów pokrywa transakcję?
• Jaki jest sposób opodatkowania (zwolnione, ryczałtowe, opodatkowane)?
• Co się dzieje przy zmianie planu w trakcie podróży?

SAP Concur rejestruje rachunek. Ale kto podejmuje te decyzje? W większości korporacji: pracownik Shared Service Center, ręcznie, per transakcja, bez udokumentowanej logiki decyzyjnej.

To jest kosztowne. GBTA Foundation szacuje średni koszt ręcznej obsługi jednej transakcji kosztów podróży na 58 USD - przy wskaźniku błędów 19 procent i koszcie korekty 52 USD za błąd (Źródło: GBTA Foundation / HRS, “Expense Reporting: Global Practices and Pain Points”, 2015).

Gdzie standardowe narzędzia do kosztów podróży trafiają na granice

Układ zbiorowy nadpisuje prawo

Stawki diet krajowych to minimalny standard ustawowy. W Polsce Rozporządzenie Ministra Pracy i Polityki Społecznej definiuje podstawowe stawki: 45 PLN za pełną dobę podróży krajowej (stan 2024). Wiele układów zbiorowych pracy definiuje wyższe stawki - czasem znacząco.

Koncern energetyczny z 35 000 pracowników po fuzji ma typowo 2 do 5 równoległych układów zbiorowych: produkcja, przesył, dystrybucja, biuro, kadra zarządzająca. Każdy układ definiuje własne stawki diet, własne zasady redukcji za posiłki, własne wyjątki.

SAP Concur nie zna układów zbiorowych. Oprogramowanie kalkuluje na podstawie stawek ustawowych - albo jednej stawki ogólnofirmowej. Kalkulacja diet zgodna z układem zbiorowym odbywa się poza narzędziem: ręcznie, w arkuszach kalkulacyjnych, albo przez pracowników Shared Service Center, którzy wynik ręcznie wprowadzają z powrotem do systemu.

To nie tylko nieefektywne. To podatne na błędy. Kiedy pracownik SSC zastosuje niewłaściwy układ zbiorowy dla grupy pracowniczej 3, powstają systematyczne błędy, które przy tysiącach transakcji pozostają niezauważone - aż do kontroli skarbowej.

Multi-jurysdykcja w jednej transakcji

Członek załogi lotniczej na locie europejskim jest w ciągu jednego dnia w 3 do 5 krajach. Dieta zależy od kraju, w którym kończy się dzień podróży, lub od zasady północy przy podróżach wielodniowych. Standardowe narzędzia do kosztów podróży kalkulują jedną podróż z jednym krajem. Multi-jurysdykcja wewnątrz jednej transakcji - z co do minuty dokładnym przekroczeniem granicy - leży poza ich modelem danych.

To nie dotyczy wyłącznie linii lotniczych:

• Logistyka: Kierowcy przekraczają codziennie kilka granic. Dieta zmienia się na każdej granicy, kalkulacja musi być co do minuty precyzyjna - szczególnie przy przekroczeniach północy. Do tego dochodzą wymogi dokumentacyjne Pakietu Mobilności UE (Dyrektywa 2020/1057).
• Sprzedaż: Przedstawiciele terenowi odwiedzają klientów w wielu krajach w ciągu tygodnia. Poniedziałek Wiedeń, środa Zurych, piątek Monachium - trzy jurysdykcje, trzy stawki diet, jedna transakcja.
• Doradztwo: Konsultanci pracują w zmieniających się mandatach. Tygodniowy rytm z trzema klientami w dwóch krajach generuje wymagania podziału, których żadne standardowe narzędzie nie odwzorowuje.

Nieregularne operacje i nieplanowane zmiany

10 do 20 procent wszystkich lotów jest dotkniętych nieregularnościami - opóźnienia, przekierowania, repozycje załogi (Źródło: EUROCONTROL / US DOT BTS, 2024). Każda nieregularność zmienia kalkulację kosztów podróży: inna dieta z powodu innego kraju docelowego, inny wymóg noclegu, inne centrum kosztów.

Żadne standardowe narzędzie do kosztów podróży nie przetwarza operacji nieregularnych (IROP) automatycznie. Korekta następuje ręcznie - jeśli w ogóle zostanie rozpoznana. Przy 100 000 transakcji załogowych rocznie i wskaźniku IROP na poziomie 15 procent to 15 000 transakcji wymagających ręcznej korekty. Każda z ryzykiem, że sama korekta jest błędna.

Luka governance

SAP Concur dokumentuje, co zostało złożone. Nie dokumentuje, dlaczego tak zdecydowano. To jest różnica między narzędziem rejestracyjnym a warstwą governance.

Gdy kontroler skarbowy pyta: “Na podstawie jakiej reguły obliczono tę dietę?” - Concur nie ma odpowiedzi. Kwota jest w systemie, logika decyzyjna nie. Gdy rada zakładowa pyta: “Jak podejmowane są decyzje o kosztach podróży?” - uczciwa odpowiedź w większości korporacji brzmi: pracownik SSC decyduje na podstawie doświadczenia.

To nie jest Audit Trail. To zależność od jednej osoby.

Symulacja: 100 000 transakcji załogowych rocznie

Punkt wyjścia

Dla koncernu lotniczego ze 100 000 transakcjami załogowymi rocznie na podstawie danych GBTA wynika:

Nie uwzględniono: kosztów czasu zatwierdzających (kadra kierownicza sprawdzająca rachunki zamiast zarządzać), zatorów na koniec miesiąca w księgowości, ryzyka audytowego przy kontroli skarbowej i frustracji pracowników wynikającej z opóźnionych zwrotów.

Podejście Decision Layer

Travel Decision Layer rozkłada każdą transakcję kosztów podróży na mikro-decyzje i stosuje do każdej decyzji udokumentowane reguły: prawo, układ zbiorowy, polityka firmy - w tej hierarchii, wersjonowane, identyfikowalne.

Stosowanie reguł jest deterministyczne. Żaden stochastyczny model językowy nie decyduje o kwotach ani opodatkowaniu. AI jest wykorzystywana do klasyfikacji - rozpoznanie typu rachunku, kategoryzacja IROP, klasyfikacja celu spotkania biznesowego - ale kalkulacja podlega ścisłym regułom.

Dla symulacji lotniczej wynika:

Przeliczenie przy 100 000 transakcji: z 6,8 mln USD do poniżej 1 mln USD rocznie. Oszczędność nie wynika z tańszych pracowników SSC, lecz z eliminacji ręcznych decyzji.

Przebieg decyzyjny w szczegółach

Pojedyncza transakcja załogowa przechodzi w Decision Layer następujące kroki:

1. Wczytanie danych rotacyjnych z systemu planowania załóg
2. Ustalenie sekwencji krajów z danych rotacyjnych
3. Określenie diety na kraj i dzień (stawki krajowe, obowiązujące w dniu podróży)
4. Sprawdzenie nadpisania układem zbiorowym (grupa pracownicza, okres obowiązywania)
5. Obliczenie redukcji za posiłki (śniadanie, obiad, kolacja - na dzień)
6. Klasyfikacja typu IROP (wspomagana AI) i ponowna kalkulacja diety
7. Sprawdzenie kosztów hotelu wobec polityki (limit na miasto)
8. Przypisanie centrum kosztów (rotacja, flota, grupa załogowa)
9. Ustalenie sposobu opodatkowania (zwolnione, ryczałtowe, opodatkowane)
10. Wygenerowanie rekordu audytowego (podpisany SHA-256, append-only)

Każdy z tych kroków to udokumentowana decyzja z identyfikowalną podstawą prawną. To jest różnica w porównaniu z workflow zatwierdzania, w którym człowiek klika “Zatwierdzone” bez zapisanej logiki decyzyjnej w systemie.

Cztery branże, cztery poziomy złożoności

Travel Decision Layer nie jest ograniczony do lotnictwa. Podstawowa architektura - deterministyczny zestaw reguł nad mikro-decyzjami - działa międzybranżowo z branżową konfiguracją:

Wszystkie cztery symulacje opierają się na tych samych wartościach wyjściowych GBTA (58 USD na transakcję, 19 % wskaźnik błędów) i pokazują branżowe potencjały optymalizacji. Różne Zero-Touch-Quote odzwierciedlają złożoność branżową: logistyka i lotnictwo osiągają 95 procent, ponieważ dane wejściowe (GPS-Tracks, rotacje załogowe) są maszynowo czytelne. Doradztwo plasuje się na 85 procentach, ponieważ tygodnie z wieloma mandatami mogą wymagać ręcznego przyporządkowania.

Czego potrzebuje rozwiązanie uzupełniające SAP Concur

SAP Concur nie musi być zastępowany. Brakuje warstwy powyżej - warstwy governance, która decyduje zanim rachunek trafi do systemu:

1. Silnik reguł natywny dla układów zbiorowych - Układy zbiorowe nie jako obejście, lecz jako koncepcja pierwszej klasy. Konfigurowalny per grupa pracownicza, z okresem obowiązywania i hierarchią nadpisywania.
2. Wersjonowane tabele decyzyjne - Każda reguła datowana, każda zmiana identyfikowalna. Stawki diet, siatki z układów zbiorowych i polityki firmowe jako datowane zestawy zmian.
3. Kompletny Audit Trail - Każda mikro-decyzja podpisana (SHA-256), zapisana w trybie append-only. Bez nadpisywania, bez usuwania, w pełni reprodukowalna.
4. Przejrzystość zgodna z wymogami rady zakładowej - Zestaw reguł jest dostępny do wglądu, logika decyzyjna jest identyfikowalna. Żadna czarna skrzynka AI nie decyduje o kwotach.
5. Integracja z ERP - Żaden zamiennik systemu, lecz zasilanie istniejących systemów ERP i payroll. Decision Layer znajduje się między źródłem danych a systemem księgowym.
6. Multi-jurysdykcja per transakcja - Nie per podróż, lecz per dzień, z co do minuty dokładnym przekroczeniem granicy.

Gosign implementuje tę warstwę governance jako Travel Decision Layer - branżowo skonfigurowany, na Twojej infrastrukturze, bez zewnętrznej zależności od SaaS.