JTL-Fulfillment als Dienstleister: Start, Kosten und Reporting-Pflichten.

Wer als Fulfillment-Dienstleister mit JTL-WaWi arbeitet, stößt früher oder später auf das JTL-Fulfillment-Network. Es klingt nach einer Lösung für genau das Problem, das jeden 3PL-Betrieb beschäftigt: Händler anbinden, Bestand synchron halten, Leistung nachweisen. Das FFN löst den ersten Teil gut. Den zweiten Teil - was am Ende des Monats an SLA-Nachweis, Mitarbeiterleistung und Abrechnung auf dem Tisch liegen muss - deckt es nur teilweise ab.

Das JTL-Fulfillment-Network (JTL-FFN) verbindet Händler-Systeme mit Fulfillment-Dienstleistern und standardisiert Anbindung, Lager und Abrechnung.

Welche Bausteine gehören zu JTL-Fulfillment?

JTL-Fulfillment ist kein einzelnes Produkt, sondern ein Zusammenspiel aus drei Bausteinen des JTL-Ökosystems. Wer als Dienstleister Fulfillment auf JTL-Basis anbietet, arbeitet praktisch immer mit allen dreien - in unterschiedlicher Tiefe:

• JTL-WaWi (eazybusiness) - die Warenwirtschaft und zugleich die Datenbasis. Hier liegen Aufträge, Artikel, Bestände, Mandanten und alle Bewegungsdaten. Jede Auswertung, jede Abrechnung und jedes Reporting speist sich am Ende aus dieser Datenbank. Wie eine read-only Auswertungsschicht direkt darauf aufsetzt, zeigt die JTL-Anbindung.
• JTL-WMS - die Lagersteuerung: Picklisten, Wegeoptimierung, Verpackungsprozess, Wareneingang. Das WMS erzeugt die Bewegungsdaten (wer hat wann was gepickt und gepackt), auf denen Leistungskennzahlen beruhen. Lizenziert wird es pro Mandant.
• JTL-FFN - das Fulfillment-Network als Vermittlungs- und Anbindungsschicht zwischen Händler-Systemen und Fulfiller-Lagern. Es macht aus zwei getrennten JTL-Installationen einen durchgängigen Auftrags- und Bestandsfluss.

Für Händler bedeutet JTL-Fulfillment: Ware an einen Dienstleister geben, der das JTL-Ökosystem spricht - ohne Schnittstellenprojekt. Für den Dienstleister bedeutet es: ein standardisierter Weg, Mandanten anzubinden und das Lager zu steuern. Was keiner der drei Bausteine mitbringt, ist die Auswertungsebene des Fulfiller-Betriebs selbst - dazu unten mehr.

Was ist das JTL-Fulfillment-Network?

Was es ist. Das JTL-FFN ist eine Vermittlungs- und Anbindungsschicht innerhalb des JTL-Ökosystems. Sie bringt Händler, die ihre Ware auslagern wollen, mit Fulfillment-Dienstleistern zusammen, die freie Lagerkapazität und Kommissionierleistung anbieten. Beide Seiten arbeiten dabei mit JTL-WaWi beziehungsweise eazybusiness, wodurch Aufträge, Bestand und Versandmeldungen ohne Dateiexport oder manuelle Übergabe zwischen den Systemen fließen.

Warum es entstanden ist. Vor dem FFN lief die Anbindung eines Fulfillers an einen Händler meist über individuelle Schnittstellen oder manuelle Prozesse: CSV-Import, E-Mail-Bestelllisten, eigene API-Anbindungen. Das FFN ersetzt diesen Wildwuchs durch ein standardisiertes Verfahren, das beide Seiten in ihrer jeweiligen JTL-Installation abbilden. Für den Fulfiller bedeutet das: ein Weg, neue Mandanten technisch anzubinden, statt für jeden neuen Händler eine eigene Lösung zu bauen.

Was es konkret regelt. Drei Bereiche stehen im Zentrum: die Anbindung (Auftragsübergabe vom Händler-System ins Fulfiller-Lager), der Lagerabgleich (Bestandsstände zwischen beiden Systemen synchron halten) und die Grundlage der Abrechnung (welche Mengen und Leistungen zwischen Händler und Fulfiller in Rechnung gestellt werden). Das FFN ist damit in erster Linie eine Prozess- und Datenbrücke, keine eigenständige Auswertungsplattform.

Wie nimmt man als Dienstleister am JTL-FFN teil?

Voraussetzung. Wer als Fulfiller am JTL-FFN teilnehmen will, braucht eine laufende JTL-WaWi (eazybusiness) mit aktiviertem FFN-Modul. Ohne diese Basis gibt es keinen Zugang zum Netzwerk - das FFN ist kein separates System, sondern ein Aufsatz auf der bestehenden Warenwirtschaft.

