Across SAP S/4HANA migrations, one message is becoming hard to ignore: Internal Orders are no longer the model SAP is designing for.

In greenfield public cloud environments, that shift is explicit. Project-based structures built on SAP WBS elements are the default. In brownfield environments, Internal Orders may remain, but the direction is the same.

For most organizations, this creates a tension:

• Do we need to change?
• Will this make things more complex?
• Or is this an opportunity to fix what has never quite worked in our CapEx processes?

The mistake is to treat this as a technical decision. Moving from Internal Orders to WBS elements is not about replacing one SAP object with another. It is a shift in how costs are structured, controlled, and connected across the lifecycle of a project.

Internal Orders were built to collect costs.
WBS elements are designed to control projects.

That difference becomes critical when both capital and operational spend needs to be:

• Planned before execution
• Controlled as work progresses
• Reported consistently across projects and portfolios

In this blog, we break down what this shift really means in practice. You’ll understand where Internal Orders fall short, how SAP WBS elements change the model, and what to consider when redesigning capital project creation in S/4HANA.

The Core Shift: From Cost Collectors to Structured Project Controls

At the centre of this transition is a fundamental change in how SAP expects organizations to manage cost.

SAP WBS (Work Breakdown Structure) elements are hierarchical objects used to plan, control, and report on project costs, activities, and timelines. In S/4HANA, they form the structural backbone of project-based cost management.

Internal Orders and SAP WBS elements are not interchangeable objects. They are built on different assumptions about how work should be structured and controlled.

Internal Orders provide a simple way to assign spend to a defined bucket, but that simplicity comes with limits. The structure is flat, relationships between costs are minimal, and once defined, the coding is difficult to adapt. As projects become more complex, reporting and coordination quickly move outside SAP into spreadsheets.

This is why many teams describe Internal Orders as passive. They record what has happened, but they do little to control what happens next.

SAP WBS elements change that model entirely. A WBS structure introduces a hierarchical view of a project. Instead of a single cost object, the project is broken down into logical components, whether by phase, asset, or work package. Each level becomes part of a connected structure that can be planned, executed, and reported consistently.

More importantly, the WBS is not just a cost object. It becomes the point where multiple business processes intersect.

Costs are still captured, but they are now tied to:

• Activities and schedules
• Procurement and supplier engagement
• Progress tracking
• Budgeting and forecasting
• Standardized reporting across the portfolio

This is the shift SAP is driving toward in S/4HANA.

The WBS becomes the object that controls both costs and the business processes that generate them.

For CapEx and project-based OpEx, this is a material change. Instead of managing disconnected cost lines, organizations gain a consistent model that aligns planning, execution, and reporting within a single framework.

Why SAP WBS Elements are Replacing Internal Orders in S/4HANA

The move toward SAP WBS elements is not arbitrary. It reflects a broader shift in how SAP has redesigned S/4HANA around simplicity, standardization, and real-time insight. Watch the full walkthrough below, where we break down why Internal Orders fall short for even ‘simple’ projects, and how WBS elements give you better CapEx control.

At a platform level, SAP is reducing the number of object types used to manage financial and operational data. The goal is not just technical simplification, but consistency. Fewer objects, used more consistently, make it easier to standardize processes, reporting, and governance across the enterprise.

This is where WBS structures align directly with SAP’s direction.

Unlike Internal Orders, which were often used in isolation, WBS elements provide a standardized way to structure projects across business units, geographies, and asset classes. That consistency becomes critical in S/4HANA environments where organizations are trying to move away from fragmented processes toward unified models of execution.

Just as importantly, the core strengths of S/4HANA reinforce the WBS model.

Real-time reporting is only valuable if the underlying data is structured in a way that can be aggregated and compared. A flat collection of Internal Orders limits that visibility. A hierarchical WBS structure enables it.

Cross-functional integration follows the same logic. Procurement, finance, project delivery, and asset accounting are no longer treated as separate activities. They are connected through shared objects and processes, with the WBS acting as the anchor point.

At a global level, this creates something most organizations have historically struggled to achieve: consistent visibility across all capital and project-based spend, regardless of where or how it is executed.

This is the underlying reason for the shift.

Internal Orders capture cost, but they were never designed to support structured, enterprise-wide capital governance.

WBS elements align directly to that requirement in S/4HANA.

Where Internal Orders Break Down

The limitations of Internal Orders are not theoretical. They show up in how capital and project-based spend is managed day to day.

On the surface, Internal Orders appear simple. But that simplicity quickly becomes a constraint as soon as projects move beyond basic cost tracking.

The first issue is structure. Internal Orders do not provide a meaningful hierarchy. Each order exists largely in isolation, limiting their use to small, discrete pieces of work. As projects scale into programs or portfolios, there is no natural way to group related investments, track phases, or break work into logical components.

