Too Many Freight Orders Created in SAP TM? How to Find the Real Cause

If SAP TM is creating too many Freight Orders and your planners are regrouping deliveries manually, then you need to analyse the following-  

1. The planning run first. Time windows, incompatibilities, capacity, lanes, and selection settings block more consolidation than anything else.
2. Freight Unit Building second. Check which rule was used, which strategy it applies, and whether it runs automatically or as a batch.
3. The SD delivery split last.

Most teams do this in reverse. They blame the delivery split, change a Freight Unit Building Rule that was working fine, and the problem comes back.

The problem, as most teams see it

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

Then the delivery reaches transportation planning, and the result is not what anyone expected. Two trucks where one would have been enough. Loads that should have travelled together, planned apart.

 And somewhere the planner is quietly fixing them manually, because the system isn’t able to schedule transportation as expected. 

This is one of the most frequent challenges with SAP transportation planning. And it is rarely caused by the thing people blame first.

Most teams notice it as a set of symptoms, not one clear fault:

• More shipments than the volume seems to need
• Consolidation chances that get missed
• Planners regrouping requirements by hand 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 is true. Often it is not. In many cases the delivery is exactly what the sales process meant it to be. The gap sits between three layers that are set up separately and are rarely reviewed together: how SD splits deliveries, how SAP TM turns those deliveries into Freight Units, and what the planning run is actually allowed to combine.

Each layer can be correct on its own. The plan can still come out wrong.

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

Which layer is your problem? A quick check

How Delivery Grouping Actually Works

Here is the sequence of how order fulfillment is actually handled.  

• Sales Order 
• Outbound Delivery  
• Transportation Requirement Created
• Freight Units Consolidated
• Transportation Planning
• Freight Order
• Execution

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

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

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

Freight Unit Building turns those requirements into Freight Units. The logic sits in the Freight Unit Building Rule, which can be found by condition — meaning different deliveries can be handled by different rules.

Transportation planning takes the Freight Units and decides which of them can travel together. The result is Freight Orders.

Out of all these stages, only two actually decide how transport 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 document item, or group all compatible items of one document, or consolidate as much as possible. 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 have not arrived. Consolidating across documents at this stage needs Freight Unit creation to run as a batch or interactive step instead. That is a deliberate design decision, not a default.

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

Why SAP deliveries don’t group the way you expect

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

1. The delivery split shapes what 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 gives you:

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

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

Nothing has gone wrong. Freight Unit Building handled each requirement as it arrived. The delivery split has simply become part of what transportation has to work with. How those requirements are finally grouped is still decided downstream — by the Freight Unit Building strategy in use, and by the planning run.

If planning can combine them, the earlier split becomes invisible and nobody notices. If it cannot, the business sees two Freight Orders for what it thinks of as one shipment, and a planner starts fixing it by hand.

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 did not 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 found by condition, two deliveries that look identical to a business user can be handled by two different rules. This one is easily missed, because the deliveries themselves give no visible clue that anything different happened.

2. 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 two different operations and need to be handled separately. 

The criteria that drive each side may include:

• Plant
• Shipping point
• Customer
• Route
• Delivery date
• Product or batch
• Destination
• Transport-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 settle it if someone has decided, deliberately, which one wins.

3. Data and timing differences

Freight Unit Building uses the data available at the moment the delivery enters transportation planning. If key transport-relevant information is missing, incomplete, or arrives later, the 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 reason the same order pattern can produce a good plan one day and a poor one the next, with no configuration having changed at all.

4. 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 transport requirements. Nobody raises it as a system issue, because nothing broke. The planners simply absorb the difference by hand, and it becomes normal.

5. Consolidation is blocked at the planning step

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

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

• 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 simple. If the Freight Units 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 is what makes it last. A planner spends twenty minutes regrouping requirements each morning, an extra vehicle goes out half full, and none of it is big enough to escalate.

Over a year, across a network, it adds up to real freight spend and a meaningful amount of planning capacity. It can also mean your 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 identify whether the problem is SD, Freight Unit Building, or planning

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

Step 1: 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 where the business expected one, the reason is usually visible right here.

Step 2: 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:

1. Automatic or batch? Does Freight Unit Building run automatically on delivery save, or as a batch step? This decides whether cross-delivery grouping is even possible at this stage.
2. One delivery, several Freight Units? Check whether one delivery was split into several Freight Units, and on what basis.
3. Different rules for similar deliveries? Check whether deliveries that look alike were handled by different rules. This happens more often than teams expect when rules are found by condition.

Step 3: 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
• Transport attributes

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

Step 4: Review the planning result

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

First 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 fair to conclude that Freight Unit Building is the problem.

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

How to Fix Delivery Grouping Problems

Solving Delivery Grouping Problems requires a strategic approach; otherwise, else it adds to problems instead of solving them.  

Ensure you map the end-to-end process, which includes –

• Order creation 
• Delivery 
• Transportation requirement
• Freight unit
• Planning 
• Freight orders
• Execution 

Instead of following a traditional approach, follow a strategic approach that actually works. 

Decide the grouping rules you actually want

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

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

