Braucht Frachtkosten-Software eine ERP- oder TMS-Integration?

Bei neuer Logistiksoftware entsteht schnell die Annahme: Bevor wir anfangen können, müssen wir erst unser ERP oder TMS integrieren.

Dann wird aus einem fachlichen Frachtkostenprojekt schnell ein IT-Projekt. Schnittstellen müssen definiert, Datenfelder gemappt und interne Ressourcen eingeplant werden. Die eigentliche Frage – Frachtkosten analysieren, Rechnungen prüfen oder eine Ausschreibung auswerten – rückt in den Hintergrund.

Für Frachtkosten-Software ist eine direkte ERP- oder TMS-Integration jedoch nicht automatisch Voraussetzung für den Einstieg.

Entscheidend ist zunächst: Welche Frage wollen wir beantworten? Und danach: Welche Daten brauchen wir dafür?

ShipCheck kann Rechnungs- und Sendungsdaten unter anderem aus PDF, Excel und CSV verarbeiten. Damit können Unternehmen bereits mit vorhandenen Transportdaten arbeiten, ohne zwingend zuerst eine vollständige Systemintegration aufzubauen.

Der zentrale Unterschied lautet: Datenzugang und Systemintegration sind nicht dasselbe.

Der bessere Startpunkt: Use Case statt Schnittstelle

Statt mit der technischen Architektur zu beginnen, sollte ein Frachtkostenprojekt vier Fragen beantworten: Use Case → benötigte Daten → Datenquelle → Übertragungsweg.

1. Use Case

Was soll die Software konkret tun? Zum Beispiel:

• Frachtkosten analysieren
• KPI-Reporting aufbauen
• Frachtrechnungen prüfen
• Ausschreibungsangebote vergleichen

Wie ein solches Reporting konkret aussehen kann, zeigt der Beitrag zu Frachtkosten-Reporting-Software.

2. Benötigte Daten

Welche Informationen sind für diesen Anwendungsfall erforderlich?

3. Datenquelle

Wo liegen diese Informationen heute? Zum Beispiel:

• ERP
• TMS
• Speditionsrechnung
• Carrier-Datei
• Tarifvertrag
• Excel-Export

4. Übertragungsweg

Wie gelangen die Daten in die Frachtkosten-Software? Zum Beispiel:

• PDF
• Excel
• CSV
• regelmäßiger Export
• technische Integration

Diese Reihenfolge ist wichtig. Denn eine API beantwortet nur: Wie gelangen Daten von A nach B? Sie beantwortet nicht: Sind es die richtigen Daten für unseren Anwendungsfall?

Welche Daten braucht Frachtkosten-Software?

Das hängt davon ab, was mit der Software gemacht werden soll.

Frachtkostenanalyse

Für eine Frachtkostenanalyse müssen die relevanten Transporte und Kosten nachvollziehbar sein. Je nach gewünschter Auswertung können beispielsweise wichtig sein:

• Sendung
• Datum
• Spediteur
• Relation
• Verkehrsträger
• Gewicht
• Kosten

Damit lassen sich unter anderem Kosten nach Spediteur, Relation oder Verkehrsträger sowie Kosten pro Sendung und Entwicklungen über Zeit auswerten. Wie granular das werden kann, beschreibt der Beitrag zur Frachtkostenanalyse auf Sendungsebene.

Die fachliche Voraussetzung lautet also: Die relevanten Transport- und Kostendaten müssen verfügbar und auswertbar sein. Nicht: Sie müssen zwingend über eine direkte ERP-Schnittstelle kommen.

Für die Rechnungsprüfung kommen Tarifdaten hinzu

Bei der Frachtrechnungsprüfung reicht die reine Kostenhistorie nicht aus. Hier werden zwei Seiten benötigt:

• Ist: Was wurde fakturiert?
• Soll: Was hätte nach den vereinbarten Konditionen berechnet werden müssen?