When using Internal Orders, organisations typically rely on “order groups” for reporting. However, this approach introduces rigidity, as naming conventions and coding structures are difficult to change once established. If poorly designed, they lead to inconsistencies and unreliable reporting over time. These groups—whether manually maintained or inferred from order numbers—are fragile, governance-heavy, and prone to error. Embedding logic in naming conventions further limits flexibility, making structural changes complex and reliant on rework rather than true redesign. In contrast, WBS elements offer a native hierarchy that supports scalable structuring, consistent aggregation, and more adaptable reporting as project complexity grows.

This is where most organizations start to compensate outside SAP. Spreadsheets are used to rebuild what the system cannot represent. Phases are tracked manually. Relationships between costs are implied rather than structured. Over time, the system of record and the system of understanding begin to drift apart.

Integration is the next constraint. Internal Orders have limited connection to the broader processes that drive cost. Procurement, scheduling, and forecasting often sit adjacent to the order rather than being embedded within it. This creates gaps between planning and execution, where commitments, timelines, and actuals are not fully aligned.

For finance teams, this becomes a visibility problem. Costs are recorded, but the context behind those costs is fragmented. Forecasting becomes reactive. Reporting becomes an exercise in stitching together multiple data sources rather than relying on a single, standardized structured.

This is why many organizations find themselves converting data repeatedly, rather than working from a stable, structured model. Data is exported, reworked, and reinterpreted just to create a usable view of project performance.

At that point, Internal Orders are no longer supporting the process. They are being worked around. Or as it is often described in practice: “they hold costs,” but the relationships between those costs, and the reporting required to make sense of them, remain clunky.

What WBS Unlocks for Capital Projects

The move to SAP WBS elements is not just about alignment with S/4HANA. It fundamentally changes what organizations can control, see, and manage across their projects.

Where Internal Orders fragment cost, WBS structures bring it together.

1. Structured Capital Control

SAP WBS elements enable organizations to break capital projects into logical structures that reflect how work is actually delivered.

Projects can be organized by:

• Phases such as design, build, and commission
• Components such as equipment, civil, or electrical

This creates a clear structure for both execution and reporting.

Instead of tracking costs at a single level, teams can assign accountability to specific parts of the project. Progress, spend, and responsibility are aligned to the same structure, improving both control and oversight.

2. Integrated Planning, Budgeting, and Forecasting

WBS brings planning and execution into the same model.

Budgets can be defined at both project level and WBS levels, allowing for more granular control. This enables organizations to move beyond static budgets and toward dynamic forecasting.

Forecasts can be driven by real commitments, not just assumptions.
Spend can be aligned to delivery timelines, rather than tracked after the fact.

The result is a more accurate and forward-looking view of project performance.

3. True Cost Visibility

One of the most immediate benefits of WBS is improved capex visibility.

Costs are no longer captured as disconnected transactions. They are tied directly to specific parts of the project structure.

This allows organizations to:

• Capture vendor costs, internal labor, and equipment usage in a single model
• Assign those costs to defined phases, assets, or components
• Understand not just how much has been spent, but where and why

For finance teams, this transforms reporting from aggregation to insight.

4. Direct Integration with Execution

WBS connects cost to the processes that generate it.

Each SAP WBS element can be linked directly to:

• External activity driving Purchase Requestions
• Components driving requirements
• Supplier contracts
• Activities and schedules

This creates a direct line between planning and execution. Procurement decisions, delivery timelines, and cost commitments are all tied back to the same structure.

In practice, this means suppliers can be linked into the WBS, with costs scheduled overtime and aligned to delivery dates.

It also strengthens capex approvals, ensuring that approved spend flows directly into structured, executable project elements rather than sitting disconnected from delivery.

5. Better Portfolio Reporting

Standardized WBS structures enable consistent reporting across all projects.

When projects follow the same structural logic, data can be aggregated and compared without manual intervention. This supports more meaningful portfolio-level analysis.

Organizations can:

• Roll up costs and progress by phase across all projects
• Track metrics such as ESG performance consistently
• Compare investments across business units and geographies

With S/4HANA, this extends further through global hierarchies, allowing organizations to manage and report on capital portfolios at an enterprise level.

How SAP WBS Elements Apply to CapEx and OpEx Projects

WBS structures are not limited to capital investments. They provide a consistent way to manage both CapEx and project-based OpEx within the same framework.

The difference lies in how costs are treated, not how they are structured.

CapEx Projects

For capital investments, WBS elements support the full lifecycle of asset creation.

They enable:

• Structuring investment measures across phases and components
• Tracking work-in-progress (WIP) as costs are incurred
• Managing capitalization in line with project progress
• Settling costs to fixed assets once complete

