Inhaltsverzeichnis
Fehlen für eine Spesenabrechnung entscheidende Telematikdaten, sollte der betroffene Fahrerfall nicht automatisch mit geschätzten oder unvollständigen Werten abgeschlossen werden. Stattdessen muss geprüft werden, ob die vorhandenen Informationen noch für eine eindeutige Berechnung ausreichen oder ob ein Prüffall erforderlich ist.
Entscheidend ist dabei nicht, ob sämtliche theoretisch verfügbaren Telematikdaten vorhanden sind. Relevant ist, ob Fahrer, Zeitraum, Orte und weitere für den konkreten Abrechnungsfall benötigte Informationen zuverlässig bestimmt werden können.
Was bedeutet ein Telematikausfall für die Spesenabrechnung?
Ein Telematikausfall bedeutet nicht zwangsläufig, dass ein komplettes Telematiksystem nicht mehr erreichbar ist.
Für die Spesenabrechnung ist bereits jede Situation relevant, in der eine für den Fahrerfall benötigte Information fehlt oder nicht zuverlässig verarbeitet werden kann.
Das können beispielsweise sein:
- fehlende Zeitinformationen,
- fehlende Positionsdaten,
- eine unterbrochene Datenfolge,
- eine fehlende Fahrerzuordnung,
- eine fehlende Fahrzeugzuordnung,
- unvollständige Tourinformationen,
- verspätet eintreffende Datensätze oder
- widersprüchliche Informationen aus mehreren Systemen.
Für den Abrechnungsprozess zählt deshalb nicht nur die technische Frage, ob eine Schnittstelle grundsätzlich funktioniert.
Entscheidend ist, ob für den konkreten Fahrerfall alle benötigten Informationen vorhanden sind.
Nicht jede Datenlücke verhindert automatisch die Berechnung
Eine wichtige Unterscheidung lautet:
Fehlende Daten sind nur dann kritisch, wenn sie für die konkrete fachliche Entscheidung benötigt werden.
Fehlt beispielsweise ein Datensatz, der für die Spesenberechnung überhaupt keine Rolle spielt, kann der Fahrerfall trotzdem vollständig sein.
Fehlt dagegen genau die Information, mit der Beginn, Ende, Fahrerzuordnung oder ein relevanter Ort bestimmt werden soll, kann eine eindeutige Verarbeitung unmöglich werden.
Deshalb sollte ein System nicht einfach prüfen:
„Sind alle theoretisch verfügbaren Telematikdaten vorhanden?“
Sondern:
„Sind alle für diesen konkreten Fahrerfall erforderlichen Informationen vorhanden?“
Welche Datenlücken sind besonders problematisch?
1. Fehlende Fahrerzuordnung
Eine der kritischsten Lücken ist eine nicht eindeutige Fahrerzuordnung.
Zeit- und Positionsdaten können technisch vollständig vorliegen. Wenn jedoch nicht eindeutig feststeht, welchem Mitarbeiter sie gehören, dürfen daraus nicht ungeprüft personenbezogene Spesenwerte entstehen.
Eine fehlende Fahrerzuordnung sollte deshalb grundsätzlich sichtbar werden.
2. Unvollständiger Zeitraum
Problematisch kann auch ein Fahrerfall sein, bei dem nur ein Teil des relevanten Zeitraums vorliegt.
Beispielsweise könnten Daten für den Beginn eines Einsatzes vorhanden sein, während das Ende fehlt.
Oder die Datenspur beginnt erst mitten im betrachteten Zeitraum.
Ob sich daraus trotzdem eine fachlich belastbare Abwesenheitszeit ermitteln lässt, hängt von den zusätzlichen Informationen und der hinterlegten Berechnungslogik ab.
3. Fehlende Positionsdaten
Positionsdaten können bei bestimmten Fahrerfällen notwendig sein, um Orte oder Tourverläufe nachvollziehen zu können.
Fehlen relevante Geo-Daten, kann beispielsweise eine Ortszuordnung nicht mehr eindeutig möglich sein.
Auch hier gilt: Nicht jeder fehlende GPS-Punkt ist automatisch kritisch. Entscheidend ist, ob dadurch eine für die Berechnung notwendige Information verloren geht.
4. Fahrer- oder Fahrzeugwechsel
Eine weitere Herausforderung entsteht, wenn Fahrer oder Fahrzeuge innerhalb des betrachteten Zeitraums wechseln und die Zuordnung nicht vollständig dokumentiert ist.
Dann können technisch korrekte Fahrzeugdaten vorhanden sein, ohne dass daraus eindeutig hervorgeht, welchem Mitarbeiter sie während des kompletten Zeitraums zuzurechnen sind.
5. Widerspruch zwischen verschiedenen Datenquellen
Eine Datenlücke muss nicht immer bedeuten, dass etwas vollständig fehlt.
Auch widersprüchliche Informationen können die automatische Verarbeitung verhindern.
Beispielsweise können:
- Telematikzeit und hinterlegte Arbeitszeit nicht zusammenpassen,
- eine Personalabwesenheit einem vorhandenen Einsatz widersprechen,
- Fahrer- und Fahrzeugzuordnungen voneinander abweichen oder
- Tour- und Positionsinformationen keinen konsistenten Verlauf ergeben.
Dann sind zwar Daten vorhanden – aber keine eindeutige Entscheidungsgrundlage.
Warum eine automatische Schätzung problematisch ist
Wenn Daten fehlen, erscheint eine technische Schätzung zunächst attraktiv.
Ein System könnte beispielsweise:
- den letzten bekannten Zeitpunkt übernehmen,
- eine durchschnittliche Fahrzeit annehmen,
- einen fehlenden Ort aus dem Tourverlauf ableiten oder
- einen Wert aus dem Vortag fortschreiben.
Für bestimmte technische Anwendungen können Schätzverfahren sinnvoll sein.
Bei einer abrechnungsrelevanten Entscheidung entsteht jedoch ein Problem:
Aus einer Annahme wird ein konkreter Auszahlungsbetrag.
Wenn eine solche Annahme verwendet wird, muss zumindest klar erkennbar sein, dass der Wert nicht auf einer vollständigen originären Datengrundlage beruht.
Für viele Fälle ist deshalb ein transparenter Prüffall sinnvoller als eine unsichtbare automatische Schätzung.
Prüffall statt falscher Sicherheit
Eine gute Automatisierung muss nicht jeden Fall automatisch abschließen.
Sie sollte vielmehr erkennen können, wann die Voraussetzungen für eine eindeutige Verarbeitung nicht erfüllt sind.
Dann kann der Fahrerfall in eine separate Prüfung überführt werden.
Der Vorteil:
- Der problematische Fall bleibt sichtbar.
- Automatisch verarbeitbare Fälle werden nicht aufgehalten.
- Die Verwaltung muss nicht den gesamten Monatsbestand erneut kontrollieren.
- Eine manuelle Entscheidung kann gezielt dokumentiert werden.
Damit wird der Telematikausfall nicht zum Grund, die gesamte Automatisierung abzuschalten.
Er wird zu einer Ausnahme innerhalb eines ansonsten strukturierten Prozesses.
Welche Informationen sollte ein Prüffall zeigen?
Ein Prüffall ist nur dann hilfreich, wenn der Sachbearbeiter verstehen kann, warum der Fall nicht automatisch abgeschlossen wurde.
Eine reine Meldung wie „Telematikfehler“ reicht dafür kaum aus.
Sinnvoll ist eine gemeinsame Darstellung der vorhandenen Informationen.
Dazu können gehören:
- Fahrer,
- Datum,
- vorhandene Arbeitszeit,
- ermittelte beziehungsweise bisher bekannte Abwesenheitszeit,
- Tourinformationen,
- Route,
- vorhandene Geo-Daten,
- konkrete Warnungen und
- aktueller Prüfstatus.
Je mehr relevanter Kontext direkt im Fahrerfall verfügbar ist, desto weniger muss die Verwaltung zur Ursachenanalyse zwischen verschiedenen Systemen wechseln.
Datenlücke oder fachlicher Sonderfall?
Diese beiden Situationen sollten getrennt werden.
Eine Datenlücke bedeutet, dass eine normalerweise erwartete Information fehlt oder nicht eindeutig ist.
Ein fachlicher Sonderfall kann dagegen auch bei vollständig vorhandenen Daten entstehen.
Beispiel:
Alle Telematikdaten sind vollständig. Für den Fahrer gilt an diesem Tag jedoch eine besondere betriebliche Regel, die bewusst nicht über den normalen Automatikprozess verarbeitet werden soll.
Dann liegt kein Telematikausfall vor.
Der Fall ist fachlich besonders.
Eine klare Trennung verhindert, dass technische und fachliche Ursachen miteinander vermischt werden.
Wie lässt sich eine Datenlücke sinnvoll klassifizieren?
Für größere Fahrerbestände kann es sinnvoll sein, Telematikprobleme nicht nur mit einem allgemeinen Status zu kennzeichnen.
Eine einfache Klassifikation könnte beispielsweise unterscheiden:
| Problemtyp | Beispiel | Mögliche Folge |
|---|---|---|
| Fahrer fehlt | Keine eindeutige Fahrerzuordnung | Manuelle Zuordnung erforderlich |
| Zeit fehlt | Beginn oder Ende nicht vollständig | Abwesenheitszeit prüfen |
| Geo-Daten fehlen | Relevanter Tourabschnitt ohne Position | Ortszuordnung prüfen |
| Daten widersprechen sich | Telematik und Personalstatus passen nicht zusammen | Quelle und Sachverhalt prüfen |
| Schnittstellendaten verspätet | Datensatz trifft erst später ein | Fall zunächst offen lassen |
Eine solche Trennung erleichtert nicht nur die Bearbeitung einzelner Fälle.
Sie hilft auch dabei, systematische Ursachen zu erkennen.
Warum die Ursache der Datenlücke wichtig ist
Wenn in einem Monat fünf Prüffälle auftreten, ist die reine Zahl nur begrenzt aussagekräftig.
Interessanter ist die Ursache.
Treten beispielsweise alle Fälle aufgrund derselben fehlenden Fahrerzuordnung auf, liegt möglicherweise kein individuelles Fahrerproblem vor, sondern ein Stammdaten- oder Integrationsproblem.
Wiederholen sich dagegen unvollständige Zeiträume bei bestimmten Fahrzeugen, sollte die technische Datenquelle genauer untersucht werden.
Ein strukturierter Prüfprozess kann damit langfristig auch die Datenqualität verbessern.
Was passiert bei einem kompletten Telematikausfall?
Ein besonders deutlicher Sonderfall ist ein längerer Zeitraum, in dem die normalerweise verwendete Telematik überhaupt keine verwertbaren Informationen liefert.
Dann muss geklärt werden, ob die erforderlichen Informationen aus anderen zuverlässigen Quellen rekonstruiert werden können.
Denkbare Informationen können – abhängig vom vorhandenen Prozess – beispielsweise aus:
- anderen vorhandenen Unternehmenssystemen,
- betrieblichen Zeitinformationen,
- Tourunterlagen oder
- einer kontrollierten manuellen Erfassung
stammen.
Welche Ersatzquelle fachlich zulässig und geeignet ist, muss das Unternehmen für seinen konkreten Prozess festlegen.
Die Software sollte diese Entscheidung nicht selbst erfinden.
Fallback bedeutet nicht automatisch „Wert vom Vortag“
Der Begriff Fallback wird technisch häufig mit einem automatischen Ersatzwert verbunden.
Bei Spesen sollte ein Fallback jedoch eher als definierter Ersatzprozess verstanden werden.
Dieser Ersatzprozess kann beispielsweise festlegen:
- Telematikdaten sind unvollständig.
- Der Fall wird nicht automatisch freigegeben.
- Eine definierte alternative Informationsquelle wird geprüft.
- Der Sachbearbeiter ergänzt beziehungsweise bestätigt den Fall.
- Die manuelle Entscheidung bleibt nachvollziehbar.
Das ist wesentlich belastbarer als ein unsichtbar eingefügter Standardwert.
Soll ein unvollständiger Fall im Monat offen bleiben?
Das hängt vom Zeitpunkt und vom betrieblichen Prozess ab.
Wenn Daten erfahrungsgemäß noch nachgeliefert werden, kann es sinnvoll sein, einen Fall zunächst nicht endgültig zu bearbeiten.
Treffen die Informationen später vollständig ein, kann der Fahrerfall erneut verarbeitet werden.
Steht dagegen fest, dass die fehlenden Daten nicht mehr verfügbar sein werden, muss eine kontrollierte Ersatzentscheidung getroffen werden.
Wichtig ist deshalb eine klare Unterscheidung zwischen:
- vorübergehend unvollständigen Fällen und
- endgültig nicht rekonstruierbaren Datenlagen.
Verspätete Daten und bereits abgeschlossene Monate
Besonders sensibel wird der Prozess, wenn Telematikdaten erst nach dem Monatsabschluss eintreffen oder nachträglich verändert werden.
Dann stellt sich die Frage, ob ein bereits abgeschlossener Abrechnungslauf nachträglich verändert werden darf oder ob eine Korrektur in einem separaten Prozess erfolgen muss.
Ein abgeschlossener Monat sollte deshalb nicht unbemerkt durch spätere Rohdatenänderungen einen neuen Stand erhalten.
Für eine nachvollziehbare Abrechnung ist wichtig, dass erkennbar bleibt, welcher Datenstand tatsächlich abgeschlossen wurde.
Warum ein fester Monatsabschluss wichtig ist
Während eines laufenden Monats können Daten ergänzt, geprüft und korrigiert werden.
Nach dem endgültigen Abschluss benötigt die Buchhaltung dagegen einen definierten Stand.
Ein sinnvoller Monatsprozess trennt deshalb:
- laufende Verarbeitung,
- offene Prüffälle,
- manuelle Sonderfälle und
- endgültig abgeschlossene Abrechnungen.
Damit ist klar, welche Informationen noch verändert werden können und welcher Stand bereits Grundlage der Abrechnung war.
Wie SpediFlow mit unklaren Fahrerfällen umgeht
SpediFlow trennt in der aktuellen Anwendung automatisch verarbeitete Fälle von Fällen, die geprüft werden müssen.
Im Bereich der Spesen-Prüfung werden auffällige Fahrerfälle separat dargestellt.
In den von dir dort einsehbaren Fällen stehen unter anderem Informationen zu:
- Fahrer und Datum,
- Arbeitszeit,
- Abwesenheitszeit,
- Route beziehungsweise Tour,
- Warnungen und
- Prüfstatus
zur Verfügung.
Damit muss ein auffälliger Fall nicht zwischen den normalen automatischen Fällen gesucht werden.
Automatische Fälle bleiben getrennt
Wenn die vorhandenen Daten für eine regelbasierte Verarbeitung ausreichen, wird der Fall im Bereich der automatischen Spesenfälle geführt.
Die Detailansicht zeigt dort unter anderem die verwendeten Zeit-, Tour- und Geo-Informationen sowie die erkannte Berechnungsregel.
Der Unterschied zum Prüffall liegt damit nicht darin, dass grundsätzlich keine Telematikdaten vorhanden wären.
Entscheidend ist, ob die vorhandene Datengrundlage für den konkreten Fall ausreichend eindeutig ist.
Manuelle Sonderfälle in SpediFlow
Neben automatischen Fällen und Prüffällen besitzt SpediFlow einen eigenen Bereich für manuelle Sonderfälle.
Damit können Ausnahmen bewusst getrennt vom normalen Automatikprozess erfasst werden.
Diese Trennung ist gerade bei Datenlücken sinnvoll:
Ein Sachbearbeiter kann eine notwendige manuelle Entscheidung treffen, ohne so zu tun, als wäre der Wert auf demselben automatischen Weg entstanden wie ein vollständig datenbasierter Fall.
Arbeitszeitregeln können zusätzliche Informationen liefern
SpediFlow verfügt außerdem über einen eigenen Bereich für Arbeitszeitregeln.
Dort können entsprechende Regeln und Zuordnungen hinterlegt werden.
Solche fachlichen Informationen können bei der Verarbeitung relevant sein, ersetzen aber nicht zwangsläufig jede fehlende externe Information.
Ob eine Regel für einen konkreten Datenlückenfall ausreicht, hängt von dessen Ursache ab.
Telematikausfall sollte nicht zum Standard-Sonderfall werden
Ein manueller Fallback ist wichtig. Er sollte allerdings nicht dazu führen, dass wiederkehrende technische Probleme dauerhaft akzeptiert werden.
Wenn dieselbe Datenlücke regelmäßig entsteht, sollte die Ursache untersucht werden.
Mögliche Ansatzpunkte sind beispielsweise:
- Stammdatenqualität verbessern,
- Fahrerzuordnungen korrigieren,
- Integrationslogik anpassen,
- Übertragungsintervalle prüfen oder
- mit dem Telematikanbieter klären, welche Daten tatsächlich bereitgestellt werden können.
Der Prüfprozess ist damit nicht nur ein Sicherheitsnetz für die Abrechnung, sondern auch ein Hinweisgeber für technische und organisatorische Schwachstellen.
Wie viele Prüffälle sind normal?
Dafür gibt es keine seriöse allgemeingültige Zahl.
Die Quote hängt unter anderem ab von:
- verwendeter Telematik,
- Datenqualität,
- Fahrer- und Fahrzeugzuordnungen,
- betrieblicher Komplexität,
- Anzahl der Sonderfälle und
- Strenge der hinterlegten Prüfregeln.
Eine niedrigere Prüffallquote ist außerdem nicht automatisch besser.
Wenn ein System problematische Fälle einfach automatisch verarbeitet, sinkt zwar die sichtbare Zahl der Warnungen – die Datenqualität wird dadurch aber nicht besser.
Eine bessere Kennzahl: Ursache der manuellen Arbeit
Für die Optimierung ist deshalb nicht nur interessant, wie viele Fälle manuell geprüft werden.
Interessanter ist:
Warum müssen diese Fälle geprüft werden?
Eine Auswertung könnte beispielsweise unterscheiden:
- fehlende Fahrerzuordnung,
- fehlende Zeitdaten,
- Geo-Datenlücke,
- widersprüchliche Abwesenheitsdaten,
- manueller Sonderfall oder
- andere betriebliche Ursache.
Damit lässt sich gezielt dort optimieren, wo tatsächlich wiederkehrende Arbeit entsteht.
Checkliste: Vorgehen bei einer Datenlücke
Für einen strukturierten Prozess kann eine Spedition bei einem unvollständigen Fahrerfall folgende Reihenfolge verwenden:
- Problem erkennen: Welche konkrete Information fehlt oder widerspricht sich?
- Relevanz prüfen: Wird diese Information für die konkrete Berechnung tatsächlich benötigt?
- Originalquelle prüfen: Ist der Datensatz nur verspätet oder technisch nicht verfügbar?
- Alternative Quelle prüfen: Gibt es eine verlässliche andere Informationsquelle?
- Fachliche Entscheidung treffen: Kann der Fall eindeutig ergänzt werden?
- Manuelle Änderung dokumentieren: Falls erforderlich, den Sonderfall getrennt behandeln.
- Ursache analysieren: Handelt es sich um einen Einzelfall oder ein wiederkehrendes Problem?
Damit wird aus einem Telematikausfall kein improvisierter Excel-Nachtrag, sondern ein definierter Teil des Abrechnungsprozesses.
Was sollte eine Spedition vor einer Integration klären?
Datenlücken lassen sich nicht vollständig verhindern. Viele Probleme können jedoch bereits vor der technischen Integration berücksichtigt werden.
Dazu sollten Fragen geklärt werden wie:
- Welche Daten sind für die Berechnung zwingend erforderlich?
- Welche Daten kann die Telematik zuverlässig liefern?
- Wie werden Fahrer und Fahrzeuge identifiziert?
- Wie werden Änderungen oder verspätete Datensätze übertragen?
- Wie erkennt das Zielsystem unvollständige Zeiträume?
- Welche alternative Datenquelle steht bei Ausfällen zur Verfügung?
- Wer darf einen Prüffall manuell korrigieren?
- Wie bleiben manuelle Entscheidungen nachvollziehbar?
- Was passiert mit nachträglichen Daten nach einem Monatsabschluss?
Diese Fragen gehören genauso zur Schnittstellendefinition wie Felder und API-Endpunkte.
Telematikausfall ist auch ein Architekturthema
Wer einen automatisierten Prozess plant, sollte nicht nur den Idealzustand modellieren.
Die interessantere Frage lautet:
Wie verhält sich das System, wenn etwas nicht funktioniert?
Eine robuste Architektur benötigt deshalb einen definierten Fehlerpfad.
Im Idealzustand:
Daten vollständig → Berechnung → Automatikfall.
Im Ausnahmezustand:
Daten unvollständig → Warnung → Prüffall → kontrollierte Entscheidung.
Genau diese zweite Kette entscheidet darüber, ob eine Automatisierung auch in der betrieblichen Realität funktioniert.
Fazit: Ein guter Prozess kann auch mit unvollständigen Daten umgehen
Telematikausfälle und Datenlücken lassen sich in einer realen Spedition nicht vollständig ausschließen.
Eine automatische Spesenabrechnung sollte deshalb nicht nur für perfekte Datenlagen entwickelt werden.
Entscheidend ist, wie sie mit Ausnahmen umgeht.
Ein belastbarer Prozess:
- erkennt fehlende oder widersprüchliche Informationen,
- prüft, ob die Lücke für die Berechnung relevant ist,
- verhindert eine unbemerkte automatische Fehlentscheidung,
- stellt den Fall gezielt zur Prüfung bereit,
- ermöglicht bei Bedarf eine kontrollierte manuelle Behandlung und
- hält abgeschlossene Abrechnungsstände nachvollziehbar.
Damit wird ein Telematikausfall nicht zum Gegenargument gegen Automatisierung.
Im Gegenteil: Er zeigt, warum gute Automatisierung einen geregelten Ausnahmeprozess benötigt.
Weiterführende Artikel
Die Grundlagen zum Einsatz von Telematikdaten erklären wir in Telematikdaten für die Spesenabrechnung: Leitfaden für Speditionen.
Welche Daten für den automatisierten Prozess konkret benötigt werden, zeigt Welche Telematikdaten braucht eine automatische Spesenabrechnung?.
Warum auch vollständige Telematikdaten zusätzlichen fachlichen Kontext benötigen, erklären wir in Telematikdaten allein reichen nicht: Welche fachlichen Informationen zusätzlich nötig sind.
Wie weit sich die Fahrerabrechnung insgesamt automatisieren lässt, lesen Sie in Automatische Spesenabrechnung für Lkw-Fahrer: Was lässt sich wirklich automatisieren?.
Die grundlegende Berechnung von Fahrer-Spesen behandeln wir außerdem in Spesenabrechnung für Berufskraftfahrer: Abwesenheitszeiten richtig berechnen.
