When the journey shapes the destination: advanced ATP meets advanced intercompany

The structure is older than the system

Large groups are distributed by nature: production in one region, distribution centres in others, a sales company in every market. Before goods reach a customer they travel – production in country A, a regional DC in country B, another in country C, the market company in country D. Sometimes the chain simply mirrors the physical route. Often it does not: ownership changes hands for reasons that have nothing to do with logistics – tax, history, acquisitions – and sometimes several times inside a single country.

Why a corporation looks the way it does is not the subject here. What matters is that this structure sits deep in the company’s DNA. A group that has run a dozen company codes for twenty years will still run them after the S/4HANA programme. Nobody announces a transformation and simplifies the legal structure on the side. The structure is fixed.

And inside that fixed structure one question has been asked since the day it was created, and is asked again on the first day of every transformation: how does a sales order in market D get confirmed against the production plan in country A – when B and C stand in between?

Correct ATP, or a compliant intercompany flow?

Before S/4HANA this was hard. Not impossible – companies found creative answers – but hard enough that we have heard the question asked in ECC workshops in exactly this form: what matters more to us, a correct ATP or a correct and compliant intercompany flow?

The workarounds we have seen fall into two families. Some kept the intermediate legs virtual, so that the flow that matters – A to D – could run on standard ATP, and the changes of ownership were settled separately. Others translated the availability picture leg by leg, with pairs of purchase and sales orders, and accepted that the promise in D was only as current as the last handover. Every company built its own variant. Every variant was a compromise between the two goals.

By the time an S/4HANA programme starts, this legacy of compromises is part of the requirement list – and, like most inherited requirements, is rarely asked what it was originally defending. (We have written before about requirements that travel into a new system as sediment.)

What S/4HANA changed

The feature deserves a short reference, because it is a real change. With advanced intercompany sales and stock transfer, one stock transport order or sales order from A to D carries one availability check, and the sale-and-purchase steps between A, B, C and D are generated in the background by the Value Chain Monitor. The two-entity version arrived with S/4HANA 2022; the multistage variant, with one or more intermediate companies, came with S/4HANA 2025 FPS01.

For ATP this is a genuine simplification: one check, one promise, one document that means what it says. For intercompany it retires the old dilemma – the compliant flow is no longer the price of a correct ATP. SAP Learning covers both processes and the monitoring framework behind them in Executing the Advanced Intercompany Sales and Stock Transfer Process; the corresponding solution processes are 5D2 for advanced intercompany sales and 5HP for advanced intercompany stock transfer.

It is also fresh. Several of the technical questions we ran into while prototyping had no documented answer yet, and a few ended up as incidents with SAP. That is normal for functionality of this age – and it is an argument for testing it in a system rather than reading about it.

The question is not the feature

Our customers are excited by the new process, and they want to see what it actually means for them. But the moment we started to lay out how it would be introduced, the question shifted.

In a group of this size a big bang across A, B, C and D is often too risky to consider. The safer path is sequential – D first, then C, then B, then A. And as soon as the rollout becomes a sequence, “show us the new feature” is replaced by five other questions:

• What does the long-term to-be look like, with advanced ATP and advanced intercompany both in place?
• What is the interim process – the state the company will actually run in for a year or two?
• How do the old and the new system work together while both are live?
• How can availability information that originates in the legacy system be used in the new one?
• How does the interim process switch over to the to-be without a second implementation?

For the first question SAP provides documentation. For the other four there is no manual, because the answers depend on the group’s own structure. Finding them is an iterative process with real turning points – “that is probably not possible”, “should C go live together with D after all?” – and every turning point moves the scope.

Decide before the contract

This is why it matters more than a technical detail: the interim design decides the project plan. Running two systems in parallel for a year has a cost. A big bang has a risk. The two can only be weighed against each other once the interim process is understood well enough to price it.

And that comparison cannot be made mid-project. Once the plan is communicated, the contracts signed and the team on board, you do not switch from big bang to sequence. The change is too large. So a question that looks like a detail of the logistics design – where exactly ATP and intercompany meet – needs an answer before the programme is set up, not in its third workshop.

Prototype, don’t argue

