Why SAP Deliveries Are Not Grouping Correctly in Transportation Planning

The sales order is correct. The delivery is created on time. Everything upstream looks clean.

Then the delivery reaches transportation planning, and the result doesn’t match what anyone expected. Two trucks where one would have done. Loads that should have travelled together, planned apart. And somewhere in the middle of it, a planner quietly fixing the same thing by hand every morning, because the system keeps producing the same answer.

This is one of the more common complaints in SAP transportation planning, and it is rarely caused by the thing people blame first.

When deliveries don’t turn into the right transportation plan

Most teams notice the problem as a set of symptoms rather than a single fault:

• More shipments than the volume seems to justify
• Consolidation opportunities that get missed
• Planners regrouping requirements manually before they can plan
• Extra effort in carrier selection and route planning
• Planning cycles that take longer than they should
• A steady stream of planning exceptions

SCM CHAMPS sees this pattern regularly in SAP TM assessments — the deliveries are correct, and the gap sits somewhere else entirely.

The instinct is to look at the delivery. Something must be wrong with how the order was split.

Sometimes that’s true. Often it isn’t. In many cases the delivery is exactly what the sales process intended it to be. The gap sits between three layers that are configured separately and rarely reviewed together: how SD splits deliveries, how SAP TM converts those deliveries into Freight Units, and what the planning run is actually permitted to combine.

Each layer can be individually correct. The plan can still come out wrong.

One note on language before going further. What the business calls a shipment is a Freight Order in SAP TM. From here on, this article uses Freight Order.

How delivery grouping actually works, from order to execution

The chain is short, and it helps to see it in one line:

Sales Order → Outbound Delivery → Transportation Requirement → Freight Unit → Transportation Planning → Freight Order → Execution

The outbound delivery defines what needs to be delivered and how the order has been divided up. The split happens for sales and fulfilment reasons — shipping point, ship-to party, delivery date, route, and other criteria depending on the configuration.

The transportation requirement is how that delivery enters transportation planning. An outbound delivery becomes a delivery-based transportation requirement, which carries the transportation-relevant data forward.

A Freight Unit is a group of goods that SAP TM treats as a single transportation requirement for planning. It is the smallest unit the system plans and moves, and it carries the constraints planning has to respect.

Freight Unit Building converts those requirements into Freight Units. The logic lives in the Freight Unit Building Rule, which can be determined by condition — meaning different deliveries can be processed by different rules.

Transportation planning takes the Freight Units and decides which of them can travel together, producing Freight Orders.

Of those stages, two actually decide how transportation demand gets grouped — Freight Unit Building and planning. This is where most of the confusion starts.

Freight Unit Building can group in different ways depending on the strategy in the rule. It can create one Freight Unit per business document item, or group all compatible items of a single document, or consolidate as much as possible — and that last strategy does work across separate business documents, including delivery-based transportation requirements.

But the strategy is only half the answer. What matters just as much is how Freight Unit Building is triggered. Most implementations run it automatically, so Freight Units are created the moment the delivery is saved. In that mode there is nothing to consolidate with yet — the other deliveries haven’t arrived. Consolidating across documents at this stage requires Freight Unit creation to run as a batch or interactive step instead, which is a deliberate design decision rather than a default.

So the practical position for most organizations is this: if your Freight Unit Building runs automatically on delivery save, cross-delivery grouping is happening at the planning step, not before it. Confirming which mode you are running takes minutes and tells you which layer to investigate.

Why SAP deliveries don’t always group the way you expect

There are five recurring causes. Most real cases involve more than one.

The delivery split shapes what transportation planning receives

Take a simple example. Same customer, same destination, same week. SD creates two deliveries:

• Delivery 1 → 60 boxes
• Delivery 2 → 40 boxes

Each becomes its own delivery-based transportation requirement. With automatic Freight Unit Building, that produces:

• FU 1 → 60 boxes
• FU 2 → 40 boxes

The business expected one truck. It now has two separate transportation demands.

Nothing has malfunctioned. Freight Unit Building processed each requirement as it arrived. The delivery split has become part of what transportation has to work with — though how those requirements are finally grouped is still determined downstream, by the Freight Unit Building strategy in use and by the planning run.

If planning can consolidate them, the earlier split becomes invisible and nobody ever notices. If it can’t, the business sees two Freight Orders for what it thinks of as one shipment, and a planner starts fixing it manually.

The reverse case is just as common and harder to spot. A single delivery can produce several Freight Units when the Freight Unit Building Rule splits by criteria the business didn’t intend — by item, by product, or by a quantity limit, depending on how the rule is set up. One delivery goes in, four Freight Units come out, and the planner is left wondering where they came from.