Dafür braucht die Software:

• Rechnungsdaten
• relevante Sendungsinformationen
• vereinbarte Tarife und Konditionen

Die Tariflogik wird auf die konkrete Sendung angewendet und anschließend mit der Fakturierung verglichen. Wie Tarife dafür maschinell nutzbar werden, zeigt der Beitrag Frachttarife digitalisieren.

Die entscheidende Frage lautet daher nicht: „Ist unser ERP integriert?“ Sondern: „Sind die Daten vorhanden, um die vertraglichen Sollkosten für die Sendung zu berechnen?“

Für Tendering werden historische Sendungsdaten benötigt

Auch bei Frachtausschreibungen steht nicht die Integration im Mittelpunkt. ShipCheck nutzt historische Transportdaten, um neue Speditionsangebote auf das tatsächliche Sendungsprofil anzuwenden.

Dafür braucht es eine belastbare Historie der relevanten Transporte. Neue Tarife können anschließend auf diese Sendungen gerechnet und miteinander verglichen werden – siehe Frachtausschreibung auswerten.

Wenn zukünftige Mengen von der Historie abweichen, können zusätzlich Forecast-Daten in die Berechnung einfließen.

Gerade bei einer Ausschreibung kann deshalb ein strukturierter historischer Datensatz wichtiger sein als eine permanente Live-Schnittstelle.

Daten müssen verfügbar sein – nicht zwingend live integriert

Ein Unternehmen besitzt relevante Transportdaten häufig bereits. Zum Beispiel als:

• Excel-Export aus dem TMS
• CSV-Datei aus dem ERP
• PDF-Rechnung des Spediteurs
• strukturierte Rechnungsdatei
• historische Sendungsliste
• Tarif-PDF oder Tarif-Excel

Diese Daten können bereits eine ausreichende Grundlage für einen konkreten Use Case bilden. Wie sich aus solchen Exporten Auswertungen gewinnen lassen, beschreibt Speditionsrechnungen und Sendungsdaten auswerten.

Die Frage sollte deshalb zuerst lauten: „Können wir die benötigten Daten zuverlässig bereitstellen?“ und erst danach: „Müssen wir dafür eine direkte Schnittstelle bauen?“

Wann kann man ohne direkte ERP- oder TMS-Integration starten?

Ein Start ohne direkte Schnittstelle ist insbesondere dann realistisch, wenn die benötigten Daten bereits regelmäßig exportiert oder bereitgestellt werden können.

Beispiel: Frachtkosten-Reporting

Ein monatlicher Export enthält:

• Sendung
• Datum
• Spediteur
• Relation
• Verkehrsträger
• Gewicht
• Kosten

Damit können bereits Fragen beantwortet werden wie: Wie entwickeln sich unsere Frachtkosten? Wie hoch sind die Kosten pro Sendung? Welche Spediteure verursachen welchen Kostenanteil? Welche Relationen verändern sich?

Welche Kennzahlen dafür sinnvoll sind, zeigt der Beitrag zu Frachtkosten-KPIs. Dafür muss nicht zwingend zuerst eine individuelle Schnittstelle gebaut werden.

Beispiel: Frachtrechnungsprüfung

Rechnungsdaten, relevante Sendungsinformationen und die vereinbarten Tarife liegen vor. Dann kann geprüft werden: Was wurde fakturiert? gegen: Was hätte laut Tarif berechnet werden müssen?

Auch hier ist die Datenverfügbarkeit die fachliche Voraussetzung – nicht die Integration. Typische Abweichungen beschreibt systematische Fehler in Speditionsrechnungen.

Beispiel: Frachtausschreibung

Historische Sendungsdaten liegen als strukturierter Export vor. Neue Anbieterpreise können auf diese reale Transportstruktur angewendet werden. Eine permanente Integration ist dafür nicht zwingend der erste Schritt.