This creates a clear line between project execution and managing fixed assets, ensuring that capital spend is accurately captured, controlled, and transitioned into the asset register.

OpEx Projects

For operational spend, WBS provides the same structural discipline without the requirement for capitalization.

Organizations can:

• Manage project-based operational spend in a structured way
• Assign costs to defined activities or components
• Maintain visibility and control without asset creation

This is valuable where operational initiatives still require coordination, accountability, and reporting, but do not result in capital assets.

The key advantage is consistency.

Both CapEx and OpEx projects can be managed within the same structural model, enabling clearer reporting, better control, and more aligned decision-making across the portfolio.

Design WBS Structures: Key Decisions That Matter

Moving to SAP WBS elements is not just about adopting a new structure. It is about designing a model that can scale, remain consistent, and support decision-making over time.

The quality of the structure determines whether WBS becomes an enabler or a source of complexity.

1. Project Structure

The first decision is how projects are defined.

Some organizations create one project per initiative. Others group related initiatives into larger programs. There is no single answer, but the structure must reflect how investments are planned, approved, and reported.

Within each project, the next decision is how to break down the WBS. Two common approaches are:

• Structuring by phase, such as design, build, and commission
• Structuring by component, such as equipment, civil, or electrical

The right approach depends on what needs to be controlled and reported. In many cases, a combination of both is used, but it must remain consistent across projects to be effective.

2. Depth of WBS

Depth is one of the most common failure points.

If the structure is too shallow, there is not enough detail to control cost, track progress, or assign accountability.

If it is too deep, the model becomes difficult to maintain. Users struggle to navigate it, and reporting becomes unnecessarily complex.

The goal is balance. Enough detail to support control and visibility, without introducing overhead that slows execution.

A consist standardized level for the assignment of costs is highly recommended. This greatly aids reporting.

3. Templates and Standardization

Without standardization, WBS structures quickly diverge.

Templates are critical for maintaining consistency across projects. They ensure that similar types of work are structured in the same way, enabling reliable reporting and comparison.

For recurring project types, this becomes even more important. A standard WBS structure allows organizations to:

• Apply consistent tagging and classification
• Compare performance across projects
• Aggregate data without manual rework

Over time, templates become the foundation for portfolio-level insight, not just project-level control.

4. Budgeting Approach

Budgeting design must align with how the organization plans and governs capital.

Some organizations manage budgets annually, aligning to financial cycles. Others manage budgets across the full lifecycle of the project.

The right approach depends on factors such as:

• Governance requirements
• Funding models
• Organizational structure

What matters is that the budgeting logic aligns with the WBS structure. If the two are disconnected, reporting and control will break down regardless of how well the system is configured.

Making WBS Work in Practice with SAP Fiori

One of the biggest concerns with moving to WBS is complexity.

Traditional SAP GUI transactions made project structures difficult to create, maintain, and govern. As a result, many teams avoided structured models altogether and defaulted to simpler objects like Internal Orders.

That constraint no longer applies. With SAP Fiori, the user experience has shifted significantly. Project creation, WBS maintenance, and workflow approvals can now be managed through intuitive, role-based applications rather than technical transactions.

This changes how WBS is adopted in practice. The complexity still exists, but it sits in the model, not in the user experience.

When designed correctly, users are not exposed to the full depth of the structure. Instead, they interact with guided processes that reflect how work is actually performed.

This is where well-designed Fiori applications make the difference. Custom Fiori apps can:

• Enforce standardized project and WBS templates
• Embed governance rules directly into the workflow
• Simplify decisions for users at the point of entry
• Drive consistency across projects without relying on manual discipline

The result is a structured model that does not feel complex to operate. For organizations moving from Internal Orders, this is a critical enabler. Without a simplified user experience, WBS can be seen as a step backward. With the right approach, it becomes a step toward more controlled, consistent, and scalable project execution.

Internal Orders Migration Risks and Pitfalls

Moving from Internal Orders to WBS can deliver significant benefits, but it is not without risk.

Most issues do not come from SAP itself. They emerge when well-intended design decisions are applied inconsistently or without considering how the model will be used in practice.

1. Over-Engineering the Structure

One of the most common mistakes is overcomplicating the WBS design.

• Too many levels.
• Too many rules.
• Too many edge cases built into the structure.

While the intent is often to capture every scenario, the result is a model that is difficult to use and even harder to maintain.

Complexity at the design stage quickly becomes friction in execution.

2. Lack of Standardization

At the other end of the spectrum, some organizations move too quickly without defining standards.

Without templates and consistent structures, SAP WBS elements begin to diverge across projects. Naming conventions vary, levels are used inconsistently, and reporting becomes fragmented.

The result is the same problem Internal Orders created, just in a different form. Standardization is what enables WBS to scale. Without it, the benefits do not materialize.

3. Ignoring User Experience