And because Freight Unit Building Rules can be determined by condition, two deliveries that look identical to a business user can be processed by two different rules. This one is easily missed, because the deliveries themselves offer no visible clue that anything different happened.

SD and TM group for different reasons

A delivery is split for sales and fulfilment reasons. A transport is built for transportation reasons. These are not the same thing, and they were never designed to be.

The criteria that drive each side may include:

• Plant
• Shipping point
• Customer
• Route
• Delivery date
• Product or batch
• Destination
• Transportation-relevant attributes

A delivery might be split because two line items have different delivery dates. Transportation planning might want them on the same vehicle anyway, because the dates are two days apart and the truck passes the same door. Both positions are reasonable. The system will only reconcile them if someone has decided, deliberately, which one wins.

Data and timing differences

Freight Unit Building uses the data available at the moment the delivery is integrated into transportation planning. If key transportation-relevant information is missing, incomplete, or arrives later, the resulting Freight Units can look different from what the business expected.

Availability at planning time matters too. If the relevant Freight Units are not available or not selected together when the planning run executes, they cannot be considered together in that cycle. Requirements that were meant to travel together never meet.

This is one of the reasons the same order pattern can produce a good plan one day and a poor one the next, with no configuration having changed at all.

The business changed, the logic didn’t

Distribution models change. Companies add a hub, shift to direct-to-store, renegotiate delivery windows with major customers, or change how they consolidate for certain regions.

The delivery split logic and the Freight Unit Building Rules often stay exactly as they were designed — sometimes years earlier, for a network that no longer exists.

The result is a slow, quiet gap between how the business now wants goods moved and how SAP still creates transportation requirements. Nobody raises it as a system issue, because nothing broke. The planners simply absorb the difference manually, and it becomes normal.

Consolidation is blocked at the planning step

This is the layer that gets checked last and explains a large share of cases.

Even when the Freight Units are exactly right, the planning run may be unable to combine them. Common reasons include:

• Pickup or delivery time windows that don’t overlap
• Incompatibility settings that keep certain products, customers, or locations apart
• Capacity limits on the selected means of transport
• Missing or incorrect transportation lanes
• Selection settings that never bring the relevant Freight Units into the same planning run
• Planning profile settings that restrict what can be combined

The practical test is straightforward. If the Freight Units themselves look correct and the Freight Orders still don’t consolidate, the constraint is almost certainly in planning. Reviewing the delivery and the Freight Unit will not find it, no matter how long you spend there.

What this costs the business

The technical detail matters less to leadership than what it produces downstream.

The cost is rarely dramatic on any single day. That’s what makes it persistent. A planner spends twenty minutes regrouping requirements each morning, an extra vehicle goes out half full, and none of it is large enough to escalate.

Over a year, across a network, it can add up to real freight spend and a meaningful amount of planning capacity — and it may also mean transportation reporting no longer reflects how goods actually moved, because the plan in the system and the plan in practice have drifted apart.

How to find where the logic diverges

Working through the chain in order will usually locate the gap within a few examples. Take one case where the business expected a different result and follow it end to end.

Review the outbound delivery

Ask: why did SAP split this order into these particular deliveries?

Look at the attributes that differ between them — shipping point, ship-to party, delivery date, route. If two deliveries exist that the business expected to be one, the reason is usually visible right here.

Review the Freight Units

Ask: which Freight Unit Building Rule was applied, which strategy does it use, and how is Freight Unit creation triggered?

Three things to check. First, whether Freight Unit Building runs automatically on delivery save or as a batch step — this determines whether cross-delivery grouping is even possible at this stage. Second, whether one delivery was split into several Freight Units, and on what basis. Third, whether deliveries that look similar were processed by different rules, which happens more often than teams expect when rules are determined by condition.

Compare the grouping logic

Put the delivery criteria and the transportation criteria side by side and look for the differences that matter:

• Dates
• Locations
• Customers
• Routes
• Shipping points
• Plants
• Products
• Transportation attributes

The question is not which side is right. It is which difference is actually preventing the outcome the business wants.

Review the planning result

Ask: did the planning run combine those Freight Units the way the business expected, and if not, what prevented it?

Check whether the Freight Units were even selected into the same planning run. Then check time windows, incompatibilities, capacity, and transportation lanes. Only after that is it reasonable to conclude that Freight Unit Building is the problem.