Wann wird eine ERP- oder TMS-Integration sinnvoll?

Dass eine Integration für den Einstieg nicht immer notwendig ist, bedeutet nicht, dass sie keinen Mehrwert hat. Sie wird insbesondere dann interessanter, wenn ein Frachtkostenprozess dauerhaft und regelmäßig betrieben wird.

Wenn laufend neue Daten hinzukommen

Für eine einmalige Tenderanalyse kann ein historischer Export ausreichen. Bei laufendem Frachtkostencontrolling kommen dagegen ständig neue Sendungen, Rechnungen und Kostenpositionen hinzu.

Dann kann eine stärker automatisierte Datenversorgung den wiederkehrenden manuellen Aufwand reduzieren.

Wenn mehrere Datenquellen zusammenkommen

Unternehmen mit mehreren Gesellschaften, Standorten, ERP-Systemen, TMS-Systemen oder Spediteuren haben häufig eine fragmentierte Datenlandschaft. Je häufiger dieselben Datenströme verarbeitet werden müssen, desto sinnvoller kann ein standardisierter Übertragungsweg werden.

Wenn zusätzliche operative Informationen benötigt werden

Rechnungen liefern vor allem Kosteninformationen. Für bestimmte Analysen können zusätzliche Sendungs- oder Unternehmensdaten aus ERP und TMS relevant sein. Welche Felder tatsächlich benötigt werden, hängt aber vom Use Case ab.

Wenn manuelle Übergaben reduziert werden sollen

Ein regelmäßiger Dateiimport kann für manche Unternehmen völlig ausreichen. Andere möchten diesen Schritt stärker automatisieren. Dann ist Integration eine Prozessoptimierung – nicht zwangsläufig die Voraussetzung, überhaupt mit Frachtkostenmanagement beginnen zu können.

Integration ist kein Ersatz für Datenqualität

Eine technische Schnittstelle löst nicht automatisch ein fachliches Datenproblem. Wenn beispielsweise:

• Carrier uneinheitlich benannt sind,
• Relationen fehlen,
• Kostenpositionen nicht sauber zugeordnet werden können,
• relevante Sendungsmerkmale fehlen,

macht eine automatische Übertragung diese Informationen nicht automatisch analytisch brauchbar.

Eine Schnittstelle löst die Frage: Wie übertragen wir Daten? Datenqualität löst die Frage: Können wir diese Daten sinnvoll auswerten?

Für Frachtkostenanalyse ist deshalb häufig nicht die technisch eleganteste Übertragung entscheidend, sondern die Vollständigkeit und Nutzbarkeit des Datensatzes.

Rechnungsdaten, Tarifdaten und ERP/TMS-Daten erfüllen unterschiedliche Aufgaben

Eine sinnvolle Trennung lautet:

Daraus ergeben sich unterschiedliche Kombinationen:

• Rechnung + Tarif + Sendungsdaten = Frachtrechnungsprüfung
• Sendungsdaten + Kosten = Frachtkostenanalyse
• historische Sendungsdaten + neue Tarife = Tendering

Die technische Integration ist nur ein möglicher Übertragungsweg für diese Daten.

Muss Frachtkosten-Software ein TMS ersetzen?

Nein. Ein TMS und spezialisierte Frachtkosten-Software erfüllen nicht zwangsläufig dieselbe Aufgabe. Ein TMS kann operative Transportprozesse und die dazugehörigen Sendungsdaten verwalten.

ShipCheck konzentriert sich auf die wirtschaftliche Nutzung von Transportdaten, Rechnungen und Tarifinformationen für Frachtkostenanalyse, Reporting, vertragliche Rechnungsprüfung und Tendering.

Das vorhandene TMS kann dabei eine wichtige Datenquelle bleiben. Die Einführung von Frachtkosten-Software bedeutet deshalb nicht automatisch, dass das bestehende Transportmanagementsystem ersetzt werden muss.