Der Ablauf. Der Dienstleister legt ein Fulfiller-Profil im Netzwerk an und hinterlegt darin die Rahmendaten, die für Händler relevant sind: angebotene Leistungen (Kommissionierung, Verpackung, Retourenbearbeitung), Lagerstandorte, Kapazitäten und Konditionen. Über dieses Profil werden Fulfiller für Händler auffindbar und anbindbar. Die eigentliche technische Kopplung - Auftragsübergabe, Bestandsabgleich, Versandrückmeldung - läuft danach automatisiert über die FFN-Schnittstelle zwischen den beiden JTL-Installationen.

• Fulfiller-Profil mit Leistungen und Kapazitäten im Netzwerk anlegen und pflegen
• Mandanten-Setup in der eigenen WaWi so anlegen, dass FFN-Aufträge sauber einem Mandanten zugeordnet sind
• Bestandsführung und Cut-Off-Zeiten technisch mit dem Händler-System abstimmen, bevor der erste Live-Auftrag läuft

Typischer Stolperstein. Die technische Anbindung ist meist schneller erledigt als die organisatorische Vorbereitung. Wer FFN-Mandanten wie klassische 3PL-Mandanten ins bestehende Lager integriert - inklusive eigener Cut-Off-Zeit, eigener SLA-Zusage, eigenem Reporting-Bedarf - vermeidet, dass FFN-Aufträge im Betrieb zu einer Art Sonderfall werden, der separat behandelt werden muss. Wie Mandanten grundsätzlich sauber getrennt und ausgewertet werden, steht im Leitfaden zum Mandanten-Reporting.

Was kostet die Teilnahme am JTL-FFN?

Die Teilnahme am JTL-Fulfillment-Network hat drei Kostenblöcke, von denen nur einer auf der Preisliste steht:

WMS-Lizenz pro Mandant. JTL-WMS wird je Mandant lizenziert - Stand 2026 rund 119 Euro pro Monat und Mandant (aktuelle Konditionen bei JTL prüfen). Das ist der wichtigste strukturelle Kostenfaktor, weil er linear mit jedem angebundenen Händler wächst: Zehn FFN-Mandanten bedeuten zehn WMS-Lizenzen, unabhängig davon, wie viel Volumen jeder einzelne bringt. Kleine Mandanten müssen diese Fixkosten erst einmal wieder einspielen.

FFN-Nutzungsgebühren. Für die Vermittlung und Abwicklung über das Netzwerk berechnet JTL Gebühren nach dem jeweils aktuellen Preismodell. Die Konditionen ändern sich gelegentlich - vor der Kalkulation eines neuen Mandanten gehört ein Blick in die aktuelle JTL-Preisliste.

Onboarding- und Betriebsaufwand. Der stillste, oft größte Block: Mandant in der WaWi anlegen, Stammdaten und Bestände abgleichen, Cut-Off-Zeiten und Prozesse abstimmen, Reporting-Erwartungen klären. Dieser Aufwand fällt pro Händler an - egal ob FFN oder klassisch - und entscheidet mit darüber, ab welcher Auftragsmenge sich ein Mandant überhaupt rechnet.

Alle drei Blöcke gehören in die eigene Preisfindung eingerechnet. Wie daraus ein belastbarer Preis pro Pick, Pack und Auftrag wird, zeigt Schritt für Schritt der Leitfaden Fulfillment-Preise kalkulieren.

FFN-Anbindung oder klassischer Mandant?

Nicht jeder Händler kommt über das Netzwerk. Viele Fulfiller fahren beide Wege parallel: FFN-Mandanten aus dem Netzwerk und klassisch angebundene Mandanten mit eigenem Setup in der WaWi. Die Unterschiede im Überblick:

Die letzte Zeile ist der Punkt, der in der Entscheidung gern übersehen wird: Beim Reporting nehmen sich beide Wege nichts. Ob ein Mandant über das FFN oder klassisch angebunden ist - die vertragsfeste SLA-Quote, die Mitarbeiterleistung und der betriebsweite Blick fehlen in beiden Fällen gleichermaßen.

Was zeigt das FFN-Portal Händlern?

Die Perspektive ist die des Händlers. Das FFN-Portal ist primär für den Händler gebaut, der seine Ware bei einem oder mehreren Fulfillern liegen hat. Er sieht darin im Wesentlichen drei Dinge: den aktuellen Bestand je Lagerort, Retouren, die im Fulfiller-Lager eingegangen sind, und ob die vereinbarten Cut-Off-Zeiten eingehalten wurden.

• Bestand je Artikel und Lager - was aktuell beim Fulfiller verfügbar ist
• Retouren, die dem Fulfiller-Lager zugegangen sind und den Bestand wieder erhöhen
• Eine Ja/Nein-Sicht auf eingehaltene Cut-Off-Zeiten je Auftrag oder Zeitraum