Most investigations that go wrong go wrong here — by stopping at the Freight Unit, assuming the fault must lie in how it was built, and reconfiguring a rule that was working correctly all along.

How to fix delivery grouping problems

The instinct is to change a setting. That usually moves the problem rather than solving it, because the three layers are connected.

Map the end-to-end process

Order → Delivery → Transportation Requirement → Freight Unit → Planning → Freight Order → Execution.

Walk the actual process, not the documented one, and mark the point where what the business intends stops matching what the system produces.

Define the grouping rules you actually want

This is a business decision, and it needs to be stated explicitly before anything is configured.

Which deliveries should travel together? For many organizations the answer looks something like: same customer, same destination, compatible delivery window. The exact criteria depend on the transportation strategy, the customer commitments, and the network.

If this cannot be written down in a sentence, no configuration will produce it reliably.

Align all three layers

Review whether the delivery split rules, the Freight Unit Building Rules, and the planning settings — including incompatibilities, transportation lanes, and selection criteria — are all supporting the same objective.

Fixing one layer in isolation is the most common reason these problems come back.

Test real business scenarios

One order proves nothing. Test the situations that actually occur:

• Multiple deliveries for the same customer
• Multiple plants
• Different delivery dates
• Partial quantities
• Different routes
• Multiple customers on one vehicle
• Different destinations
• Deliveries that should consolidate and deliveries that must not

That last pair matters. A change that improves consolidation can also combine things that were deliberately kept apart.

Monitor the exceptions

After the changes go live, track the cases where expected grouping and actual grouping don’t match.

These exceptions are the early warning system. They show up long before anyone raises a complaint, and reviewing them periodically is what stops the same gap reopening the next time the business changes how it distributes.

In practice

A European consumer goods manufacturer running embedded TM in S/4HANA, with over 200 daily outbound deliveries, came to SCM CHAMPS with planners spending the first hour of every morning manually regrouping requirements the system kept splitting across separate trucks, even for identical customer destinations. The assumption internally was that the SD delivery split was creating too many deliveries from a single order.

The assessment traced it to the planning run. The Freight Units were correctly built and fully consolidatable, but the planning engine could not combine them because the delivery time windows—derived rigidly from requested delivery dates on the sales orders—did not overlap, even when the physical delivery could have occurred within a wider window.

The business had to first settle an explicit rule: deliveries for the same customer and destination could be planned together as long as the requested windows fell within the same calendar day and a ±3‑hour tolerance. With that decision made, the planning profile’s time‑window constraint was relaxed to allow consolidation across Freight Units whose windows overlapped within that tolerance, without changing any SD or Freight Unit Building logic.

Within one quarter, the daily manual regrouping step disappeared entirely. Regional freight orders dropped by 34% against the same delivery volume, and the planning team recovered over 20 hours per week of hands‑on correction time.

How SCM CHAMPS helps identify and fix SAP TM planning gaps

Most organizations dealing with this don’t need a new SAP TM implementation. They need to know which of the three layers is actually producing the wrong result — and that requires looking at the process end to end rather than at one configuration object.

SCM CHAMPS helps organizations work out whether the gap sits in the delivery logic, in Freight Unit Building, or in transportation planning — and then determine what actually needs to change. That work typically covers:

• Assessment of current SAP TM transportation processes
• SD-to-TM process alignment
• Analysis of delivery split, Freight Unit Building, and planning logic
• Identification of where the transportation plan diverges from business intent
• Identification of manual consolidation and planning workarounds
• Evaluation of SAP TM automation opportunities
• Translation of business transportation requirements into practical improvements

The goal isn’t simply to change how SAP creates Freight Units. It is to make sure the transportation planning logic reflects how the business actually needs to move goods.

Not sure whether your transportation planning issue comes from SD delivery splitting, Freight Unit Building, or the planning run itself?

SCM CHAMPS can assess the end-to-end process, identify the underlying gap, and determine where the improvement opportunities are.

→ Request a Free SAP TM Assessment

Fix the planning logic behind the problem

Incorrect delivery grouping is not really a configuration issue. It is a sign that four layers have stopped agreeing with each other:

Business requirement → SD delivery logic → Freight Unit Building → Transportation Planning

When they align, the plan comes out the way the business expects and nobody thinks about it. When they don’t, planners compensate manually — and because they are good at it, the underlying gap can stay hidden for years.

The objective is a transportation process where the delivery logic, the Freight Unit logic, and the planning logic all support the same thing: how the business actually wants to consolidate, plan, and move goods.

That usually starts with finding out which layer stopped agreeing, and when.