commitments, and the network.

Align all three layers

Check 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 goal.

Test real business scenarios

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

• 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.

These exceptions are your early warning, and reviewing them frequently is what helps prevent the occurrence of exceptions.  

Can a New S/4HANA Version Release Fix This?

Not really. Newer releases add more control around the problem, but they do not remove the cause.

Recent S/4HANA releases have added things like mixed-loading checks during freight unit building and consolidation, packaging information carried from sales orders and deliveries into Freight Units, and warehouse-driven delivery splits through Advanced Shipping and Receiving (ASR). Each of these helps in a specific situation.

But two things are worth being clear about:

The ASR delivery split solves a different problem. It handles cases where what was planned cannot actually ship — stock is short, or the truck is full at the loading door. It is warehouse-driven, and it needs EWM. It is not a fix for deliveries that should have been grouped together in the first place.

More features means more places the logic can drift. SD still splits for sales reasons. TM still groups for transport reasons. Planning still applies its own constraints. Adding more options does not make those three layers agree — someone still has to decide what the business actually wants and make sure all three support it.

This is not a new problem. It has existed as long as SD and TM have been separate. It is simply one that most teams still diagnose in the wrong order.

In practice: a real case

A European consumer goods manufacturer running embedded TM in S/4HANA, with over 200 daily outbound deliveries, came to SCM CHAMPS with a familiar problem. Planners were spending the first hour of every morning manually regrouping requirements that the system kept splitting across separate trucks — even for identical customer destinations.

Internally, everyone assumed the SD delivery split was creating too many deliveries from a single order.

The assessment traced it to the planning run instead.

The Freight Units were correctly built and fully able to consolidate. The planning engine could not combine them because the delivery time windows — taken rigidly from requested delivery dates on the sales orders — did not overlap, even when the physical delivery could easily have happened within a wider window.

Before anything could be configured, the business had to 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.

Results within one quarter:

• The daily manual regrouping step disappeared entirely
• Regional Freight Orders dropped by 34% against the same delivery volume
• The planning team recovered over 20 hours per week of hand-correction time

A note for teams on newer releases: there is now a second route to this kind of problem. TM-based scheduling for sales orders calculates loading, transport and unloading times and returns confirmed delivery dates. That can produce more realistic delivery windows at order entry, instead of correcting unrealistic ones later in planning. It does not replace the business decision above — you still have to agree what “can travel together” means — but it can stop the problem being created in the first place.

Frequently asked questions

Why is SAP TM creating too many Freight Orders? Usually because the planning run cannot combine the Freight Units it was given. The most common blockers are delivery time windows that don’t overlap, incompatibility settings, capacity limits, missing transportation lanes, or selection settings that never bring the right Freight Units into the same run.

Why are my Freight Units not consolidating into one Freight Order? If the Freight Units themselves look correct, the constraint is in planning, not in Freight Unit Building. Check whether they were even selected into the same planning run first — that catches more cases than people expect.

How do I know if the problem is SD delivery splitting or Freight Unit Building? Take one real example and follow it. If two deliveries exist where the business expected one, look at the delivery split criteria. If one delivery produced several Freight Units, look at the Freight Unit Building Rule. If both look correct, the problem is in planning.

Why does one delivery create multiple Freight Units? Because the Freight Unit Building Rule is splitting by criteria the business did not intend — by item, by product, or by a split quantity. Check the strategy and the split quantities in the rule that was actually applied.

Two similar deliveries behaved differently. Why? Freight Unit Building Rules can be found by condition. Two deliveries that look identical to a business user can be handled by two different rules, and nothing on the delivery itself shows this.

Should Freight Unit Building run automatically or as a batch? It depends what you need. Automatic creation on delivery save is the common setup, but it cannot consolidate across deliveries, because the other deliveries have not arrived yet. Cross-document consolidation at this stage needs batch or interactive creation.

What blocks consolidation in the SAP TM planning run? Time windows that don’t overlap, incompatibilities, vehicle capacity limits, missing or wrong transportation lanes, selection settings, and planning profile restrictions.

Can a newer S/4HANA release fix delivery grouping problems? Newer releases add useful controls, but they do not remove the cause. SD and TM still group for different reasons, and the three layers still have to be aligned deliberately.

How SCM CHAMPS helps

Most companies 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 needs an end-to-end look at the process, not a look at one configuration object.

SCM CHAMPS helps organisations work out whether the gap sits in the delivery logic, in Freight Unit Building, or in transportation planning — and then decide 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
• Identifying where the transportation plan diverges from business intent
• Identifying manual consolidation and planning workarounds
• Evaluating SAP TM automation opportunities
• Turning 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 problem comes from SD delivery splitting, Freight Unit Building, or the planning run itself?

SCM CHAMPS can assess the end-to-end process, find the underlying gap, and show you where the improvement opportunities are.

→ Request a Free SAP TM Assessment

The real fix

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 agree, the plan comes out the way the business expects and nobody thinks about it. When they don’t, planners compensate by hand — and because they are good at it, the underlying gap can stay hidden for years.

The goal 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.