This is what the ATP Vision Lab is for. We do not answer questions like this on slides. We build the scenario in a system – the to-be, the interim, the handover between them – and let the customer’s business and IT teams test it.

Two things happen when options stop being theoretical. First, the decision de-risks: the people who will run the interim process have seen it work, including the ugly parts. Second, the decision moves out of the IT department. Business does not sign off on an architecture diagram. It signs off on an order it confirmed itself, in a system, against a production plan two companies away.

By the time the programme starts, the business has already tested the key concept of the to-be. They know where they are going. That is a different starting position from a requirement list.

You cannot prototype ATP alone

There is a practical consequence to all of this that we did not fully anticipate. To test the promise, we had to build the chain it travels through – which meant prototyping the intercompany process itself, not only the availability check on top of it. That is not an ATP exercise. We did it together with the customer’s FI consultants, because the questions it raises are theirs: which documents are created, what is posted where, how the value chain is monitored, what the auditors will see.

The side effect was worth as much as the original objective. The customer did not only see how ATP behaves across the chain. They saw the intercompany process run end to end, in their own system, on their own structure – long before the programme that would introduce it. Finance had the same chance as logistics to ask questions while the answers could still change something.

And some of those questions were for SAP. When we built the prototype, the multistage variant did not exist yet.

That is the part worth pausing on. A decision of this size is usually deferred until the functionality can be seen – which in practice means deferring it until the programme is already running and the plan is already fixed. A prototype turns that around. It makes the open questions precise enough to put to SAP, early enough that the answers still shape the plan. Here they came back as a confirmation of the roadmap, and the implementation strategy could be settled while it was still a strategy.

The interim solution that outlived the interim

One more thing, and it is the reason this article exists.

In the engagement that produced the sketch above, the interim state looked like Figure 2: the market company was live on S/4HANA; production – and the plan behind it – still lived in the legacy system. D needed to confirm orders against a plan it could not see as supply.

The answer was to express the upstream production plan as product allocation in D – capacity per period, at the level where the constraint actually lives – and to net D’s own stock against it first, so that an order beyond the lead time would not consume future capacity for goods already standing in the warehouse. It was designed as a staging step: a way to give D a correct promise until A arrived on the same system.

It turned out to be more than that. What the interim design had actually produced was a division of labour along the commitment horizon – and that division makes just as much sense when every company is on S/4HANA.

Far out, the intercompany chain does not exist yet. No stock transport orders have been raised, nothing is committed, and the group still has freedom in how the demand will be sourced. What is real at that point is a constraint: what the upstream plan can produce in a given period. Here the shared constraint mechanism does the work. The order is promised against that capacity, with the market company’s own stock netted first, so future capacity is not spent on goods already standing in the warehouse.

Closer in, the chain becomes concrete. The stock transport orders are created, the legs between the companies are real documents – and from that moment advanced intercompany takes over the mechanics. It carries the confirmation through every leg and makes sure the postings behind it are exact.

Neither mechanism is doing the other’s job. Shared constraint capacity answers can we promise this at all, while the chain is still an intention. Advanced intercompany answers what exactly happens in each company, once it is a commitment. The interim design had found the handover point between them – and we have since built the first half into a standalone solution: Shared Constraint Availability.

These questions would have surfaced eventually. A sequenced rollout forces someone to answer how D promises against a plan it cannot see – if not before the programme, then during it. What changes is the circumstances. Inside a running programme the answer is found against a go-live date and judged by whether it holds until the next wave. Built in the Lab, ahead of the programme, it had room to be run, questioned and evaluated on its own merits, and that is why its second purpose became visible at all.

What is less certain is whether the question would have come up in the first place. It exists because of the sequence. A big bang has no interim stage – nobody would have needed to ask how a promise is made across a system boundary, and the alternative approach to the long-term check would most likely never have been considered. The rollout path did not only delay the destination. It changed it.

Ask ATP first

When advanced ATP meets advanced intercompany, the interesting question is not whether the feature works. It does. The question is whether your group can afford to switch it on everywhere at once – and what the promise to your customer looks like while it cannot.

Answer that before the contract, in a system, with the people who will run it. The feature will be waiting when you get there.