Und welche Rolle spielt das ERP?

Auch ein ERP kann wichtige Informationen liefern. Aber die für Frachtkostenmanagement relevanten Daten liegen häufig nicht nur dort. Je nach Unternehmen befinden sich Informationen beispielsweise verteilt in:

• ERP: Auftrags- und Unternehmensdaten
• TMS: operative Transportdaten
• Speditionsrechnung: fakturierte Kosten
• Tarifvertrag: vereinbarte Preislogik

Die Herausforderung besteht deshalb häufig darin, relevante Informationen aus mehreren Quellen für einen konkreten Frachtkosten-Use-Case gemeinsam nutzbar zu machen.

So sollte ein Frachtkostenprojekt starten

Schritt 1: Use Case definieren

Welche Frage soll beantwortet werden? Zum Beispiel: Wo steigen unsere Frachtkosten? Werden unsere Rechnungen tariflich korrekt abgerechnet? Welches Speditionsangebot passt wirtschaftlich zu unserem Sendungsprofil?

Schritt 2: Benötigte Daten bestimmen

Welche Informationen braucht genau dieser Use Case?

Schritt 3: Datenquellen identifizieren

Wo liegen diese Informationen heute?

Schritt 4: Einfachsten sinnvollen Übertragungsweg wählen

Kann zunächst mit PDF, Excel, CSV oder einem bestehenden Export gearbeitet werden?

Schritt 5: Wiederkehrende Datenversorgung optimieren

Wenn der Prozess dauerhaft betrieben wird, kann anschließend geprüft werden, welche Übertragung sinnvoll automatisiert werden sollte.

Damit lautet die Architektur: Use Case → Daten → Datenquelle → Übertragungsweg. Und nicht: Integration → Daten → irgendwann Anwendungsfall.

Wie ShipCheck mit unterschiedlichen Datenquellen arbeitet

ShipCheck kann Rechnungs- und Sendungsdaten unter anderem aus PDF, Excel und CSV verarbeiten und strukturiert auswertbar machen. Diese Datenbasis kann anschließend für mehrere Frachtkostenprozesse genutzt werden.

• Frachtkostenanalyse: Transportkosten nach unterschiedlichen Dimensionen analysieren und Entwicklungen sichtbar machen.
• Rechnungsprüfung: Fakturierte Positionen gegen hinterlegte Tarife und Konditionen prüfen.
• Tendering: Historische Transporte mit neuen Anbieterpreisen und Szenarien berechnen.

Der zentrale Grundsatz lautet damit: Frachtkostenmanagement braucht die richtigen Daten. Es braucht nicht zwangsläufig vom ersten Tag an eine vollständige ERP- oder TMS-Integration.

Fazit: Erst den Use Case lösen, dann die Datenversorgung optimieren

Eine ERP- oder TMS-Integration kann für Frachtkosten-Software sehr sinnvoll sein. Aber sie sollte nicht automatisch als Voraussetzung für den Projektstart verstanden werden.

Wenn Rechnungs-, Sendungs- und Tarifdaten bereits über PDF, Excel, CSV oder andere verwertbare Exporte verfügbar sind, können Analyse, Audit oder Tendering je nach Use Case bereits darauf aufbauen.

Die sinnvollere Reihenfolge lautet: Use Case definieren → Daten bestimmen → Datenquelle identifizieren → geeigneten Übertragungsweg wählen → Datenversorgung bei Bedarf weiter automatisieren.

So wird aus einem fachlichen Frachtkostenproblem nicht unnötig zuerst ein umfangreiches IT-Projekt. Die zentrale Frage lautet nicht: „Ist unser ERP bereits integriert?“ Sondern: „Haben wir die richtigen Daten, um unsere Frachtkostenfrage zu beantworten?“

Ein Blick auf die Abo-Modelle zeigt, wie ein Einstieg ohne IT-Projekt aussehen kann.