Budgeting and Financial Management on SAP for a Multi-Enterprise Energy Group
A unified SAP platform helps a holding company manage budgeting, planning, scenario modeling, and financial performance across around ten legal entities.
Energy & Utilities
Central Asia
Background
A large multi-enterprise energy group in Asia brings together around ten legal entities and several production sites of differing profiles. Its production chain runs from raw-material processing and a small number of semi-finished products to a narrow line of finished goods. The group operates one of the world’s most technologically complex manufacturing processes, producing advanced components from rare-metal alloys for the high-tech industries.
The enterprises within the group all run on a single corporate system, yet they perform identical functions — procurement, sales, production, cost calculations — in different ways. The company assembled its budget and financial data at the group level manually or through fragmented tools. The tools the group relied on no longer met its new requirements. It had no unified platform to build a consolidated budget, track actuals against it, and show plan-versus-actual across all enterprises at once.
Challenge
The company operates in volatile conditions, where currency rates, commodity prices, and sales volumes all shift throughout the year. Management needed to anticipate how those changes would affect profit and cash flow so it could adjust budgets in time. What the company needed was a comprehensive financial-management tool where employees could manage plans and actual data, compare them, build forecasts, and run “what-if” scenarios. With such a tool, the company could reforecast the remaining months mid-year based on the actuals collected so far and on changing conditions.
Working together, we identified three main challenges.
Methodology
The client already had its own budgeting methodology and an established process, each owned by specific individuals. But some of the rules weren’t documented anywhere — they lived only in employees’ heads — and the processes changed faster than anyone could write them down. As a result, the documented methodology didn’t fully reflect how the company actually operated.
Enterprise heterogeneity
All the enterprises run on one corporate system, but procurement, sales, production, and cost calculations work differently from site to site. At some, the differences came from geology that required specific processing technologies and ingredient sets. At others, identical system settings were simply applied inconsistently.
Plan-versus-actual comparability
The plan was detailed down to individual line items, but actual purchases were recorded at a higher level and in different units. Because the plan and actual structures didn’t line up, building plan-versus-actual comparisons turned out to be the hardest task of all.
Solution Overview
At the start of a project, setting the right goal matters more than focusing on technology. Frame the challenge too narrowly — say, “implement budgeting in a large holding company” — and the team ends up solving the wrong problem from day one.
That’s why the IBA Group team came in as early as possible. Working with the client’s top management, we defined the goal, the architecture, and the sequence of the work. We ran the project end-to-end using an iterative Scrum approach. The budgeting solution was built on SAP BW/4HANA and SAP BPC, with refined data sources in SAP ERP and integrations with adjacent systems.
Why Methodology and Architecture Come First
The single most important decision is the order of the work — which is why the methodology and architecture teams engage before the core consulting team. For budgeting, this isn’t bureaucracy: the budgeting methodology, the regulations, the source systems, and the integration approach shape the entire project. Without a clear, upfront picture of how plan, actual, and analysis will ultimately be structured, everything built downstream gets built wrong.
Methodology work is needed even for well-prepared clients. This client’s own methodology wasn’t fully current or formalized. We developed a methodology grounded in the real systems, reconciling two sets of requirements: the rules for organizing accounting, reporting, and analysis on one side, and the platform’s actual capabilities for implementing those rules on the other. A methodology that ignores what the platform can do leads to needless rework, abandoned standard practices, and technical debt the client pays down long afterward.
The work was detailed and iterative. We defined the core budgeting rules upfront to guide the architecture, then refined the details through the end of the project. The methodology went through roughly seven approved versions. The solution adapted to SAP BPC’s real capabilities while we also refined the source systems feeding the budget. Our specialists worked side by side with the client’s team to mature the methodology into a working version that served both the business and the actual tools.
How the System Builds Financial Budgets from Operating Plans
The architecture is built on two levels: operational and financial. The operational level brings together the sales budget, the procurement budget, and others. Enterprise specialists plan their needs in physical terms — what materials, equipment, and resources are required, in what mix and volume — without any cost valuation. The financial level consolidates that data into the final outputs: P&L, cash flow, a forecast balance sheet, and regulatory reporting.
Between the two levels sits a calculation engine that converts physical metrics into financial ones with minimal human intervention. It relies on a price reference, standards, and other baseline data. The sales plan is built the same way — from prices in the reference and volumes set manually. Financial budgets form from the operational budgets almost automatically, and the system is easy to change, refine, and scale.
This two-level architecture also solves the heterogeneous-enterprise problem. At the operational level, each site plans in its own way — in its own mix and units, accounting for its own technologies and processes. A shared conversion engine and a unified price reference bring all of that data into comparable financial budgets. One model supports the different processes, and group-level consolidation requires no rework for each enterprise.
How does scenario planning work in SAP budgeting?
The budgeting model starts with macro-parameters such as exchange rates. When one parameter changes, SAP automatically recalculates operational budgets, financial plans, cash flow, and profit projections, allowing organizations to evaluate alternative scenarios before making business decisions.
We built scenario modeling into the architecture from the start. Planning begins with macro-parameters, and one of the key ones is currency.The forecast comes from external market analysis, such as currency projections published by independent financial institutions, and the company builds its budget on that basis. The approved plan is built on these macro-parameters, and the entire model then recalculates in a single action. Change one macro-parameter — the dollar rate, say — and the system recalculates the whole chain right down to the P&L.
Budget Assessment and Revision
The client runs two related but distinct processes — assessment and revision — and the system supports both. Assessment is a forecast of budget execution. At any point in the year, you can forecast what happens under a rate change or other conditions. The system plugs in actuals for the closed months and recalculates the remaining periods. This budget version is created for analysis only, with no further steps.
Revision is rethinking the budget itself. In the second half of the year, for example, the company might decide to revise the plan based on current economic and production conditions. The team creates a new version, it gets approved, and execution from that point follows the updated budget.
Data Quality as Part of the Project, Not the Client’s Problem
Data quality is a shared project risk. Even a well-configured system produces the wrong results on bad input data. So we don’t hand this off to the client — we help get the data in order ourselves.
On this project, the data problem surfaced when we reconciled plan and actual. The budget was planned in detail down to individual line items, but actual purchases were entered into the accounting system in different units and in larger groups. A typical case: a plan lists items by unit, but they show up in the actual data as cases, or under a different purchase code. The plan and actual lines don’t match, so a direct comparison is difficult.
The issue showed why source-system assessment and data-quality analysis need to be built into the project from the outset.
The client didn’t want to change how it records actuals, so we solved it at the reporting level: we raised the aggregation levels until plan and actual became comparable. The planning processes stayed the same, and the comparison was handled through reporting refinements.
Building the Right Team on Both Sides
At this scale, results depend heavily on the team. From the outset, we structure the collaboration so that client and vendor are equally invested in success. Two factors make that possible:
- Project goals are tied to the company’s strategic goals.
- Each participant on the client side has their own KPIs — both financial and non-financial.
For the business units, an SAP project always adds to their existing workload, and the incentive structure turns that burden into sustained engagement.
The client filled five key roles, and we set up a working format for each.
- The sponsor — the deputy CEO for economics and finance — kept the project a priority and set the pace.
- The process owner — the director of the economics department — owned the budget and its execution reporting.
- With the client’s methodologists, we reviewed how the processes actually work in the subsidiaries, and they were the first to validate our solutions.
- We ran end-user testing together in a single room, which is where we caught most of the issues.
- And we worked separately with the client’s IT specialists, deliberately transferring know-how: within three months of launch, they were running budgeting and SAP BPC on their own, supporting users and closing minor issues without us. We treat that transfer of competency as part of the result, not an add-on.
Results
We built an end-to-end budgeting and financial-management system for the entire group on SAP BW/4HANA and SAP BPC. The project ran 16 months and covered about ten of the group’s legal entities. We integrated the system with SAP ERP and the adjacent systems, making it the single source of truth for every budget process.
We locked the business outcomes into the technical specification. The first target — the time it takes to build the budget — came down, and it’s the most visible result. The second — plan-versus-actual accuracy — we validated against strict contractual criteria: end users themselves entered the previous year’s budget into the new system, and the deviation from the way the team had calculated it before couldn’t exceed 3%. The project cleared that bar.
Beyond the targets, the client got a comprehensive financial-management tool. It includes a consolidated annual budget broken down by quarter and month; automatic assembly of the financial budgets from the operational ones (P&L, cash flow, forecast balance sheet); “what-if” scenario modeling on macro-parameters like the currency rate; and step-by-step approval, budget revision, and ongoing plan-versus-actual monitoring. Together, these deliver transparency and control across the entire budget process.
| Stakeholder | What they gain |
|---|---|
| Executive management | A consistent financial picture, transparent assumptions, and the ability to analyze scenarios. |
| Budget process owner | Status control, a single methodology, managed versions, and clearly assigned accountability. |
| Corporate center | Automated consolidation, less manual processing, and unified analytics. |
| Subsidiaries and affiliates | Clear rules, standardized forms, and a managed process for comments and approvals. |
| Functional units | Data reuse, automated calculations, and less duplication. |
| Support teams | A formalized architecture, documentation, and transparent integration points. |
There’s a separate result worth naming — the transfer of competency. Three months after launch, the client’s IT specialists were operating and supporting the system on their own. The project advanced careers, too: the process owner moved into a sponsor role once it was done.
Successful SAP budgeting programs require three elements to work together: a sound methodology, the right architecture, and reliable data. Treating any of them separately increases the risk of rework, delays, and unmet business expectations.
About IBA Group
IBA Group is a long-standing SAP SE partner. We’ve delivered custom SAP projects since 1996. Our team includes more than 250 certified SAP specialists with deep experience across a wide range of SAP projects for clients in over 50 countries.
Looking to modernize your financial planning and budgeting on SAP?
Contact us
Please feel free to include any information about your business you think we should know (e.g., by how much you’d like to reduce your current data hosting expenses, or which cloud provider you’d prefer and why).