It is possible to design a technically correct WBS structure that no one can use.

If users struggle to create projects, assign costs, or navigate the structure, they will find workarounds. This often leads back to spreadsheets, defeating the purpose of the migration.

User experience is not a secondary concern. It is a core part of making WBS work in practice.

4. Treating It as a Technical Migration

This is where many programs lose momentum. If the move to WBS is treated as a system change, the focus stays on configuration rather than outcomes. The structure may be implemented correctly, but the underlying processes remain unchanged.

The shift to WBS should be approached as a change in how capital is governed. That includes:

• How projects are defined and approved
• How budgets are structured and controlled
• How performance is measured and reported

When approached this way, the value becomes clear. When it is not, WBS can feel like unnecessary complexity.

Well-designed Fiori applications can help remove perceived complexity by embedding governance into guided workflows, rather than relying on users to interpret the structure themselves.

5. Underestimating Change Management

Even with the right structure and tools, adoption is not automatic.

Teams need to understand not just how to use WBS, but why the change matters. Processes often need to be redesigned, and stakeholders across finance, procurement, and project delivery must be aligned.

Without this, inconsistencies emerge quickly.

Process-driven, workflow-enabled Fiori applications can support this transition by guiding users through standardized steps, improving adoption, and ensuring more consistent execution across projects.

How to Successfully Move from Internal Orders to WBS

A successful transition from Internal Orders to SAP WBS elements requires more than configuration. It is driven by clarity in how projects should be structured, governed, and executed.

The organizations that get this right start with business intent, then align SAP to support it.

Step 1: Start with Use Cases, Not SAP Objects

The first step is to define what you are trying to control.

• Is the focus on individual projects?
• Programs made up of multiple initiatives?
• Or portfolio-level investment decisions?

These questions determine how WBS structures should be designed. Starting with SAP objects too early often leads to technical solutions that do not align with how the business actually operates.

Step 2: Define Standard Structures

Once the use cases are clear, the next step is to define how projects will be structured consistently.

This includes:

• WBS templates for common project types
• Naming conventions that support reporting
• Defined levels within the structure

Standardization is what allows WBS to scale. Without it, reporting becomes fragmented and governance becomes difficult to enforce.

Step 3: Align to CapEx Governance

WBS design must align directly to how capital is governed.

This includes:

• How budgets are defined and controlled
• How approvals are managed
• What reporting is required at project and portfolio level

If the structure does not reflect these requirements, it will not support decision-making, regardless of how well it is configured.

Step 4: Simplify the User Experience

Even the best structure will fail if it is difficult to use.

Fiori applications and guided workflows play a critical role in making WBS practical. They allow users to create and manage projects without needing to understand the full complexity of the underlying model.

When designed correctly, they:

• Guide users through standardized processes
• Reduce manual decision-making
• Enforce governance without adding friction

This is what enables consistent execution across the organization.

Step 5: Integrate with Execution

WBS must be connected to the processes that drive cost. This includes:

• Procurement activities
• Project scheduling
• Cost commitments and actuals

Integration ensures that planning and execution are not disconnected. Costs are not just recorded; they are linked to the activities and decisions that generate them.

In practice, this can extend to generating source-based requisitions directly from project structures, ensuring that procurement activity aligns to approved project definitions from the outset.

This Isn’t Just Migration, It’s Maturity

Moving from Internal Orders to SAP WBS elements is often positioned as a response to SAP’s direction in S/4HANA. In reality, it reflects something far more important: a shift in how organizations structure, govern, and manage capital and project-based spend.

This is not about replacing one SAP object with another. It is about moving beyond fragmented cost tracking toward a model where projects are defined, controlled, and reported as structured investments. Internal Orders can capture cost, but they were never designed to support the level of control, visibility, and integration that modern capital environments demand.

SAP WBS elements provide that foundation.

They enable organizations to connect planning, budgeting, procurement, and execution within a single structure. Projects are no longer treated as isolated cost buckets, but as coordinated investments with defined scope, aligned funding, and clear accountability. This creates a more consistent approach to both CapEx and OpEx, while improving visibility across the full portfolio.

For finance leaders, the impact is practical. Investment decisions become easier to compare, justify, and adjust as priorities evolve. Reporting shifts from reconstructing the past to understanding performance in context. Governance becomes embedded in the structure itself, rather than enforced through manual processes and workarounds.

S/4HANA enables this shift, but it does not force it. Many organizations will carry forward existing approaches. Those that take the opportunity to redesign capital project creation around SAP WBS elements move beyond system alignment and toward a more mature model of capital control.

The change is not simply technical. It is structural.

It marks the transition from managing costs to managing investments, with the clarity, consistency, and control required to operate at scale.

FAQs on Migrating from Internal Orders to SAP WBS Elements in S/4HANA