Was das für den Fulfiller bedeutet. Diese Sicht ist mandantenbezogen und bewusst schmal gehalten: Sie beantwortet dem Händler seine Frage ("Ist meine Ware da, kommt sie pünktlich raus"), nicht die Frage des Fulfillers ("Wie steht mein Betrieb insgesamt da, über alle Mandanten hinweg, und was beweise ich im nächsten Vertragsgespräch"). Das FFN-Portal ist ein Kunden-Frontend, kein Betriebs-Cockpit.

Wo endet die native FFN-Auswertung?

Kein vertragsfestes SLA-Reporting. "Eingehaltene Cut-Off-Zeit" ist eine binäre Information, keine belastbare SLA-Quote. Es fehlt die Logik, die ein Reporting vertragsfest macht: Werktage von Wochenenden und Feiertagen trennen, Rückhalte und Stornos aus der Wertung nehmen, unterschiedliche Fristen je Mandant sauber abbilden. Ohne diese Regeln ist jede Quote entweder zu streng (jedes Wochenende zählt als Bruch) oder zu grob, um im Kundengespräch zu bestehen.

Kein betriebsweiter Blick. Das FFN-Portal zeigt jedem Händler seine eigene Sicht - es aggregiert nicht über alle Mandanten hinweg zu einer Betriebssicht. Für den Fulfiller, der wissen muss, wie das gesamte Lager an einem Tag läuft, welcher Mandant welchen Anteil der Kapazität bindet und wo Engpässe entstehen, liefert die native FFN-Auswertung keine Antwort.

Keine Versandleistung pro Mitarbeiter. Personalsteuerung ist im FFN gar nicht vorgesehen. Wie viele Pakete ein Mitarbeiter pro Stunde schafft, wo Leistungsschwankungen zwischen Schichten liegen, welche Mandanten überproportional Kapazität binden - all das bewegt sich außerhalb dessen, was FFN als Anbindungsschicht abbilden soll.

Keine abrechnungsfeste Mengenbasis über Mandanten hinweg. Das FFN liefert die Grundlage der Abrechnung zwischen Händler und Fulfiller für den jeweiligen Mandanten. Ein konsolidierter Mengen-Export für die eigene Rechnungsstellung, der alle Mandanten - FFN und klassisch - in einer Struktur zusammenführt, ist damit nicht automatisch gegeben.

Wie schließt max.dash die Lücke?

max.dash ist ein read-only Operations-Cockpit für Fulfillment-Dienstleister (3PL). Wir lesen dein Lagersystem rein lesend mit und liefern SLA-Reporting pro Mandant, Leistung pro Mitarbeiter, ein mandantengetrenntes Kundenportal und Abrechnungs-Mengen-Export - ohne Systemwechsel.

Das heißt konkret: Die Cut-Off-Information, die das FFN-Portal binär zeigt, wird im SLA-Reporting zu einer vertragsfesten Quote - mit Werktagslogik, Feiertagen und den individuellen Fristen jedes Mandanten. Die fehlende Betriebssicht entsteht im Cockpit auf der JTL-Wawi, das alle Mandanten - FFN-Aufträge eingeschlossen - in einer gemeinsamen Ansicht zusammenführt, statt sie mandantenweise zu isolieren. Und die Mengenbasis für die eigene Rechnungsstellung liegt strukturiert in der Abrechnung, unabhängig davon, ob der Auftrag über das FFN oder klassisch angebunden wurde.

max.dash ersetzt das FFN dabei nicht - es liest neben der WaWi auch die über FFN abgewickelten Daten mit und ergänzt die Auswertungsebene, die das Netzwerk nicht mitbringt. Kein Plugin, keine Migration, kein Eingriff in die laufende Anbindung.

Ist das auch ohne FFN relevant?

Die beschriebene Lücke - fehlendes SLA-Reporting, fehlender betriebsweiter Blick, fehlende Mitarbeiterleistung - besteht unabhängig davon, ob ein Fulfiller überhaupt am JTL-FFN teilnimmt. Wer ausschließlich klassische 3PL-Mandanten ohne FFN-Anbindung betreut, steht vor derselben Auswertungsfrage: Die JTL-WaWi speichert die Rohdaten, liefert aber keine vertragsfeste SLA-Quote und keine mandantengetrennte Leistungsauswertung von Haus aus. max.dash setzt an dieser Stelle unabhängig von der Anbindungsart an - für FFN-Mandanten genauso wie für Mandanten, die auf klassischem Weg angebunden sind.

Und wer gar kein JTL im Lager hat, sondern ein anderes Warenwirtschafts- oder Lagerverwaltungssystem betreibt? Auch dann bleibt die eigentliche Lücke bestehen: Jedes System kennt Aufträge, Mandanten und Versandstatus, nur unter anderen Tabellen- und Feldnamen als eazybusiness. max.dash liest solche Systeme genauso lesend mit wie die JTL-WaWi - welche Anbindungen es gibt, steht in der Übersicht der Lagersysteme.