Expense, Payment und Travel als integrierter Prozess bedeutet: Eine Buchung erzeugt eine Zahlung, die Zahlung erzeugt einen Beleg, der Beleg erzeugt eine Abrechnung — alles in einer Datenbasis. Im deutschen Mittelstand bringt diese Integration zwei messbare Effekte: 60 bis 75 Prozent weniger Prozesszeit in Finance und HR, plus eine Datenqualität, die Travel Management überhaupt erst steuerbar macht. Intertours liefert die drei Module — Intertours Travel, Intertours Pay, Intertours Expense — als ein integriertes Operating Model.
Was Integration konkret bedeutet — und was nicht
Integration zwischen Expense, Payment und Travel heißt nicht: drei Tools mit Schnittstellen. Es heißt: ein durchgängiger Prozess auf einer Datenbasis.
Der integrierte Vorgang in fünf Schritten
- Buchung: Reisende oder Travel Manager bucht über Atriis-OBE. PNR-Datensatz entsteht mit Kostenstelle, Reisegrund, Approval-Status.
- Bezahlung: Buchung wird über Corporate Card, Lodge Card oder virtuelle Karte direkt durch das Unternehmen bezahlt — keine private Vorauslage durch Reisende.
- Reise und Beleg: Während der Reise werden Spesen-Belege per Mobile-App-Foto erfasst (Bewirtung, Taxi, sonstige Auslagen). OCR liest Beträge automatisch.
- Abrechnung: Belege werden gegen Reiserichtlinie geprüft, kategorisiert, Mehrwertsteuer ausgewiesen, mit der Buchung verknüpft.
- Buchhaltung: Die Daten fließen in Datev, SAP FI oder ein anderes ERP — pro Kostenstelle, pro Konto, pro Mehrwertsteuer-Logik.
Das ist nicht ein Tool, das andere Tools ablöst. Das ist ein Prozess, der ohne System-Brüche läuft.
Für CFO und Buchhaltungs-Leitung relevant: Der Wert entsteht nicht im einzelnen Modul. Er entsteht im Datenfluss zwischen den Modulen — weil dort die manuellen Stunden eingespart werden und weil dort die Reporting-Qualität entsteht.
Das Problem mit drei getrennten Tools im Mittelstand
Im deutschen Mittelstand sind Travel, Payment und Expense typischerweise drei separate Welten. Drei separate Tools, drei Datenformate, drei Schnittstellen — und drei Datenqualitäts-Probleme.
Wo die Daten brechen
- Buchung läuft über Reisebüro oder OBE — Daten kommen als PDF-Reiseplan oder als manueller Buchungseintrag
- Bezahlung läuft privat über die Karten der Reisenden oder über Firmen-Kreditkarten ohne strukturierte Belegerfassung
- Spesenabrechnung läuft über Excel oder ein eigenes Tool, das nicht weiß, was gebucht wurde
- Buchhaltung bekommt Belege und tippt sie ein — ohne Verknüpfung zur ursprünglichen Reise
Die Folgen
- Manueller Aufwand in Finance: zwei bis vier Stunden pro Reise, je nach Komplexität
- Erstattungsdauer für Reisende: vier bis acht Wochen, weil Belege durch mehrere Stationen wandern
- Reisekosten-Reporting unmöglich: weil Buchungs- und Belegdaten nicht aufeinander mappen
- Konditions- und Reisemittel-Steuerung ohne Faktenbasis
- Compliance-Risiko bei Audit, weil Belegketten unvollständig sind
Mittelständler mit 500 bis 2.500 Mitarbeitenden und 1.500 bis 5.000 Reisen pro Jahr verlieren in diesem Modell typischerweise 250 bis 600 Personentage pro Jahr — in Sekretariat, HR und Buchhaltung zusammen.
Intertours Travel: Buchung als Datenquelle
Intertours Travel ist die Buchungs- und Steuerungsschicht — Atriis als OBE-Plattform plus dedizierter Travel Manager als persönliche Steuerung. Im integrierten Operating Model ist Travel nicht nur Buchung — es ist die Quelle aller nachgelagerten Daten.
Was Intertours Travel im integrierten Modell liefert
- Strukturierte PNR-Daten mit Reisegrund, Kostenstelle, Approver, Reisendem
- Multi-Source-Inventar (NDC, GDS, Direct Connect, Bahn) mit konsolidiertem Output
- Approval-Workflow mit Pre-Trip-Approval — Daten fließen sofort in das Reporting
- Travel Policy als Code — Compliance-Status pro Buchung
- Verknüpfung zur Bezahlmethode (Corporate Card, Lodge Card)
- API für nachgelagerte Module (Expense, Reporting, Buchhaltung)
Ohne diese Buchungs-Datenbasis ist Expense ein Belegerfassungs-Tool. Mit ihr wird Expense Teil einer durchgängigen Reisedokumentation.
Intertours Pay: Zentrale Zahlung mit Corporate Cards und Lodge Card
Intertours Pay ist das Zahlungsmodul im integrierten Operating Model. Es löst zwei strukturelle Probleme des Mittelstands: die Vorauslage durch Mitarbeitende und die Belegketten-Lücke zwischen Buchung und Buchhaltung.
Die drei Karten-Typen im Mittelstands-Einsatz
| Karten-Typ | Zweck | Wann sinnvoll |
|---|---|---|
| Corporate Card (personalisiert) | Persönliche Geschäftskarte für vielreisende Mitarbeitende | Mitarbeitende mit hoher Reisefrequenz und Spesenanteil |
| Lodge Card (zentral) | Zentrale Firmenkarte für Flüge, Hotels, Mietwagen — vom Travel Manager belastet | Für alle Buchungen, die vorab über die OBE laufen |
| Virtuelle Karte (Single-Use) | Einzelvorgangs-Karte für spezifische Buchungen | Für Hotelbuchungen mit unklarer Belastungs-Logik oder Ad-hoc-Reisen |
Was die zentrale Zahlung konkret leistet
- Keine private Vorauslage durch Mitarbeitende — Cashflow-Vorteil für Reisende
- Strukturierte Belegerfassung direkt bei Belastung (PNR + Hotel + Mietwagen werden gebündelt)
- Automatischer Datenfluss zur Buchhaltung — keine manuelle Beleg-Eingabe
- Compliance-Sicherheit bei Audit (Belegkette von Buchung über Bezahlung zur Abrechnung)
- Cashback und Rebates bei Card-Issuern werden als Programm-Komponente zurückgeführt
Operative Größenordnung: Bei Mittelständlern mit 3.000 bis 5.000 Reisen pro Jahr reduziert Intertours Pay den manuellen Aufwand in der Buchhaltung typischerweise um 60 bis 75 Prozent. Erstattungsdauer für persönliche Auslagen sinkt von vier bis acht Wochen auf eine bis zwei Wochen.
Intertours Expense: OCR, Abrechnung, Buchhaltungsschnittstelle
Intertours Expense ist das Abrechnungs- und Beleg-Modul. Es verbindet die Buchung (aus Travel) und die Bezahlung (aus Pay) mit den Spesen-Belegen, die während der Reise entstehen — Bewirtung, Taxi, Trinkgeld, sonstige Auslagen.
Was Intertours Expense automatisiert
- OCR-Belegerfassung über Mobile App — Foto reicht, Beträge werden automatisch ausgelesen
- Automatische Kategorisierung (Bewirtung, Hotel, Transport, Sonstiges, mit MwSt.-Logik)
- Prüfung gegen Reiserichtlinie (Pauschalen, Tagessätze, Belegpflicht)
- Verknüpfung zur ursprünglichen Buchung (PNR → Cost-Center)
- Optionaler Expense Check als ausgelagerter Prüfservice (für Unternehmen ohne eigene Buchhaltungskapazität)
- Übergabe an Datev, SAP FI, Microsoft Business Central oder andere Buchhaltungssysteme
Was Intertours Expense nicht ersetzt
Es ersetzt nicht die Buchhaltung als Funktion. Es ersetzt nicht die Reisekostenrichtlinie als Regelwerk. Es ersetzt nicht die Verantwortung der Reisenden, Belege einzureichen. Es automatisiert die manuellen Schritte zwischen diesen Funktionen.
Vom Trio zum Operating Model: Wie die drei Module zusammenwirken
Der Wert entsteht im Zusammenspiel. Drei Punkte sind operativ entscheidend.
Eine Datenbasis statt drei
Buchungsdaten, Zahlungsdaten und Belegdaten liegen in einer konsolidierten Datenstruktur — verknüpft über die Reise als Klammer. Damit wird Cost-per-Trip präzise berechenbar, Reporting wird vergleichbar, und Anomalien werden sichtbar.
Ein Vertragspartner statt drei
Intertours liefert die drei Module aus einem Haus. Damit gibt es einen Steering-Cadence, einen Reporting-Pack, eine Eskalations-Logik. Wer drei getrennte Vendor-Stacks betreibt, betreibt drei Risiko-Profile parallel.
Eine Steuerungsebene statt drei
Travel Policy wirkt nicht nur in der Buchung, sondern auch in der Spesenabrechnung. Approval-Logik betrifft beide Welten. Reporting läuft über die Gesamtreise — nicht über das einzelne Modul. Steuerung wird einfacher.
Vergleich mit Stand-alone-Lösungen (SAP Concur, Pleo, Moss)
Im Mittelstand konkurriert das integrierte Intertours-Modell mit drei Klassen von Stand-alone-Lösungen.
| Anbieter / Modell | Stärke | Schwäche im Mittelstand |
|---|---|---|
| SAP Concur (Travel + Expense) | Tief in SAP-Welt integriert, Enterprise-Reife | Hoher Konfigurationsaufwand, komplex für 500–2.500 MA, keine eigene Steuerungs-Schicht |
| Pleo / Moss (Expense + Payment-zentrisch) | Schöne Belegerfassung, schnelle Adoption | Travel-Buchung nicht integriert, keine Steuerung der Reisekosten, geringe Konditions-Logik |
| TravelPerk / Lanes & Planes (Travel-zentrisch) | Self-Service-Plattform mit guter UX | Schwache Expense-Tiefe, dünne Payment-Integration, dünne Konditionsverhandlung |
| Intertours Travel + Pay + Expense | Integriert in einem Operating Model, mit Travel-Manager-Steuerung und Altour-Netzwerk | Höhere Implementierungstiefe als reine Self-Service-Stacks |
Für Einkauf relevant: Die Frage ist nicht „welches Tool ist das beste". Die Frage ist: „welches Operating Model passt zu unserem Reifegrad". Mittelständler mit 500 bis 2.500 MA und ohne dedizierte Travel-Abteilung profitieren am stärksten von einem integrierten Setup mit Steuerung — nicht von einem Tool-Stack mit drei Anbietern.
Datev-, SAP-, HR-Anbindung: Was technisch notwendig ist
Eine integrierte Travel-Pay-Expense-Lösung läuft im deutschen Mittelstand selten ohne ERP- und HR-Anbindung.
Datev-Anbindung
Datev ist im deutschen Mittelstand das dominante Buchhaltungssystem. Die Schnittstelle überträgt strukturiert: Buchungsdatum, Kostenstelle, Konto, Brutto- und Nettobetrag, Mehrwertsteuer-Code, Belegreferenz. Das ist Standard — die Frage ist die Tiefe der Mapping-Logik.
SAP FI / Business Central
Für Unternehmen mit SAP- oder Microsoft-Dynamics-Backbone läuft die Anbindung über Standard-APIs oder spezifische Konnektoren. Die Mapping-Logik (Kostenstelle, Konto, Reisende, Cost-Center) wird in der Implementierung definiert.
HR-Anbindung
Personalstammdaten (Mitarbeiter, Vorgesetzte, Kostenstellen-Zuordnung) kommen aus dem HRIS, dem Active Directory oder dem ERP. Damit wird Approval automatisch korrekt — auch bei Wechseln in der Organisation.
SSO und Identity
Single Sign-On (SAML/OIDC) ist Standard. Mitarbeitende loggen sich mit ihrem Unternehmens-Account in Atriis, Pay und Expense ein — kein separates Passwort, kein separates Onboarding.
Diese Anbindungen sind technisch Standard. Die Komplexität liegt in der Mapping-Logik — also wie die Kostenstellen-Hierarchie, die Spesen-Konten-Logik und die Mehrwertsteuer-Regeln im integrierten Setup abgebildet werden.
Implementierung im Mittelstand: Zeitachse und Aufwand
Eine integrierte Travel-Pay-Expense-Implementierung dauert im typischen Mittelständler sechs bis zwölf Wochen — abhängig von der Komplexität der ERP- und HR-Landschaft.
Phase 1 — Woche 1 bis 2: Analyse
- Auswertung der bestehenden Buchungs-, Zahlungs- und Spesenflüsse
- Kostenstellen- und Konten-Mapping-Logik
- Identifikation der ERP- und HR-Schnittstellen
- Datenschutz- und Compliance-Anforderungen
Phase 2 — Woche 2 bis 5: Konfiguration
- Atriis-Konfiguration mit Travel Policy
- Card-Issuer-Setup (Lodge Card, Corporate Cards, virtuelle Karten)
- Intertours-Expense-Konfiguration (Kategorien, Pauschalen, Approval)
- Integration mit Datev oder SAP FI
Phase 3 — Woche 5 bis 8: Pilot
- Rollout in einer Pilot-Abteilung (typischerweise Vertrieb oder Service)
- Schulung der Reisenden und der Approver
- Validierung der Datenflüsse, Korrekturen, Optimierungen
Phase 4 — Woche 8 bis 12: Voll-Rollout
- Schrittweiser Rollout in das gesamte Unternehmen
- Start des monatlichen Reporting-Cadence
- Steering-Committee-Setup
- Übergabe an den dedizierten Travel Manager bei Intertours
Ab Woche 12 läuft das integrierte Operating Model. Ab Monat 4 beginnen die ersten messbaren Einsparungen sichtbar zu werden, ab Monat 12 lässt sich eine sauber bereinigte Gesamtwirkung gegen Baseline dokumentieren.
Worauf Einkauf bei Integrations-Versprechen achten muss
Liegen die drei Module wirklich auf einer Datenbasis?
„Wir haben Schnittstellen" ist nicht Integration. Frage: Ist die Reise das primäre Datenobjekt, an dem Buchung, Zahlung und Belege hängen? Wenn nicht, ist es ein Tool-Stack — nicht ein integriertes Modell.
Gibt es einen einzigen Steuerungs-Cadence?
Ein monatlicher Reporting-Pack über alle drei Module, ein quartalsweises Steering, ein jährlicher Annual Review. Wenn jedes Modul seinen eigenen Reporting-Pack hat, fehlt die Integrations-Logik.
Wer ist Ihr einziger Ansprechpartner?
Bei Intertours: ein dedizierter Travel Manager, der die drei Module verantwortet. Bei Stand-alone-Stacks: drei separate Customer Success Manager, drei separate Eskalationspfade.
Wie ist die Datenqualität zwischen Buchung und Beleg?
Eine Hotel-Belastung über Lodge Card muss automatisch zur ursprünglichen Buchung verknüpft sein — ohne manuelle Übertragung. Wenn diese Verknüpfung nur über manuelle Belegeingabe entsteht, ist die Integration unvollständig.
Wie ist die Card-Issuer-Logik geregelt?
Welche Karten-Typen sind möglich (Corporate Card, Lodge Card, virtuelle Karte)? Welche Banken oder Card-Provider sind im Setup verfügbar? Welche Cashbacks fließen zurück ins Programm — und in welcher Höhe?
Kann das Setup mit Datev und SAP FI sauber umgehen?
Im deutschen Mittelstand ist die Datev-Schnittstelle Pflicht. Wer das nicht standardmäßig anbietet, schafft Einführungs-Reibung und Korrektur-Aufwand.
Lehre aus integrierten Mittelstands-Setups: Der Wert von Travel-Pay-Expense entsteht nicht im einzelnen Modul. Er entsteht im Datenfluss zwischen den Modulen. Wer drei beste Tools kombiniert, hat drei beste Tools — und keine Integration. Wer ein integriertes Operating Model wählt, hat einen besseren Prozess.
Häufige Fragen zu Expense + Payment + Travel
Technisch ja. Empfehlung im Mittelstand: alle drei zusammen. Wer nur eines einführt, hat zwar Wirkung im Modul — verliert aber die Integrations-Vorteile. Phasen-Implementierung (Travel zuerst, Pay nach drei Monaten, Expense nach sechs Monaten) ist möglich, wenn Ressourcen begrenzt sind. Die Daten- und Steuerungs-Logik wird von Anfang an integriert konzipiert.
Standardisierter Datev-Datenfluss mit Buchungssatz pro Reise und Spesenvorgang. Mapping-Logik (Konten, Kostenstellen, MwSt.-Codes) wird in der Implementierung definiert. Die Schnittstelle ist im Mittelstand vielfach erprobt.
Nein. Die meisten Mittelständler arbeiten mit einer Kombination aus zentraler Lodge Card (für Flüge, Hotels, Mietwagen über OBE) und persönlichen Corporate Cards für vielreisende Mitarbeitende. Mitarbeitende ohne Corporate Card erfassen ihre Spesen weiterhin über die Mobile App — die Erstattung läuft trotzdem schneller, weil OCR und Workflow automatisiert sind.
Bestehende Karten können in der Regel weiter genutzt werden — Intertours Pay konfiguriert den Setup so, dass bestehende Card-Issuer-Beziehungen erhalten bleiben, sofern technisch möglich. Bei Bedarf wird auf neue Issuer migriert (Cashback-Vorteil, bessere Konditionen, bessere Datenqualität).
Sämtliche Daten in EU-Rechenzentren, DSGVO-konform. Zugriffe nach Rollen-Logik (CFO, Travel Owner, Cost-Center-Verantwortliche, Audit). Personenbezogene Daten werden nicht für Modell-Training verwendet, sofern nicht explizit konfiguriert.
Drei Komponenten: (1) Servicepauschale für Travel-Manager-Steuerung, (2) transaktionsbasierte Komponente für Buchungen, (3) Card-Acquiring-Gebühren bei Pay. Bei nachgewiesener Einsparung von 2 bis 7 Prozent rechnet sich das Gesamt-Setup im ersten Jahr in der Regel deutlich — abhängig vom Reisevolumen.
Ab Phase 3 (Pilot, Woche 5 bis 8) ist der Effekt in der Pilot-Abteilung sichtbar. Ab Voll-Rollout (Woche 12) im gesamten Unternehmen. Die Bearbeitungszeit pro Spesenvorgang sinkt typischerweise um 60 bis 75 Prozent. Die Erstattungsdauer für persönliche Auslagen sinkt von 4–8 Wochen auf 1–2 Wochen.
SAP Concur ist eine Expense-Plattform mit Travel-Add-on, gebaut für Enterprise-Stacks mit SAP-Backbone. Intertours liefert ein integriertes Operating Model mit drei Modulen aus einem Haus, plus dediziertem Travel Manager als Steuerungsschicht — passend für mittelständische Unternehmen ohne Enterprise-IT-Tiefe. SAP Concur löst Compliance und Reporting auf Enterprise-Niveau. Intertours löst Kosten, Compliance und Reporting auf Mittelstands-Niveau — methodisch und mit messbarer Einsparung.
