SAP Integration for European Road Freight Execution

SAP tells you what should happen

It does not tell you what will happen on the road. The transport is planned, the carrier is assigned, the document is issued, and from that moment the ERP is blind until somebody types a status into it. The gap is filled by phone calls, and the planner ends up maintaining a spreadsheet next to a system that cost seven figures.

This is the execution layer for that gap. The freight job leaves SAP, allocation happens against live carrier availability, and the confirmation and every subsequent event come back to the same record rather than to a parallel tool.

What crosses the boundary

How it connects, honestly

Over standard SAP interfaces rather than a certified add-on. Depending on your landscape that means IDoc, an OData or REST service, or a scheduled file exchange, and which one applies depends on whether you run ECC or S/4HANA and whether transportation management sits embedded or standalone. We agree the channel in scoping rather than assuming it.

The practical consequence of not being an add-on is the one your planner cares about: there is no transport into the SAP system itself, no object to install and no basis project to queue behind. That is what makes a seven-week GO LIVE possible in an estate where an in-system change would take two release cycles.

What this does not do

It does not replace transportation planning inside SAP, rewrite your master data or become the system of record for your freight orders. SAP stays authoritative for the order, the cost object and the financial flow.

What changes is that the execution half stops being invisible. If what you actually need is the developer-level view of the same events rather than an ERP interface, start at the road freight visibility API; if the question is which channel each of your carriers can sustain, that is API against EDI.

Carrier integration to SAP TM: the three options

Getting freight orders out of SAP is the easy half. The half that decides whether the project works is getting a fragmented European carrier base to report back into it, and there are only three ways to do that. Most estates end up running all three.

1. Carrier collaboration inside SAP. Carriers log into a portal and update status themselves. It works for the handful of large carriers who will accept another login, and it fails on the long tail, because a twelve-truck haulier will not staff a portal for one customer. The status you get is also keyed by hand, which is the weakest kind of timestamp.

2. Point-to-point EDI per carrier. Robust, auditable and the right answer where a carrier already runs EDI with you. The cost is that each connection is its own project of four to twelve weeks with a bespoke mapping, so it reaches your top five carriers and stops there. The channel comparison sits in API against EDI.

3. Platform aggregation. One integration into SAP, and the platform holds the carrier side: telematics providers for position, a driver app where there is no box, EDI where a partner can only send files. This is the option that reaches the long tail, because the connection is made once with each telematics provider rather than once with each haulier. The mechanics are on telematics integration.

The honest comparison: option 1 costs least and covers least, option 2 gives the highest data quality on the few carriers that can sustain it, and option 3 is what moves network coverage from roughly fifteen per cent of loads to most of them. They are not exclusive, and the right estate uses EDI for the carriers who already have it and aggregation for everybody else.

The seven weeks

GO LIVE is guaranteed in seven weeks, and the schedule is the same on every integration because the platform side never changes. What varies is how quickly your side can supply a test system and a named contact.

1. Weeks 1–2, scoping. We agree the field list, the direction of each field and which system is authoritative for it. This is the meeting that decides whether the project is easy, and skipping it is why integrations drift.
2. Weeks 3–4, connection. Credentials, endpoints and a first message moving in a test environment. Nothing is mapped yet, we are proving the pipe.
3. Week 5, mapping and events. Your fields onto our event model, including the definition of arrival, which is the single most disputed one.
4. Week 6, parallel run. Both systems live, event counts compared daily. Any gap is a mapping bug found before anybody depends on it.
5. Week 7, cutover and handover. Downstream consumers switch, monitoring is handed to your team with the reconciliation report that tells you when a feed goes quiet.

Data residency, GDPR and ISO 27001

Freight data is operational data about identifiable drivers and vehicles, so it falls under GDPR whichever way it reaches us. Three things are usually asked in a European security review, and the answers do not change per integration.

• Where the data sits. Processing and storage stay within the EU.
• Who can see it. Your freight data stays inside your trusted carrier network. A carrier sees the loads they are assigned, not your wider network.
• How it is governed. TrucksOnTheMap is ISO 27001 certified, and the controls that matter to a transport integration are access control, retention and the audit trail on every event.

Position data has a retention question of its own. Decide up front how long raw pings are kept as against derived events, because the derived events are what your KPIs need and the raw trace is what a works council will ask about.

Common questions

How does TrucksOnTheMap integrate with SAP?

Over standard SAP interfaces rather than an installed add-on. Depending on the landscape that means IDoc, an OData or REST service, or a scheduled file exchange, and which applies depends on whether you run ECC or S/4HANA and whether transportation management is embedded or standalone. The channel is agreed during scoping rather than assumed.

Is TrucksOnTheMap an SAP-certified add-on?

No. The integration runs over standard interfaces, which is deliberate: there is no transport into the SAP system, no object to install and no basis project to wait for. That is what makes a seven-week go-live realistic in an estate where an in-system change would take two release cycles.

What data goes back into SAP?

Carrier allocation and confirmation, the agreed rate where contracted that way, live position and ETA per drop, milestone events for loaded, arrived and delivered, the ePOD or eCMR document, and a delivery confirmation suitable for invoice matching. The freight order itself stays authoritative in SAP.

Does this replace SAP TM?

No. Transportation planning, the freight order, the cost object and the financial flow stay in SAP. What the platform adds is the execution layer: allocation against live carrier availability and the stream of events from the road that the ERP has no source for.

What are the options for carrier integration to SAP TM?

Three, and most estates run all of them. Carrier collaboration inside SAP, where carriers log into a portal and key their own status, which works for large carriers and fails on the long tail. Point-to-point EDI per carrier, which is robust and auditable but costs four to twelve weeks per connection with a bespoke mapping. And platform aggregation, one integration into SAP with the platform holding the carrier side through telematics providers, a driver app and EDI, which is the option that reaches the small hauliers.

Do we need an SAP project team to make this work?

Not a development team. What is needed is a named contact who can confirm the field list and direction, credentials, and a test system. Most of the seven weeks is spent agreeing what each field means and running both systems in parallel rather than building.

See it on your own landscape

Bring one freight order type and one lane. We will show it leaving SAP and the position, ETA and ePOD coming back against the same record.