SAP BPC

BPC lets finance teams plan and budget (build and manage forecasts and budgets collaboratively) and perform legal/management consolidation (combining subsidiary results, eliminating intercompany transactions) to produce group financial statements, with workflow, versions and an Excel/web interface.

A note on the variants, since job adverts use the names loosely. BPC ran in two flavours, one embedded in BW and one standard, differing in how tightly the planning model was coupled to the warehouse's own data model. Which one a client runs changes the skills required, and it is a fair question to ask before accepting a role described only as BPC.

• Planning & Budgeting: collaborative financial planning.
• Forecasting & versions.
• Consolidation: group financials, intercompany elimination.
• Reporting via EPM/Excel and web.

Finance systems record what happened. Planning systems record what is intended, and the differences between the two shape everything about how BPC works.

Accounting is actual and singular. There is one version of what happened, it is at document level, and it is auditable.

Planning is multiple and aggregate. There is a budget, a forecast, several scenarios, and last year's plan for comparison. It is at a level people can reason about, cost centre by month rather than document by document. And it changes, deliberately, as the year progresses.

So a planning tool needs things a ledger does not: versions, so budget and forecast coexist; write-back, because planners enter numbers rather than posting documents; disaggregation, so a number entered at a total spreads down to the detail; workflow, because a budget is submitted, reviewed and approved by people.

The link back to accounting is the comparison everybody actually wants: plan against actual, by the same dimensions, in one report. That means the planning model's dimensions have to line up with the ledger's, which is the design constraint that matters most and is easiest to get wrong early.

Planning gets the attention and consolidation is the other reason organisations buy this, and it is a different discipline.

Consolidation produces group financial statements from several legal entities, which is not simply adding them up. It requires currency translation at defined rates, intercompany elimination so that sales between group companies do not inflate group revenue, investment elimination for holdings, and minority interest where a subsidiary is partly owned.

Each of those is a rule the system applies, and each has an accounting standard behind it. That is why consolidation configuration is agreed with group finance and often with auditors rather than designed by a consultant alone.

The data dependency is severe: intercompany elimination only works if entities code their intercompany transactions consistently, which is a discipline in every subsidiary rather than a setting in the consolidation system. Most consolidation problems are actually reporting-package quality problems at source.

BPC integrates with BW/HANA for data and with FI/CO for actuals. In S/4HANA, planning and consolidation capabilities are increasingly delivered by SAP Analytics Cloud (planning) and Group Reporting (consolidation), so the field is evolving toward those cloud tools.

Worth knowing where the product line is going, since it affects what to learn. Planning capability has increasingly moved into SAP Analytics Cloud, which is where new planning implementations tend to go, and group consolidation has a dedicated successor. Classic BPC on BW remains widely deployed. As with SRM above, the process understanding transfers and the tooling is a moving target.

Learn BPC through its core processes, its master data and configuration, and its integration with the rest of the SAP landscape. Hands-on practice cements it.

Whatever the tool, a planning implementation is a model, and the same decisions recur.

Dimensions. What the plan is broken down by: entity, cost centre, account, product, time, version. Each dimension multiplies the number of cells, and a model with too many is slow and tedious to plan in.

Granularity. The level people actually plan at. Planning by cost centre and account by month is normal; planning by employee and day is a data entry exercise nobody completes.

Versions. Budget, forecast, actual, and usually several forecast iterations. Being able to compare them is most of the value.

Disaggregation. When somebody enters a total at a summary level, how it spreads down. Evenly, in proportion to last year, in proportion to the existing plan. This is the rule most often left at a default and most often the reason a planner distrusts the system.

Where actuals come from and how often they load, because plan against actual is the comparison the whole thing exists for.

The design test: can a planner see their own numbers, change them at the level they think in, and have the change land sensibly underneath. If any of those three is awkward, the model will be worked around in a spreadsheet.

• Which cycle first. Cost centre budgeting is the usual starting point because it is contained and the audience is defined. Full financial planning across the group is a programme.
• How much detail. The level the business genuinely decides at, not the level the ledger records at.
• Who owns the numbers. A planner accountable per area, or the tool produces layouts nobody completes.
• Where actuals come from and how often. Monthly after close is normal; more frequent needs the source to be reliable mid-period.

The interface planners use decides whether a planning implementation is adopted, and it is usually not the one a consultant demonstrates.

The Excel add-in is how most planning is genuinely done. A workbook connects to the model, reads current values, lets the planner work in the tool they already live in, and writes back. That is deliberate: planning teams are Excel teams, and fighting that is how a planning tool ends up unused beside a spreadsheet.

Web input forms suit occasional contributors, such as a cost centre manager entering their own budget once a year, who should not need a workbook or training.

Input schedules are the layouts themselves: which dimensions are rows, which are columns, what is editable and what is calculated. Designing one that matches how a planner thinks is more of the work than the model behind it.

The practical test of an input schedule is whether somebody can complete it without a manual. If it requires explaining which cells to fill, it will be completed wrongly, and the numbers underneath will be argued about later.

• Learning features, not the end-to-end process.
• Ignoring integration with finance and neighbouring areas.
• Skipping master data/configuration the process depends on.

• Planning dimensions that do not match the ledger. Plan against actual then requires mapping, and the comparison everybody wanted becomes an argument.
• A planning cycle nobody owns. The tool produces layouts and the budget still happens in spreadsheets.
• Intercompany elimination treated as a system problem. See MDG, IBP, MM and the module map for what feeds and surrounds it.

• Modelling at the ledger's level of detail. Planning happens at the level people decide at, and a model that asks for document-level detail will be completed by nobody.

Building a layout is the visible half, and designing a model whose dimensions reconcile to the ledger is the part you do in the course.

The design constraint that matters most is that planning dimensions must reconcile to the ledger. Get that right and plan against actual is a report; get it wrong and it is a mapping exercise repeated every month.